on the map April Defense, it uses a system where you buy upgrade levels that you can use for all the possible upgrades

the idea is that when u buy upgrade levels your minerals stay on that number until you buy more

for example, i buy 3 levels of upgrades. my minerals stay at 3. then i buy 2 more, and my minerals then stay at 5.

short of making hundreds of triggers and switches, how can i do this?

Edit:
Im looking at the triggers and they use death counts to determine the level, however im still not quite sure i understand how it works

Post has been edited 1 time(s), last time on Jan 4 2009, 7:48 am by Toothfariy.

I think they have a lot of triggers. Lets say, one trigger for one upgrade. They have one death count to represent one upgrade. Then there is another trigger like this.

Conditions:
Player X has suffered 1 death of "unit"

Actions:
Set minerals for Player X to 1
Preserve Trigger

Then for two minerals change the 1 to a 2 and so on. I'm guessing this is somewhat what is used.

but doing that would mean for every upgrade level, i'd need a trigger

and that'd be 225 triggers, per player
i dont think the map could support that many triggers

It could
but here is what I suggest (without looking on map)
the upgrades does not cost minerals, or? if yes:

Lets say 1 upgrade costs 1 gas, then you only need that one trigger.

Player: X
Condition: Current player accumulates exactly 0 Gas
Action: Preverse trigger
Action: Set reccourcen for Player X: add 1 Gas
Action: Set reccourcen for PlayerX: add 1 Minerals

It detects if you made an upgrade and then it adds one minerals.
Hope that helps.

that might work, however, i need to use minerals to buy other things, other units etc.

i want to use gas so that i can upgrade to x amount and have the gas amount stay where it is after i've bought x amount of upgrade levels

Using current player, you won't need to do this per player.

Devourer's suggestion is good, and really simple. If you could use custom score or something in place of minerals, then you would be better off.

I would have suggested a more complex system that updates the minerals based on the number of deaths of a unit. You would need to create triggers for the powers of 2(make sure they are in order from highest to lowest).

In the initialization trigger, set minerals to 0.
For each power of 2, subtract deaths of unit A, add minerals, add deaths of unit B.
For another power of 2, subtract deaths of unit B, add deaths of unit A.

Preserve triggers. Add deaths of unit A to increase the resources obtained by the player.

Heinermann's suggestion is the most efficient method for what you want to achieve, but I feel it needs some clarification.
Basically whenever you buy an upgrade level you increase unit A (=Death Counter).
Then he uses 2 Binary Countoffs to keep your minerals at the same amount as unit A.
In principle thats work just like saying
if current player has suffered exactly 1 death of unit A then set minerals to 1
if current player has suffered exactly 2 death of unit A then set minerals to 2
... etc. until 255.
But the special properties of binaries make it possible to need only n triggers for every arbitrary amount of minerals between 0 and 2^n (2 power n). In your case you want to cover 0 - 255, which means you'd need 8 triggers (2^8 = 256). (8 * 2 triggers actually, as we have to transfer from unit A and to unit A. See below why.)

So what happens is, you have unit A storing your upgrade level. Then you set the minerals to 0 and transfer unit A to your minerals by binary subtraction/addition.

But since unit A is 0 after that, you need a temporary death counter unit B that always gets added the same amount as unit A gets subtracted. Which means in the end unit A is 0, minerals and unit B have the same number as unit A had before.

Then all you need to do is transfer unit B back into unit A, again using binary subtraction, but of course without modifying the minerals.

All of what I wrote above happens within 2*8 triggers in the same trigger loop.
It is recommended that you use Hyper Triggers.
They are not absolutely necessary, but they practically nullify the delay between when you used your minerals and when they get restored.

Post has been edited 1 time(s), last time on Jan 4 2009, 1:22 pm by NudeRaider. Reason: Typo fixed

so i make triggers for 1, 2, 4, 8, 16, 32, 64, 128, 256?

then i make ones to loop it?

Uhm, kinda... but you don't need 256, as 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 = 255
You really should read the Binary Countoff tutorial.

okay i got it to work now

thanks a lot