BLR Interface: Initialization

Let's GO!

Time to start the new year off right by starting work on the game early in the day. Well,  I guess it's not all that early, I just finished lunch. What really matters though, is doing the work. So where do I start? How about the simple stuff, like updating the text in my BLR interface? I realize I need a way to tell it to update, so I quickly added a connection in my signal handler to my ui manager's refresh signal. Then connected my BLR interface's display update function to that signal.

Now, let's make that update function actually do something. First, I need to be able to grab the appropriate data from my BLR-related data. . . which means getting that data. Actually, I should probably clear the fields first, so another partial function there to reset the labels. I'll have to add the functionality to reset the prerequisites and costs later, so a couple of quick comments. Man, things get complicated quick with even the simplest ideas. I realize I have this error label, so I might as well use it. This means a whole new function for that. But this also means more localization!

Looking at my localization data, it seems at some point I swapped out the specific naming convention I was using, so on some keys the node type comes last and on others it comes second, how did this happen? I'll worry about fixing that later, as long as the localization works, that's all that really matters. Even then, I still have to remember to use my translation wrapper on my data. After doing a bit of work, I wanted to test it and for some reason nothing was updating how I expected. Then I realized I never actually told the game to fire the function that updates the display. I've now added a single signal emission of the refresh UI signal to my UI manager whenever it detects a state change. Hopefully that doesn't add too much load.

That still didn't help. I needed to also call the function internally in ready for the BLR interface because it doesn't exist during the initial state change that instantiates it. Of course, there was a crash too because I accidentally used the wrong variable name in that function. . . Weird things are happening. Even though I should be sending this signal every time the state changes it's clearing but not updating the labels. So, after a bunch of new debug lines and testing I was still scratching my head trying to figure out the issue. 

In the end, I had a quick discussion with Gemini and found the issue is that I was using the clear method while setting the value using the text property. Because the value being assigned was the same as the previous one, Godot wasn't working how I expected. A quick change to my script to use the append_text method and all was right in the world.

Keeping Going

I was contemplating stopping for the day, but decided to keep going with some of the easier things. I started by designing my prerequisite item scene. Then I started working on the functionality to return those to the pool, as well as the yet to be created cost item. Sure, I don't have the instantiation functionality working, but I can quickly reset the pools now! Then it occurred to me that the player may switch between tabs of the BLR interface to be able to meet a prerequisite, and this meant I need to force a refresh of my tabs when switching. So I dove down a new rabbit hole and added more functionality.

Once that was done, I decided I wanted to update the look of the BLR interface. At first it was the same red color I used for the induction terminal interface which didn't feel appropriate. So I changed it to a nice bluish-greenish color. I'm sure I'll need to do a lot more in time to these interfaces. A nice background image would be great, add some animation, etc. But that's for later, first I gotta get the functionality working.

And before I can get the functionality working I had to figure out the data handling logic surrounding my prerequisites and costs. I actually ended up finding I was being a bad coder and operating on the class data directly instead of creating a copy of it. I sure hope I haven't made this same mistake in other places. See, I was originally popping data out of a dictionary and into another based off the referenced data in the BLRDefinitions class. Instead, I needed to do a deep duplication of that data so I didn't accidentally start erasing stuff. That would have been a headache to figure out down the line.

Good thing I decided to test before calling it a day.  Turns out Gemini lied to me and the pop method doesn't actually exist on dictionaries in Godot. It was a quick fix, I just changed the method to "get" and added a new line to erase the entry. Would have been nice if Gemini didn't hallucinate this though. I actually ended up streamlining the code slightly with this new approach. Since the erase function returns true if data was actually erased, I no longer needed to check the returned data to make sure it wasn't empty.

Next Time

I think that's enough for today. I got a serious amount of work done today. My next steps are very clear, first I need to deal with my prerequisites, then I need to deal with costs. Finally, I need to deal with a successful button press. It sounds really simple, and it shouldn't be too difficult, but it will definitely require time and effort. Luckily, I'm still off work for the next 3 days (although I'm sure I'll be stuck going to the mall tomorrow). Great session! Lots accomplished! I'm very happy with how everything is going.