So what is it all about ?
Well, sometime when you implement an Editor to a plugin, you can fail in following your own rules. In this case, the plugin relies on designer entering an ordered "step id" numbers, so step 1 comes before step 3 and so on.
The Editor does create its own "id" numbers, but they might not be ordered in the same fashion as the plugin expect, for example the Editor can produce the following:
step start will receive id 1
step two will receive id 27
step three will receive id 124
step end will receive id 9999.
So what is the problem ?
Well, when you add more steps and change their "next step", the Editor will re-order the steps in the tree node, which leads to the output mission data file to also change the order of the steps.
Since the plugin reads the steps in sequential order, it will read "start" then then 27, then 124 etc...
But if you altered the order, it might read:
"start", 124, 27 etc...
Now, if in our plugin we use a logic that determine depends on order of steps (smaller to bigger until reached end), It will fail due to the fact that the Editor does not fix the ID numbering.
Instead of fixing the Editor, I decided to "fix" the plugin. I decided that I'll enhance it, and apply the rule during mission data load. So every time I evaluate the "step id", I will also evaluate the "step sequence id".
So far during this interesting bug fix, I had the opportunity to also fix an issue in the 3D object display function, and hopefully made it faster.
I'll just do some more sanity tests to make sure that I did not break anything else, and hopefully will continue with the next iteration (v2.1.28).