Hi,
I wrote script which creates stereo camera rig. Below you can see small part of it. On some machines last line throws “system exception”. Any idea why this is happening? This happens only on one machine and not always. I’m unable to reproduce it in any repeatable way.
StereoSideCamCA = attributes "StereoSideCamCustAttr"
(
parameters main
(
mainCam type:#node
)
)
mainRigDummy = Dummy boxsize:[3,3,3]
custAttributes.add mainRigDummy StereoSideCamCA
mainRigDummy.StereoSideCamCustAttr.mainCam = selection[1]
Are you using 64-bit Max? I have run into random system exception errors quite often with caDefs and 64-bit Max. Sometimes I could just close Max and wait for the process to completely end, then it would be fixed next time I started Max. Other times there would be nothing I could do to get rid of it.
The only reason I really started noticing it was because I had script controllers referencing parameters in the caDef. After that I discovered that trying to access any parameter on the def, even just through the listener, would throw the system exception for me.
Not sure if this is the same thing that is happening to your or not. This issue didn’t seem to come up with 32-bit Max. I can’t say it doesn’t exist in 32, but I didn’t run into it and I didn’t hear anything from the animators. Would be interesting to hear what suggestions others might have regarding this.
Our company has reported this to Autodesk (without real steps to reproduce, but with the suspicion that it is Max 64 bit related). It was also confirmed by a lot of other users.
Autodesk is looking at it under the assumption that the garbage collection is deleting something it should not, but for now there is no workaround except for using Max 32 bit.
If you ARE using 32 bit, then I don’t know.
We are using max 64bit.
Does using type:#maxObject help and store a weak reference? Or is this completely unrelated to the param type?
Another TD and I have been running into nothing but system exceptions in 64 bit when custom attributes are involved. We even got a system exception by trying to access’s a node’s layer name ($.layer.name). The problem is that we can’t even reproduce it as it seems like it happens inconsistently. It makes me sad :hmm:
I have come across an issue with the paramblock myself too and it was related to the tabsize of any tab type param. The stereocam scripted modifier I build used:
bmRenders type:#bitmapTab -- crashed on backburner
bmRenders type:#bitmapTab tabSize:3 -- rendered just fine
So as a rule of thumb, I always declare all the class parameters for a param, because I don’t trust that max does the right default thing when leaving stuff out of the declaration. I have not had any problems after that, but I should note, I’m not a heavy user on this type of tools, so maybe I was just lucky with the tabsize, but maybe it’s of some help to anyone.
-Johan
You have always needed to set the tabSize and the tabSizeVariable if you want to grow it. I saw instability with this way back if you didn’t. Then again it could have been other things that I was doing at the time as it was right back around Max 4 I would think that I first started writing them by hand, I think that is when they were added as well.
As for the error that every one is seeing I haven’t and I can’t say that any of our clients have mentioned it. I will ask some of them and see if any are having that problem that are on Max 2010.
I think the only reason it was popping up for me was because in the script controller where I was getting the error, I was calling on a maxObjectTab. Since I wasn’t able to hold direct reference to the maxObjectTab through the script controller’s built in variables, I had to store the modifier or def, or however I went about it, and then access the parameter through that means.
If I remember correctly, there were other parameters from the def being stored directly in the script controller’s built in variables and they didn’t seem to be throwing any errors. Wish I still had the file to confirm that, but if this is the case the issue might go by undetected in most cases. If any parameters being used are being stored directly in the script controller’s variables, no ones the wiser.
Just for the record, when I was running into it it was in Max 2008 64-bit. Are you guys still using 2008 there Jay?
We’re using 2010 now, but we’ve had the same problems in 2008.