Yet another way to save resources in Starcraft. By resources I mean DCs and switches. So lets say you've gotta store 16 different Boolean values for human players in your RPG. You could use 16 switches x #Players, which could be a lot of wasted switches, and a hassle because switches are global. You could also use 16 DCs to store these values, but it would still be a waste since the DCs would only ever be 0 or 1.
SO
Instead of all that rubbish. We can localize 16 switches by storing them in a DC at the end of a players trigger cycle and loading them at the beginning of the cycle. We can accomplish this by representing a switch with a power of 2.
Switch1 = 1
Switch2 = 2
Switch3 = 4
Switch4 = 8
Switch5 = 16
Switch6 = 32
Switch7 = 64
Switch8 = 128
Switch9 = 256
Switch10 = 512
Switch11 = 1024
Switch12 = 2048
Switch13 = 4096
Switch14 = 8192
Switch15 = 16384
Switch16 = 32768
LOADING THE SWITCHES:
DC at least (switch value) --> set switch, subtract value from DC.
Going from highest to lowest.
STORING THE SWITCHES:
switch is set --> clear switch, add (switch value) to DC
Congratulations, you now have 16 localized switches, which means they're different for each player that loads/stores em.
The only downside to this is that since they're local you won't be able to access other player's switches.
None.
An artist's depiction of an Extended Unit Death
Couldn't this be done with a single death counter, where it is subtracted in the binary manner you described to figure out what flags are set, and only subtracting when you need to do it in the trigger list? I guess if you couldn't arrange the triggers in this manner, it wouldn't work as well.
You also didn't mention how to restock the death counter in the switch scenario.
Couldn't this be done with a single death counter, where it is subtracted in the binary manner you described to figure out what flags are set, and only subtracting when you need to do it in the trigger list? I guess if you couldn't arrange the triggers in this manner, it wouldn't work as well.
Yes it could be done that way. I don't think it would be worth it tho, seeing as it would be a crap ton of triggers just to get a single value every time you need it. As opposed to just the triggers to load at the top of your list, and triggers to store at the bottom.
You also didn't mention how to restock the death counter in the switch scenario.
I don't know exactly what you mean by this. I described Loading and Storing.
None.
Couldn't this be done with a single death counter, where it is subtracted in the binary manner you described to figure out what flags are set, and only subtracting when you need to do it in the trigger list? I guess if you couldn't arrange the triggers in this manner, it wouldn't work as well.
You also didn't mention how to restock the death counter in the switch scenario.
Yes, this actually circulates around a guide I've been wanting to make about data management. Anyway, it does make more sense to store everything as normal, but calculate it in binary.
None.
An artist's depiction of an Extended Unit Death
You also didn't mention how to restock the death counter in the switch scenario.
I don't know exactly what you mean by this. I described Loading and Storing.
Oh, I missed the adding back into the DC part in the storing process.
Couldn't this be done with a single death counter, where it is subtracted in the binary manner you described to figure out what flags are set, and only subtracting when you need to do it in the trigger list?
That's what I did in Autocracy RPG, storing all my Boolean values as binary using a single death count. I think that system is advantageous since death counts for one player can easily be checked and modified by other players if necessary.
It doesn't take a lot of triggers to check either, you can make a single set of triggers that test the values being stored and have those troggers initialized whenever you need any value loaded from the storage death count.
