Playerstats: Refactored!

I Don't Wanna!

After a trip out to the mall yesterday, I decided to take a stab at the remaining work to be done surrounding the refactor. At first, I thought it was going to be a pretty easy lift. I was wrong. I spent a while just looking over the code trying to figure out what needed to happen and there's a lot of interconnected stuff that needs updating. It was too much for me, so I just put it aside to tackle on a fresh brain today.

So, here I am, trying to tackle it, and it's still just as ominous and beastly as it looked yesterday. I figure I should just tackle it little bits at a time. Doing it that way should help me break it down into more manageable chunks. So, the first step is to address the variable that holds the information surrounding the currently active effects. It's a simple change at first, just changing the dictionary definition. But it has cascading effects across the whole playerstats manager.

Next up was a change to the way I apply active effects, instead of passing the entire effect I just pass the effect id. This means querying the data manager for the actual effect information. Once that was done, all the errors disappeared regarding the change in variable declaration, but there's still so much to do. There are a lot of other changes needed, like the process to decay active effects. I relied heavily on Gemini for this process, making it review my code numerous times to find things I missed. I even spun up multiple chats to help so that the AI didn't get confused.

Eventually, I was able to successfully remove all internal functionality surrounding the effect definitions and made it rely entirely on the data manager for effects. After that I had to tackle the effect thresholds, which was it's own beast. Tackling that required a lot more work with Gemini, and multiple chat instances. It turned out the actual refactor to use the data manager for effect thresholds wasn't too bad. It actually streamlined my code a little bit. Once that was done, I wanted to make sure my changes were good and Gemini seemed to think so.

The final step here was to remove the internal data loading functions and related artifacts. I asked Gemini to validate the removal because I wanted to make sure I wasn't missing any other components prior. It didn't go well. The AI started hallucinating and told me I'd break everything because I'd be relying on the data manager and all kinds of things would break. Oh well, I started deleting. I wasn't fully confident after the removals though, so it was time to open another chat instance to get feedback from Gemini. 

It actually gave me some good feedback and found a small issue I had overlooked when it came to decaying effects. I made a note in the code to address it later, but it seemed to me that I'd not broken anything. After a little bit of testing, I confirmed that everything appears to be working correctly. Only time will tell if that's actually the case.

Next Time

It is still so early in the day I might dive back in later, but for now I'm happy with the outcome. Next up is to address the whole reason for this refactor, consumables! It really should be pretty easy, I just need to finish writing a couple of functions, one to process the use effect on the item itself, and the other that actually applies the instant effects. Actually, nevermind! I finished the first function that addresses the use effects on items. All I needed was to add a call to another function with the effect id. Now all that's left is to build out the function that processes instant effects.

I actually decided to make a couple of other small modifications to the code while I was writing this up. In one place I was passing the id of the effect directly out of the effect definition instead of passing a variable that contains the same information (consistency is key!). I also changed the way my instant effect processor receives the effect data. Originally I was passing the whole effect definition, but now I'm just passing the effect id and it can look to the data manager for the rest of the data.

But, I'll deal with that next time, which may not actually be tomorrow. Maybe today, maybe Monday, who knows. I think tomorrow we're going for a long drive so there probably won't be any time available in my day for development. Either way, this is a huge win today and I'm very happy with my progress! 

Not Next Time

So, I got a bit bored and decided to just keep working. I decided to dive into my instant effect processing function. First up, just in case a non-instant effect is passed, I validate the effect id to make sure duration truly is zero. After that, I have to iterate through the item's attribute modifiers and match them against my options. Then on match I just send the value to the appropriate function. It took a little bit of back and forth with Gemini for me to figure out the correct syntax for all of it, but I wrote every last line myself.

And testing shows that it works without issue, surprisingly. This is great, the player can now properly consume items! Well, there really is only a single item to consume so far, but it works exactly how I want from the inventory. The player selects the item, then hits the consume button and the item is removed. Then the effects on the item are all triggered and the player regains some health, energy, and satiety (if any of the stats are drained). This should also allow me to add other effects to consumables, like attribute or skill buffs and debuffs.

Next Time (Really)

Okay, for real now I probably won't be touching the project again until Monday. Pretty sure tomorrow will be a complete wash for game development. I'm sure I'll spend some time talking to Gemini on the road to plan the next session or something. But I doubt I'll do any actual work on the project directly. The next steps are to work on the quick action button assignment. This one will be a bit tricky as I want to add some extra logic. I want to prevent the player from assigning the same item to multiple buttons, and include logic on the button push to clear the assigned item if it runs out. Maybe I should add a cooldown to the button too? To prevent accidental spamming and eating? I dunno, for now I'll skip that portion.

I had a bit of a chat with Gemini to try to figure out the best approach for updating the quick action buttons upon item depletion. Originally, I was going to trigger it from the current function that consumes items. But I realized that would miss a few cases where an item is depleted without it actually being consumed. Instead, I'll trigger it directly from the function that removes items from the inventory. First, it'll need to check if the new quantity is zero, then it will need to check if the specific item is assigned to a quick action button. If both of those conditions are met, I'll first clear the specific quick action button assignment then emit a UI Update signal which will force the button to update.

So, the plan of action is pretty straightforward. First is the actual button assignment, followed by a signal to refresh the UI. I'll need to include a check for existing assignment. If it's already assigned it will move the item to the new slot (clearing the old one's assignment). I also need to build out the system to refresh the buttons themselves, which I'll hook onto my existing UI refresh signal. After that, I'll add the logic inside my item removal function to look for a zero quantity on an assigned item. If it finds one, it'll clear the setting followed by a signal to refresh.