If you create an empty scene with a single sphere, then run :
getclassinstances sphere astrackviewpick:true
select the sphere, then run
maxops.clonenodes $
You will get a “system exception”.
It seems to be the case that the “getclassinstances” function when used in conjunction with “astrackviewpick:true” causes some kind of change to the scene that breaks maxops.clonenodes()
Now, I actually need to be able to getclassinstances with astrackviewpick without breaking maxops.clonenodes (which is being run by a third-party plugin and crashing), so is there any way I can clean the scene after running this form of getclassinstances ?
The reason I’m using astrackviewpick is that I need to return the treeviewpick client, eg $Sphere:Sphere001 @ [-81.602371,-0.000000,7.418397]
rather than just “Sphere”.
Is there a way to get this node from a normal getclassinstances “Sphere” in this case to bypass the “astrackviewpick” method?
Thanks in advance for any help!
the bug is very weird. can anyone else confirm it?
does the code below crash the max?
(
delete objects
s = sphere()
getclassinstances sphere astrackviewpick:on
select s
maxops.clonenodes selection
)
Yes, I can confirm this, and it is indeed a bug.
Looking further into it (and summarizing the issues), this is what I've found:
1.
This will cause a ** system exception **
(
delete objects
node = sphere()
getclassinstances sphere astrackviewpick:on
maxops.clonenodes node
)
2.
Restart Max and try the following:
(
delete objects
node = sphere()
getclassinstances sphere astrackviewpick:on
)
Now select the sphere and make a copy using the keyboard only b[/b]. This causes an immediate crash.
3.
Restart Max again and run the previews code. Now make a copy of the sphere using the mouse and Shift key and then run:
maxops.clonenodes $
This time it will work.
A hack I've found to "fix" this issue could be to hold the scene after the [b]getclassinstances[/b]() call and before the [b]clonenodes[/b]() call, or better yet to use [b]savenodes[/b]() which will be faster.
Both of these codes seems to work well:
(
delete objects
node = sphere()
getclassinstances sphere astrackviewpick:on
holdMaxFile()
maxops.clonenodes node
)
(
delete objects
node = sphere()
getclassinstances sphere astrackviewpick:on
tmp = getdir #temp + "\ mp.max"
savenodes #() tmp
deletefile tmp
maxops.clonenodes node
)
I am not sure if this will do what you need, but you could try refs.dependents() or refs.dependentNodes():
(
delete objects
for j = 0 to 3 do sphere pos:[50*j,0,0]
instances = getclassinstances sphere
nodes = for i in instances collect
(
node = (refs.dependents i)[1] -- Won't always be the first item in the array
format "%
" node
node
)
for i in nodes do maxops.cloneNodes i offset:[0,50,0]
)
(
delete objects
for j = 0 to 3 do sphere pos:[50*j,0,0]
instances = getclassinstances sphere
nodes = #()
for i in instances do
(
for j in (refs.dependentNodes i firstOnly:false) do append nodes j
)
for i in nodes do maxops.cloneNodes i offset:[0,50,0]
)
EDIT: Added code sample.
i would try:
-- #1
free <trackpick>
-- #2
gc light:on
garbage collection will slow down everything for sure
Thanks for the suggestion polytools. I think that’s what I used previously but it didn’t play well with what I was doing. If I can’t work around this bug though I’ll have to go back and try to make that approach work.
DenisT, glad to see you find it as weird as I do. Your code crashes for me too.
I wonder if there’s a hidden “undo off” when doing getclassinstances given it is a known cause of crashes when using maxops.clonenodes. Is here any way to query if the info buffer is active or not?
Thanks again Jorge,
So, forcing max to copy before running clonenodes fixes the issue… how strange!
Unfortunately your workaround won’t work for me as I need my code to work with 3rd party scripts/plugins that would most likely not be aware that another script has triggered the crash.
I’m trying to go down the route you suggested before of using refs.dependentnodes…
Thanks again!
the bug is very very bad. it must be reported.
it’s more than just what you found. it’s seems like a trackpick holds not weak reference to the anim (object, controller, say node…)
max crashes when tries to make a copy of a node keeping coping its trackpick connections (dependency) as well.
the workaround (technically the solution) is to wipe the fact that a node has a dependency to the trackpick. the code of trackpick is in the max sdk. i’m absolutely sure the bug is in there.
Thanks Denis,
I’ve posted it to the other place (Area), and in the past they have picked up bug reports from there, but if I don’t hear anything I’ll pass on a proper report.
I’m surprised this bug hasn’t caused havoc across many scripts given script A can break script B, debugging it would be a bit of a difficulty!
I’ve reported it from the beta program as well.
Cheers Dave!