Hi guys,
I’m trying to figure out how to set a controller through MXS-array system. Basically this should be the easiest task in the world, but it turned out, that it’s not:
Create a box, select it, try:
$.visibility = (bezier_float())
Hurray, it sets a float-controller to the visibility track, now:
Create a box, select it, try:
$[1] = (bezier_float())
– result: Error, no put function, bla bla…
– now try this:
$[1].controller = (bezier_float())
– result: D’oh.
Now when $[1] is an equivalent to $.visibility, why the hell can’t I set the controller to this. For the visibility track this it’s not that hard to compensate it, because I could get the name of the array and use the name to build an executable string, but it gets pretty ugly, when I try to set the position of X because I can’t say $.x_position = … I would have to take the “pos” ($.pos.x_position) into account, and basically I just don’t want to do that.
I appreciate any help.
-k.
there is a known bug related to the visibility track. you have to assign it twice:
<node>.visibility = bezier_float()
<node>.visibility.controller = bezier_float()
Denis is correct, your setting the wrong property.
You want to set the visibility’s controller to bezier, not the property visibility directly.
Oh well, that’s interesting!
I’ve tried it out for:
$[3][1][1].controller = (linear_float())
And it worked perfectly.
Are there any other track-bugs I should be aware of?
Thank you guys.
Some history to clear your mind (or confuse you further):
When Max 1.0 was written, the Visibility Track was quite a bastard child. As you probably know, many properties in Max until this day do not have a default controller assigned – the controller is assigned when you first animate the property. For example, if you make a Box, the Position controller is there, but the Height does not have one unless you keyframe it. This was done to speed things up – since a controller is a kind of an object class, the developers thought it was be better not to create too many controllers unless needed. Until this day, asking for the .controller property of such tracks returns undefined.
But the Visibility was special (read: screwed). In Max 1.0 (and for a few releases later), you had to go to TrackView and click a special button (an Eye icon) to make the Visibility track animatable. This means that the Visibility track wasn’t shown in the TrackView by default and was not keyframeable unless specifically enabled to be keyframeable. On top of that, the track was hard-coded in Max 1.0 to be an On/Off boolean value.
So when the MAXScript exposure of the Visibility track was done (MAXScript was a Beta plugin for Max 1.0 and then shipped as part of Max 2.), it was assumed that the Visibility can be either True or False and there is NO CONTROLLER by default! Not just undefined controller, no controller is allowed by default!
Then users requested the Visibility to be animatable smoothly between 0.0 and 1.0 (making the object appear and disappear gradually). That wish was granted, suddenly allowing the user to assign ANY controller to the Visibility track, as long as the track was enabled using the “eye” icon in TrackView.
So when MAXScript was augmented to support this new workflow, the mess you discovered became complete. In short,
*Accessing $.visibility returns True, but there is no controller holding that value (which is quite unique in Max in general)
*Assigning True or False to $.visibility is the standard Max 1.0 approach and actually makes a controller implicitly. It is equivalent to pressing that Eye icon from early versions of Max, allowing the Visibiliy track to actually possess a controller.
*Assigning any float or boolean controller to the .visibility property itself is also allowed.
*After that, the $.visibility.controller property becomes a viable expression in MAXScript, because there IS a controller!
b = box()
$Box:Box001 @ [0.000000,0.000000,0.000000]
b.visibility --> returns True by default, but there is no controller!
true
b.visibility.controller --> and it cannot be accessed via MAXScript
-- Unknown property: "controller" in true
getVisController b --> but the function call works - you can use it to check if valid...
undefined --> shows there is no controller yet
b.visibility=false -->setting the property to any valid value adds a controller!
false
b.visibility.controller -->check if there is one - surprisingly there is!
Controller:Bezier_Float
b.visibility=On_Off() --> this is how older versions of Max stored the visibility
Controller:On_Off
b.visibility.controller = bezier_float() --> this is how modern Max does it
Controller:Bezier_Float
b[1] --> this is just the SubAnim track, not the controller,
SubAnim:Visibility
b[1].object --> but you can get the object of the SubAnim,
Controller:Bezier_Float
b[1].controller --> or the controller of the SubAnim
Controller:Bezier_Float
In short, the Visibility track handling is one of the worst things that ever happened in the whole MAXScript exposure history… You should NOT base your learning of working with controllers on this experience, but put it in the back of your mind as an exception rather than the rule!
Thank you very much for this really in depth Explanation, Bobo.
Basically, I think it’s a general problem, that I use the worst possible example on purpose to start testing
Love the history lesson you shared with us Professor Bobo. Very interesting
Thanks
Love reading pieces of history like that, thanks!
If you’re good at maxscript and then learn a more structured language the more you realize you’ve become really good in exception handling and figuring our workarounds
-Johan