I sometimes get this messagebox popup when starting a krakatoa render (which was working fine until it appears with no major changes),
[Krakatoa Error]
Failed to get the track holder for an Input:Value node
Somebody knows where this comes from or what to look for ?
thanks
This is the first time I hear about this problem.
Here is some background info: When you open the MagmaFlow editor and add an Input node, a bunch of TrackView nodes are created to accommodate its potential Float, Integer and Vector values. Since an Input node can be repurposed to a value node at any time, every Input node gets a track for each type. These tracks have unique names based on the unique ID of the KCM modifier (which is displayed just above the >AUTO UPDATE button in the Command Panel), and a unique ID of the MagmaFlow node. You can press the “Zoom In Track View” button in the Value Input’s UI to open TrackView at the corresponding location.
Obviously, if you load multiple flows into the same KCM within the current session, every new Input would have to make its own tracks. If an input node is deleted from MagmaFlow or the flow is replaced with another, the corresponding tracks remain in TrackView as dead weight. To avoid this, every time the Max file is saved, MagmaFlow runs a cleanup function to find out what tracks are not referenced by any modifiers and nodes anymore and cleans them up (by deleting the tracks and their controllers from TrackView).
It sounds like somehow your scene is being corrupted in some way and when Krakatoa tries to resolve the controller holding the value of an input node, it does not find the corresponding track in TrackView. This could be caused by the cleanup function misbehaving somehow (but I haven’t seen this myself and it has not been reported previously), or something else deleting tracks from TrackView (cannot imagine what though). So at this point I would assume it is my bug 
Things you could do to help debug this - keep an eye on your actions before the error appears. Did you save the Max scene before rendering? If you created a KCM, saved the scene and then rendered and you see the error, then it is most probably the cleanup function that is deleting a node’s track incorrectly. Similarly, if a scene renders ok but you then saved it, closed it, opened it again later and tried to render with the error appearing, the saving action could have caused the corruption due to the cleanup call.
Note that when MagmaFlow is opened from a KCM, it makes sure that every node in the flow has its tracks and if a track is missing, it gets recreated on the fly. So opening MagmaFlow with the broken flow might appear to fix the issue, but if there was an animation for that node, it would be reset to a static value (last value stored in the node definition itself).
If you can figure out specific steps that lead to this problem and even send us a scene that has the problem, it would be very appreciated!
Can you please tell us what version of 3ds Max (2010, 2011, 32/64 bit etc.) and what exact build of Krakatoa you are running?
There is a bug in 3ds Max 2011 which prevents a controller assigned to a trackview via MAXScript from being replaced (this will be fixed in 3ds Max 2012). This required a lot of hacking around the problem in MagmaFlow to make it work again and it is quite possible that the 2011 build of Max behaves differently with Krakatoa than other versions. I am running 3ds Max 2010 64 bit here and haven’t seen your issue…
thanks Bobo for these detailed insights and suggestions.
It is occurring in max 2011 64 together with Krakatoa1.6.0.43612
I’ll try to provide you some decent repro steps if it happens again or i can invoke it but so far it looks like it happens when adding multiple PRT loaders to the scene and indeed saving the scene whilst doing. I am adding a few different sets of partitions so I was creating multiple PRT loaders (each with some simple magmaflows on top of them) for them(duplicating them, remove partitions, add other ones), at some point after adding one I got this when hitting render. If I then leave the scene as is, save it, reopen it, hit render, it does not pop up the error although nothing shows up in my render. Also strangely, maybe not related, my lights (in the new scene) don’t point to their interests anymore until i translate that interest. I’ll try to get you better info if I get some more time to it.
btw. whats better for doing this, adding all partitions to 1 prt loader (talking about 4 sets of partitions each consisting of 50to100 partitions - which gets a bit slow when adding in more and more to the same prt loader, i suppose its parsing the existing ones for duplicates or so?) or using multiple prt loaders a I described ? Does it make a difference in terms of performance when loading the particles ?
thanks for your time
ok, I can evoke this consistently in max 2011 64 when duplicating (ctrl-v > copy) PRTLoaders, I do this to copy my loaders and provide them with different sets of partitions. When I copy the 4th instance, hit render, I get this error and the scene becomes corrupted. However when I add all new PRTLoaders separately (and load back a modifier stack) the problem does not seems to occur, so thats a workaround - or maybe just the proper way to do it 
hope this helps
Is it always the 4th copy, or does it happen after just one?
I would prefer EXACT steps, with a sample scene, sample PRT, PRT Loader and KCM if possible.
Also, I don’t have 2011 at home, will have to wait until Monday to get to the office and try it out there.
In 2010 64 bit, I was unable to replicate the problem, but I could be missing a step.
Here is what I tried:
*Created a PRT Loader
*Loaded a set of particles saved from a teapot turned to PRT Volume.
*Added a KCM, introduced a Multiply Operator with a Vector Input to the default flow.
*Using Ctrl+V, Cloned to COPY 4 times until I had 5 PRT Loaders with non-instanced KCMs (tried Instances, too).
*Just in case, called File>Hold to trigger the cleanup code.
*Rendered in Krakatoa
RESULT: No Problems, no errors.
Please verify my steps and provide yours in the same format.
If you have Max 2010 64 bit, try to do the same there and see if it behaves differently.
I will try to track this down. It is supposed to work, so you are doing nothing wrong. For now, please use the workaround.