Report, edit, etc...Posted by JaFF on 2006-10-26 at 04:34:50
I'm thinking about my next map (probably) and I need enough theory to make it real in my head first.
OK, the problem is:
At first, I have 2 deathcounters - D1 and D2.
D1=N (N<>0)
D2=0
I want it to be like this in the end:
D1=N
D2=N
And I don't want to write a "if" for every N possible. Basically I want to copy the meaning of D1 into D2 without loosing it in D1.
I had an idea of using switches to hold the value (like in the currently opened topic), but that requires a lot of switches. But it can be pulled off within 1 trigger cycle, which is good. I would look like this:
S1 is the set ow switches that will hold the value of D1. S2 hold the value of D2.
First I transfer the value of D1 to S1 and S2, and loose the value in D1 by doing so. Then, the switches allow me to restore D1 from S1 or S2, and apply the value to D2.
So ... any other ideas?
OK, the problem is:
At first, I have 2 deathcounters - D1 and D2.
D1=N (N<>0)
D2=0
I want it to be like this in the end:
D1=N
D2=N
And I don't want to write a "if" for every N possible. Basically I want to copy the meaning of D1 into D2 without loosing it in D1.
I had an idea of using switches to hold the value (like in the currently opened topic), but that requires a lot of switches. But it can be pulled off within 1 trigger cycle, which is good. I would look like this:
S1 is the set ow switches that will hold the value of D1. S2 hold the value of D2.
First I transfer the value of D1 to S1 and S2, and loose the value in D1 by doing so. Then, the switches allow me to restore D1 from S1 or S2, and apply the value to D2.
So ... any other ideas?
Report, edit, etc...Posted by Red2Blue on 2006-10-26 at 04:48:29
Why not just use burrowed units within two locations and then center the location on each stack when the variable calls for it?
such as having two stacks of zerglings giving them away to another computer player as a way to tally the death count, and have a burrowed unit of different types on each stack and centering a specific location on that unit as a means of switching stacks yet still retaining all the conditions and actions that that specific location has?
Sorry... I have an addiction for creating all my triggers with burrowed units. v_v
ADDITION:
Being more specific, each stack taking the place of each death counter. D1 and D2.
And the specific location retaining the conditions and actions of both D1 and D2.
such as having two stacks of zerglings giving them away to another computer player as a way to tally the death count, and have a burrowed unit of different types on each stack and centering a specific location on that unit as a means of switching stacks yet still retaining all the conditions and actions that that specific location has?
Sorry... I have an addiction for creating all my triggers with burrowed units. v_v
ADDITION:
Being more specific, each stack taking the place of each death counter. D1 and D2.
And the specific location retaining the conditions and actions of both D1 and D2.
Report, edit, etc...Posted by JaFF on 2006-10-26 at 05:11:21
QUOTE(Red2Blue @ Oct 26 2006, 11:48 AM)
such as having two stacks of zerglings giving them away to another computer player as a way to tally the death count, and have a burrowed unit of different types on each stack and centering a specific location on that unit as a means of switching stacks yet still retaining all the conditions and actions that that specific location has?
I don't understand this part. Rephrase it better
Report, edit, etc...Posted by Red2Blue on 2006-10-26 at 05:20:51
Assuming you are using only one computer player to determine the amount of count per pile.
Two piles with a burrowed unit underneath each pile:
Pile 1 (burrowed hydra)
Pile 2 (burrowed defiler)
And one location:
Location 1
Each pile can hold an infinite amount of units as they need be (though this is unlikely that you will need more than 100).
You will create units as you need them and remove when unneeded.
Each unit in each pile consitutes one unit of measure as a death counter adds one and etc.
To count each unit of measure you would use a bring to statement in the conditions statement.
In this case we can use zerglings as units of measure.
Say D1 demands 15 as a statement for some reason...
We would create 15 burrowed zerglings at D1.
Then we would need a trigger to check D1 if the condition is met. This can be automated or triggered. And to check, you would simply center Location 1 onto the Hydralisk owned by that computer. To check D2 you would center on the defiler.
Let's say the condition for 15 burrowed zerlings or D1=15 is allowing you to command a engineering bay.
We could also use D1's commands, and implement them with D2.
v_v but beyond this is complicated and I need to know specifically what you're trying to do... to give you a better explaination.
elaborate your goal. ty.
Report, edit, etc...Posted by JaFF on 2006-10-26 at 05:39:24
You don't understand...
Imagine that you get a deathcounter value (only a deathcounter), and you must make another deathcounter have the same value, without loosing the value in the first one.
The value of the first one can be anything from 1 to 50000, let's say. I don't want to make thousands of triggers for each value.
I can't use the "bring" condition because I would need thousands of conditions for each possible value.
...Or I don't understand you and look stupid. Someone who understood what Red2Blue said, please rephrase it for me...
Imagine that you get a deathcounter value (only a deathcounter), and you must make another deathcounter have the same value, without loosing the value in the first one.
The value of the first one can be anything from 1 to 50000, let's say. I don't want to make thousands of triggers for each value.
I can't use the "bring" condition because I would need thousands of conditions for each possible value.
...Or I don't understand you and look stupid. Someone who understood what Red2Blue said, please rephrase it for me...
Report, edit, etc...Posted by Zeratul_101 on 2006-10-26 at 10:47:00
binary cutoffs ftw!
just use two sets of them. use the first one to move all of D1 into a 'holder' DC. then use the second set of cutoffs to move all of 'holder' into D1 and D2.
ADDITION:
take a look at the fractional reducer if you want to see details. the first set would be 'a - b' and the second set would be 'add to c'
just use two sets of them. use the first one to move all of D1 into a 'holder' DC. then use the second set of cutoffs to move all of 'holder' into D1 and D2.
ADDITION:
take a look at the fractional reducer if you want to see details. the first set would be 'a - b' and the second set would be 'add to c'
Report, edit, etc...Posted by ZPD on 2006-10-26 at 15:53:06
I'll try to clarify Zeratul's post, if I interpretted it correctly.
Have a set of triggers to move the daeth counts from one unit into two units in a narrowing list.
Example;
P1 suffers at least 1024 deaths of [Marine]
==Add 1024 deaths to [Firebat] for P1
==Add 1024 deaths to [Medic] for P1
==Subtract 1024 deaths for [Marine] for P1
P1 suffers at least 512 deaths of [Marine]
==Add 512 deaths to [Firebat] for P1
==Add 512 deaths to [Medic] for P1
==Subtract 512 deaths for [Marine] for P1
You halve the numbers each time until you reach one; 256, 128, 64, 32, 16, 8, 4, 2, 1.
If your death counts will be higher, add a trigger of a higher value above the 1024 trigger (2048, 5096, etc.).
Now you takes the deaths from the Medic to the Marine again.
P1 suffers at least 1024 deaths of [Medic]
==Add 1024 deaths to [Marine] for P1
==Subtract 1024 deaths for [Medic] for P1
P1 suffers at least 512 deaths of [Medic]
==Add 512 deaths to [Marine] for P1
==Subtract 512 deaths for [Medic] for P1
And again you count down to one.
As long as all these triggers are in one continuous list, or you don't have a trigger using any of the death counts inbetween those triggers, and there are no waits to interrupt them, then there will be no problem with using the number from the [Marine] or [Firebat] deathcount because by the time they're used they'l both have their correct values.
Have a set of triggers to move the daeth counts from one unit into two units in a narrowing list.
Example;
P1 suffers at least 1024 deaths of [Marine]
==Add 1024 deaths to [Firebat] for P1
==Add 1024 deaths to [Medic] for P1
==Subtract 1024 deaths for [Marine] for P1
P1 suffers at least 512 deaths of [Marine]
==Add 512 deaths to [Firebat] for P1
==Add 512 deaths to [Medic] for P1
==Subtract 512 deaths for [Marine] for P1
You halve the numbers each time until you reach one; 256, 128, 64, 32, 16, 8, 4, 2, 1.
If your death counts will be higher, add a trigger of a higher value above the 1024 trigger (2048, 5096, etc.).
Now you takes the deaths from the Medic to the Marine again.
P1 suffers at least 1024 deaths of [Medic]
==Add 1024 deaths to [Marine] for P1
==Subtract 1024 deaths for [Medic] for P1
P1 suffers at least 512 deaths of [Medic]
==Add 512 deaths to [Marine] for P1
==Subtract 512 deaths for [Medic] for P1
And again you count down to one.
As long as all these triggers are in one continuous list, or you don't have a trigger using any of the death counts inbetween those triggers, and there are no waits to interrupt them, then there will be no problem with using the number from the [Marine] or [Firebat] deathcount because by the time they're used they'l both have their correct values.
Report, edit, etc...Posted by JaFF on 2006-10-26 at 16:41:10
A good idea. And without switches. Thanks. 
Maybe someone will post something interesting?..
Maybe someone will post something interesting?..
Report, edit, etc...Posted by Heimdal on 2006-10-26 at 17:01:06
I was gonna say the same thing as Zeratul (and ZPD explained it very well). Probably your best bet. Also note that you're not restricted to just death counts using this; score and resources also work.
Report, edit, etc...Posted by fritfrat(U) on 2006-10-26 at 20:55:57
Personally, I'd just make it so whenever I edited D1 I would edit a, lets say, "DX" as well to keep it exactly the same. Then, you can go ahead and lose the value of DX for a temporary period of time for whenever you need to lose the value, since it will get it back anyways. This may not apply to every situation, but would be a simple fix for those that it does apply for.
Report, edit, etc...Posted by Red2Blue on 2006-11-06 at 04:02:08
I guess that works too........ -_-;;
I guess what I was explaining was a way to get infinite place holders for infinite conditions to use infinite actions to apply for infinite variables in one universalized loop. v_v.. or something... Though, now that I think of that idea, im gonna try to devise something to prove that method works too.
Or I can just be like Legacy and say:
"We have tutorials for everything."
I guess what I was explaining was a way to get infinite place holders for infinite conditions to use infinite actions to apply for infinite variables in one universalized loop. v_v.. or something... Though, now that I think of that idea, im gonna try to devise something to prove that method works too.
Or I can just be like Legacy and say:
"We have tutorials for everything."