My weekend consisted of this little boolean in my console output. Me and him became real close friends!
In short, in my previous update I said I had fixed the GUI bugs, finally. This was not a smart thing to say, since it turns out that I did not. I had one panel fixed and working sure, the code was even pretty eloquent. However, I foolishly thought I could just apply the fix to all panel toggles the same way and everything would be cool! I should have known better!
Adding the same fix to multiple panels toggle buttons, which are simple Unity GUITextures, caused utter chaos. This wasn't because they shared data between themselves. In fact this was the problem. Each toggle button tried to talk to other toggle buttons panels on their own. So the GUI could reach a state where a toggle affected another ones panel, which then screwed up the panels primary toggle.
For example, toggle x has panel x, toggle y has panel y. When these work separately with their panels, all is well. Click a toggle, panel is set accordingly. However, now they talk to each others panels! So toggle y says to panel x, close yourself sir! Panel x does so but now toggle x says close yourself sir! Panel x doesn't know wtf is going on now and just breaks down in tears.
This was bad-news-bears, if I was only worrying about visibility then the worst that could happen was a panel popping up when it shouldn't. But since I have to deactivate a panel completely to hide it, I was running into nullpointers all over the place! So, I had to find a way to apply my toggle fix to all 4 panels and have them play nice with each other.
So to fix this I did what I normally do, refactoring! Rather than have all the panels talk to each other in an uncontrolled way I made another manager class to coordinate the panels toggle buttons. This class would hold the state of all panels and if a toggle button wanted to know the state of a panel, it would ask the manager class. All the toggle buttons spoke to the manager class rather than each other.
This improved things but didn't fix the bug completely.
I was still getting nullpointers on launch for many of the toggles. When the level loads, the toggle buttons all grab each others Panels and stores them for reference later on. The problem was that some toggle buttons do this faster than other buttons, for some reason. Once they grab the other toggles panel information, they then hide themselves. This is so the user doesn't end up with a bunch of panels all up in their grill, yo!
Unfortunately, if one panel hides itself before a toggle button can grab the info they need, it results in a nullpointer and a broken toggle button.
To fix this bug I had to implement a loading feature. It works pretty well and basically it goes like this: A toggle button loads in the required info from the other panel elements. It then tells the GUI manager it's all done loading its data and storing it for the harsh winters ahead. This is done by all toggle buttons that need data from other GUI elements. The manager class waits until it receives the OK from all relevent GUI elements (all the toggle buttons) and then sends out an OK to everyone who needs it. Once the toggle buttons receive the OK from the manager class, they hide all their panels and anything else that they don't want to have on display on level load.
Finally, after many, many hours of crazy unorganized panels flying around and buttons running around my screen pooping out nullpointers, I have this fixed. I can't help but feel this is a crazy long way to code a GUI with a bunch of panels/toggle buttons. Maybe I did it the right way and just took longer because I didn't plan for it mentally?
Anyhow, the next post I'll talk all about the Stats panel and how Unity's Start() method trolled me! :P
Thanks for reading and have a great day! :D
Rob
No comments:
Post a Comment