Bugs, In our game? It’s (now) less likely than you think.
Brandon asked me (Zach) to do a blog outlining some of the recent fixes we have coming with 1.5.5. However considering we have a pretty constant weekly update cycle I’d like to try to do a blog for every weekly update. We’ll see.
So. In 1.5.5 we have some pretty substantial bug fixes coming, that I hope should clear up a lot of issues people are still having. I will try to explain the most significant one here.
The Self Infliction Bug:
I am going to attempt an understandable explanation of the bug, and then the subsequent fix, hopefully this will be understandable, but it will be dense. (Don’t worry, I will aid you with pictures)
This is achieved by rotating the “green” mirror until it reflects the green laser straight up into what was the prism splitting the red.
So what exactly happened there? Well to better analyze it, lets take a look at what happens now (corrected):
At first glance this doesn’t look much better, but one key thing to note here is you can easily rotate the mirror “back out” of this situation to return to what it was in the original picture (this is good!)
To finally explain this bug, I will give a brief explanation of the logic involved in a laser “creation” (in this instance by rotating we are deleting a laser at the previous angle, and creating one at the new angle).
When a laser is created there are 3 main aspects to the logic: (simplified)
- Do stuff
- Check for what this new laser will affect, and calculate accordingly
- Do more stuff
So in a situation where the newly create laser hits a mirror, the logic is something like so:
- Do stuff
- Check for what this new laser will affect, and calculate accordingly:
a. Do stuff
b. Check for what this new laser will affect, and calculate accordingly
c. Do more stuff - Do more stuff
And so on, and so forth. This logic can nest infinitely deeply (well until you physically run out of room for more objects to affect). With that basic understanding out of the way, lets apply it to the aforementioned situation.
When you reflect the green laser up into the “red splitting” prism, this series of events happens:
- Green laser created pointing straight up
- Green combines with the incoming red to form the dead white
- The prism that previously combined red + blue to form purple, now has no red input. Thus it now splits blue, one straight up, and one straight Right (default outputs of a single split).
- The blue laser now going straight right combines with the prism that was splitting yellow forming green.
- The yellow that was being split straight downward is now removed, meaning our original green laser does not exist. THE ONE WE USED TO START THIS WHOLE MESS. (see the buggy pic up top)
Because of the nesting nature of this process, it is bad to end up affecting something that is already being modified once in the chain. The code could have certainly been designed differently originally to avoid this issue, but of course hindsight is 2o/20. With that being said, once discovered this issue was actually really easy to fix.
There is now a global “Object Modification Stack” That maintains a list of objects currently part of the recalculation chain. If a laser tries to affect a Prism in this stack, it is respectfully declined. Leading to the result in the “fixed” picture. The blue laser is stopping at the yellow splitting prism, because it knows it cant proceed any further without royally fucking everything up 🙂
I hope anyone who reads this finds it remotely interesting, and not terribly confusing.
– Zach