I think I’ve found a bug, I’d like to confim it before submitting it.
Assing a script float controller to some parameter.
(Create a box and e.g. assing a ‘float script’ to it’s width.
Edit the script and put this in
print F
1
This return 1 and prints the frame at which it’s evaluated. Scrubbing the timeline indeed show the frame number in the listener as expected.
Now deselect the object and re-select it again…
now the listener prints a whole lot of numbers, more then 100, ranging from -4.6 to 62.123.
So is a controller evaluated a zillion times when you select an object? This can cause quite some lag with complex script!
i can’t reproduce the bug. for me it works as expected:
b = box()
b.width.controller = float_script script:"print F; 1"
// max 2010/64 and 2012/64
Ahh never mind, I had the trackview open, to draw the graph it has to evaluate all points I guess.
That also explains why it happens on a select.
/it must be Friday
[one of the biggest problems of the current reference system…]
another:
assign script controller, e.g: to a sphere radius:
if modify panel is open, the scrpt controller will update 3 times
if another panel is open it will update 2 times
if you add an ‘empty modifier’ on the sphere, it will update 1 time only
so there is a lot of redundancy in max…
it's not a problem of scripted controller. a scripted controller evaluates on every notification message that system sends to it. when sphere's UI opened in modpanel and radius's Spinner visible the system sends notification message two times - one on radius update and another one on spinner update. so the only [b]two [/b]evaluations might be happened. i don't see how it might be [b]three [/b]times.
EDIT:
hmm… i checked a sphere radius. Ruramuq is right. scripted controller assigned to the radius parameter evaluates many times and depends on number of opened views, well shame on developers who coded the sphere primitive. we can do nothing in this case.
I’m not saying its a mxs controller problem. it’s just a way to test it.
the problem is that the UI, while reading values ‘forces updates’.
If we want to be a lit technical, it’s like a strong reference, instead of an indirect one…
the track view is similar in that sense
in the tests, I scrubbed the timeslider to get fair results:
(
sp=sphere()
ctr=sp.radius.track=float_script()
ctr.script=“print (timestamp())
20”
)
try move the timeslider one frame and check the listener:
slidertime+=1
–modpanel open==3
–createpanel open == 2
–add customAttrib mod = 1
(the CA mod, adds a derived obj/modified obj which probably block the direct access to the baseobject, that triggers the extra updates).
[oh, I read your edit…]
anyhow, the other sad part of the ref system, is that custom parameters with strong references no X node transform, do not connect at all…
that’s very old BUG which drives me crazy for many years. but Autodesk developers are all the time too busy changing max UI, UI schemes, default viewport behavior, default hot-keys, etc. they don’t have time to fix a bugs.
i think the sphere is a sample of bad coding. i see that radius script controller receives change notification on every sphere’s parameter change. it seems like on any paramblock change they send a message to update ALL parameters.
I think we can safely assume the Sphere primitive was the first geometry object ever to be coded for Max pre-1.0 (sometime in 1993 perhaps?), so I don’t think it is a surprise…
Make sure to log it through the bug system and get it up on uservoice to try and get it to become a priority.
-Eric
This happens with other objects too:OilTank makes even more updates.
Personally, I think that rather than fixing this, max would benefit from a new reference system/(controllers too), now that people is wanting a nodal system and better animation for max.
