Protobound Day 7
Continuing where I left off yesterday, I'll get the equipment stuff hooked up to the UI and then implement the party members' panels.
Side note; funny how Tesla used flash memory for high I/O. I mean why would you ever do that? Anyone who has worked with flash memory knows you do not want to be reading and writing on flash very often or it'll wear out. Work enough with raspberry Pi projects and you'll learn. That's why I was so happy to see the boot-from-usb feature become official, now my local PostgreSQL runs on a Pi. Anyway, back to work.
Right so the drop-down is probably not going to work the way I had intended so I guess I will spend a little more time creating something a little better. I need to eat some lunch and figure out exactly what I am going to do for it. Maybe have a texture button whose sprite is set to the current equipped item. Click that, opens another panel with a grid of buttons for all other armors. I could have some tool-tips display the stats and armor name. (Or weapon, starting on armor because arbitrary choice)
So first lunch, walk dog, then figure out how the data will flow around so the UI properly equips the right items to the right party members.
Okay, a button that opens a panel. Select item in panel = change armor and close panel. Simple enough, watch me over-complicate it.
It's making me think more and more of a 90's Cyberdeck from old parts out of the 70s-80s.
Now the button needs to open another panel. Really not a fan of the grid container. I feel like I am missing something big in the UI system. Don't really have the time to mess around and figure it out right now though, need to get this done today.
So you click the button, the panel opens and populates itself with buttons based on the panel slot the button was on. So we need to get the data for what character is currently being equipped and the data for the inventory to this panel somehow.
So I wrote a filter on the inventory to find Armor in inventory that can be equipped by the character that panel refers to and return it as a dict with reference to the node that contains the armor's data. Then I send that over to the armor selection panel. Now I need to populate the buttons with the armors and wire them up to fire the equip_armor function on stats and when armor is changed fire the unequip function for previous armor.
Now I just need to add the tool-tip and figure out how I am going to get the data over to the stats system. I guess I could directly call the equip function from the button and pass the stats object over from there.
She ain't pretty, but she gets the job done.
func populate():
print(character)
var cur_armor_btn = 1
print(armor_inventory_for_character)
for armor_item in armor_inventory_for_character:
print("Armor found: " + armor_inventory_for_character[armor_item].item_name)
get_node("Armor"+str(cur_armor_btn)).texture_normal = armor_inventory_for_character[armor_item].item_sprite
var armor_info = armor_inventory_for_character[armor_item].item_name + '\n'
for stat in armor_inventory_for_character[armor_item].stats:
armor_info += stat + ": " + str(armor_inventory_for_character[armor_item].stats[stat]) + '\n'
get_node("Armor"+str(cur_armor_btn)).hint_tooltip = armor_info
I feel like I am doing this really stupidly. I don't think I planned it enough. Oh well, almost got it working now. It'll come back to haunt me or it wont. If it does I can point back to the moment where I fucked up and learn from it, so que sera sera.
Yup. My current implementation of stat mods doesn't know where it's mods come from. I can set it to is_equipment so it wont run the turn-based countdown... but if I went to unequip armor I would have to search for modifiers that match the stat and amount with is_equipment == true. Not great, don't really have time to rewrite it so...
Yep, that's working. Has to be good enough for now.
func unequip(stats):
print("Unequipping item.")
#DUCT TAPE!
for stat in stats:
for mod in get_children():
if mod.is_equipment:
if stats[stat] == mod.stat_mod_amt:
mod.equipment_removed()
Damn it's bad. Well, I'll redesign it later, for now I gotta get the weapon version working. So much for simple, eh? It did occur to me I didn't even need weapons and armor, really. But it's in the issues for the week and it's only Wednesday with one issue left after it so it's getting done, dammit. Hell or high water.
Now to wire up the party members to this... thing. Oh boy. The buttons will have to be wired up differently, of course. Also need to hide/show things when necessary. Alright, brain, enough hackery, get your shit together.
Undefined symbols for architecture human:
"me::Work::operate_brain()", referenced from:
_main in getshitdone.o
So now to look at the code I wrote yesterday and hope I remember exactly how the flow works. Well, I do keep these logs for a reason, don't I?
Right, so I need to get the party member from the party child of the player for each slot. If there is one. If not I need a signal handler that will add that party member's data on recruit.
Breaking some DRY rules with how the UI is hooked up. Foolish, will regret it. Lots of regrets to be had today. Really stickin' it to future me.
Sometimes you forget all the patterns that exist, including the ones you use. I forgot about signals for a while there. I really should have spent more time planning this feature.
Of course for some reason the stat labels get zeroed on me so I gotta go back and re-do that. I hate coding UI in any of the game engines I use. Maybe when I write my own damn engine I can fix that problem. Anyway, back to it. It's past 4pm now, gotta go fast.
I think it works, though I need to make some equipment items to find out. I guess I can make a weapon for Ro and see if it's all good.
It's 5pm now and I got a stack overflow, first time for everything. Looks like I will have to finish this tomorrow.
The best laid plans, eh?
Cheers.