Brenton, you didn't really expect the general population to understand this strange and mystical problem did you?
Before anyone should think we have some grimlins performing black magic inside Flexsim, let me try to explain the underlying problem behind this problem in hopes that it calms anyones suspicions.
If anyone has spent much time looking at the tree view in Flexsim, you've probably noticed that nodes that have been toggled as flexscript nodes (the light brown square nodes with an "S" inside of them) usually have a plus sign next to them. If you click on the plus sign you will expand the flexscript code tree that is created during the flexscript build event which parses your flexscript code and creates the code tree for quick interpretation during run time. Ok, keep this in mind for a minute.
Now let's look at the Recorder's functionality. When Nico specified on the Recorder what data he wanted to capture, he did so by specifying the name of an object in the model and the name of a node on that object. The object's name was "Processor", and the node's name on that object was "Total". Well when the model is reset, the Recorder starts at the top of the object data tree of the Processor object and searches for the FIRST occurance of a node named "Total" and stores a reference to the node thinking it is the node it needs to record during the simulation. Well, because the OnReset variable node contains the code setlabelnum(current, "Total"); is ranked higher in the tree than the label node, and because the parsed flexscript subtree of the OnReset node contains a node named "Total (interestingly enough, "Total and Total appear as the same name to the engine), the Recorder thinks that it is the node it needs to record rather than the label node named Total that is further down in the tree.
Do you see the problem? Now do you see why the problem was fixed by not using the name of the Total label in your code, but instead using the index 1? It's simply because in so doing you removed the parsed flexscript subtree node named Total, and therefore the first occurance of a node named Total was found to be the label node which is the one you intended to record.
Incidentally, this is not a v4 problem, this problem existed in v3 as well. It's just that in v3 you didn't typically use flexscript, but instead you used compiled C++ code. Therefore you didn't run into this problem of searching for nodes by name in the tree, and stumbling upon an unsuspecting node by the same name inside of a parsed flexscript subtree.
I hope this all makes sense somehow in spite of having done a horrible job of explaining it, because I sincerely hope to not have to try and explain my explanation...
You just need to hope we find a solution around all of this in a future release! I'm confident we will, but in the mean time, be careful of situations where you are referencing nodes by name and expect Flexsim to know what node you're refering to by reading your mind.
Display Labels with the Recorder
