ster
patreon
Simple Breakthrough
🕑 Added 2023-01-08 20:25:52 +0000 UTCHey! For you patreon enjoyers I thought I'd write a nerdy explanation of how one simple programming change can make a huge impact.
Its 5 days before Aegis Recruits is scheduled to start again and I just realized something I previously thought was impossible isn't that complicated at all. And its good that I realized it now, because it requires modifying a lot of different types of tokens and macros to update to the very slightly new format.
I've been trying to move everything over to a more consistent way to reference macros so that when I modify the 'master' macro, any character that has that macro is updated. (A macro being any weapon, spell, skill, item. Clickable buttons on tokens)
That is going well, referencing a 'master' token makes everything more flexible and easier to bug fix. However, what I thought was impossible was referencing a 'tooltip' of the description of that macro when a player hovers over it. So, I was basically just creating a snapshot of what the tooltip was when any token that references the original is generated. This means if I ever changed a numerical value on the spell in question, the tooltip would not represent that and it would be wrong anywhere that spell appeared.
The reason I thought this was impossible is because maptools naughty little "getMacroName()" function gets the name of the currently operating macro. And tooltips are considered macros. Sort of. So when a tooltip is referenced and you get the macro name the whole thing breaks, even though the tooltip exists on a macro that has a name. I use "getMacroName()" in a lot of places to help effeciency -- rather than writing "Name = 'Sword'" in a weapon, it just gets the macro name so I only need to update one text entry. Name = getMacroName()
Great until the macro name is a non-existent tooltip name.
Yesterday, while fiddling around with pretty unrelated stuff, I accidently noticed... getMacroButtonIndex() gets the index of the macro that was CLICKED...not the one that is currently running. A lot of the 'meta-macro' functions within maptools are pretty weird and their naming conventions don't really make any sense. Based on how other macros function, I'd always assumed this one worked exactly the same way as getMacroName, with the exception that it got the index instead of name. (every macro has a # associated with like an ID)
So! Now I can figure out the macro that was clicked rather than the one that is currently running. This is great because macros in maptools all can reference eachother. So you click Sword, it takes you to the Attack() function. Now getMacroName() would actually = "Attack()".
Using this information, I made a new function called getMacroClicked() and it solves so many problems and hoops I've been jumping through. Every single weapon that uses getMacroName(), however, now needs to be updated. If a token references a master 'weapon macro' it gives an error if getMacroName() exists within it. Because, again, its not getting the name of the correct macro. Referencing a master weapon token was actually impossible before realizing this -- only abilities had master tokens for a further extension of complicated reasons. Because equipment icons are images... they dont really even have 'macro names' and add an extra layer of being hard to work with.
The end result: There are a bunch of "Aegis Knight" tokens in the base where the players currently are. Each of them would have a self contained copy of their armor, weapon, and abilities. If the armor or skill needed to change, I'd basically delete all but one of the tokens and then copy and paste them all again. No longer necessary. It even solves a lot of other minor annoyances like when having multiple macros with identical names. It doesn't care anymore, it knows the correct one that was clicked.
This is a good example of what I've been talking about for 'backend' work and trying to make things more efficient in the future. In so many ways this very simple realization was the final 'key' in unlocking the full potential of everything I've been doing and simplifies so many things. The items and rewards from the last patreon post also fall into this group. Everything in Myriad that is a clickable button falls into this group.
If I hadn't figured this out before resuming the campaign it would mean updating even more tokens/weapons/items/skills/rewards that have all been duplicated and copied and placed all across any map players had touched. Most things are like that. Big win. In retrospect, its so simple its kind of embarrassing :)
Comments
Congrats! Deduplication of code, data, and your own effort are pinnacles of good software and a good workflow.
programming means constantly learning the difference between "simple" and "obvious". it warms my heart that you seem so enthusiastic about this! I get the same way when I'm working on a problem.
