Repeat Triggers... Possible? (Topic)

Quote from

Make 2 "blind" triggers (preserved of course) that set the vision based on the DC.
- If Current Player has suffered at least 1 death of 'Vision DC' then turn ON shared vision for <Computer>
- If Current Player has suffered at most 0 deaths of 'Vision DC' then turn OFF shared vision for <Computer>

The reset vision trigger:
C: Always
A: Set deaths for Current Player to 0 for 'Vision DC'
A: preserve

The activation trigger:
C: Current Player controls the most [men] at 'middle'
C: Current Player brings at least one [men] to 'middle'
A: Set deaths for All Players to 1 for 'Vision DC'
A: Set deaths for Foes to 0 for 'Vision DC'

...

This is the most elegant way to do this. You need no switches, only 1 DC, just 4 triggers for as many players as you wish and gives freedom with alliances.

Okay Nude, you beat me :bleh:

I like the way you compute the negation of the condition! The only problem with your triggers is that the set vision actions will be executed every trigger loop. I think I have an idea how to improve the method in case Nikronius wants to insert the sound (which I've seen at the head post) at moments vision turns on and off.

No doubt it is elegant but with alliances it is not very smooth. Consider the case when both players bring equal number of units. In this case both players will get vision, but in some cases their allies wont get vision. For example this will happen in the layout (there are other examples also): P1 allied with P2, P3 allied with P4, P2 and P4 bring equal number of units.

When I was talking about alliances what I kept in mind was: how to make triggers run when allies have got most units at location together. Most likely that cant be made unless you manually count number of units each player has got at location.

Quote

My recommendation on that problem is to use a death counter that signifies is you have vision or not.
Make 2 "blind" triggers (preserved of course) that set the vision based on the DC.
- If Current Player has suffered at least 1 death of 'Vision DC' then turn ON shared vision for <Computer>
- If Current Player has suffered at most 0 deaths of 'Vision DC' then turn OFF shared vision for <Computer>

The reset vision trigger:
C: Always
A: Set deaths for Current Player to 0 for 'Vision DC'
A: preserve

The activation trigger:
C: Current Player controls the most [men] at 'middle'
C: Current Player brings at least one [men] to 'middle'
A: Set deaths for All Players to 1 for 'Vision DC'
A: Set deaths for Foes to 0 for 'Vision DC'
A: preserve

You asked about specific players vs current player:
Always use Current Player whenever possible. Using specific players can get you in trouble with leavers plus usually you need less triggers and it's easier to maintain the map should you want to add something.

Damn I was close!
Before I posted I was poking around with switches and Death Counters, I did something similar to what you proposed but with a different order and now I know that thats why it didnt work...

I thought that if you have two conditions the order didnt matter, I thought the computer verifies if BOTH are true... and the same for the Actions... but now i know that the order DOES matters.

I will try it and post the results.

Note: This is very convenient, practical and yes... elegant.

Nude! I found an improvement of your method so that it is executeing Vision ON/OFF actions only once (well, it have not got an ally thing yet, but that is buggy anyways)!

Quote

TRIGGER
OWNERS: Force 1
CONDITIONS:
    Always
ACTIONS:
    Modify deaths counts for Current Player: subtract 1 for dcVision
    Preserve trigger

TRIGGER // check condition
OWNERS: Force 1
CONDITIONS:
    Current player commands the most Men at lMiddle
    Current Player brings at least 1 Men at lMiddle
ACTIONS:
    Modify deaths counts for Current Player: add 1 for dcVision
    Preserve trigger

TRIGGER // give vision
OWNERS: Force 1
CONDITIONS:
    Current player has suffered at exactly 1 deaths of dcVision
ACTIONS:
    Modify deaths counts for Current Player: set to 3 for dcVision
    Execute AI script +Vi7
    Play WAV
    Preserve trigger

TRIGGER // take vision
OWNERS: Force 1
CONDITIONS:
    Current player has suffered exactly 2 deaths of dcVision
ACTIONS:
    Modify deaths counts for Current Player: set to 0 for dcVision
    Execute AI script -Vi7
    Play WAV
    Preserve trigger

Quote from Nikronius

I thought that if you have two conditions the order didnt matter, I thought the computer verifies if BOTH are true... and the same for the Actions... but now i know that the order DOES matters.

Conditions order does not matter (well... not taking into account one complicated issue with command/bring). Trigger order is what matters! Triggers are checked from top to bottom.

Post has been edited 2 time(s), last time on Jan 24 2009, 2:56 pm by Wormer. Reason: Ouch! Forget to change Player 1!

Some.

Thanks for all the help this thing is working perfectly! now vision goes depending on number of units.

This guy made it look so simple and I was braking my head for 2 days on this. :lol:

if you want to see the final here it is:

Attachments:

--Python 1.3 RC.scx
Hits: 1 Size: 65.83kb

None.

Yeah, Nude is good at explanations

he has got a big practice

Post has been edited 1 time(s), last time on Jan 24 2009, 2:44 pm by Wormer. Reason: grammar error lulz

Some.

wormer, I was thinking that with your method then I could add some sound when you gain vision and when you lose it, cause with the other method I think the sound would be clicking all the time when you maintain vision am i wright?

None.

Quote from Nikronius

wormer, I was thinking that with your method then I could add some sound when you gain vision and when you lose it, cause with the other method I think the sound would be clicking all the time when you maintain vision am i wright?

Yup!

By the way, the order you placed triggers now players wont get vision in case they both have the most number of units at one time.

Some.

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Thanks for the flowers guys.
Good Job on improving my method, Wormer. Adding to the DC is what he needs here. I also have an idea on how to improve your improvement it to work with equal units in the middle. Thx for pointing out the problems. I think I we make a good team.

Hang on...

Quote from Nikronius

I thought that if you have two conditions the order didnt matter, I thought the computer verifies if BOTH are true... and the same for the Actions... but now i know that the order DOES matters.

Order of conditions does not matter. The trigger will only run when all conditions are true. That's it.

Quote from

NudeRaider

Trigger order is obviously important here.

What I meant is that the reset trigger must be before the set vision trigger, or it would always be 0.

Quote from

NudeRaider

What I meant is that the reset trigger must be before the set vision trigger, or it would always be 0.

Do you mean these triggers:

Quote from

NudeRaider

The reset vision trigger:
C: Always
A: Set deaths for Current Player to 0 for 'Vision DC'
A: preserve

The activation trigger:
C: Current Player controls the most [men] at 'middle'
C: Current Player brings at least one [men] to 'middle'
A: Set deaths for All Players to 1 for 'Vision DC'
A: Set deaths for Foes to 0 for 'Vision DC'
A: preserve

before these:

Quote from

NudeRaider

- If Current Player has suffered at least 1 death of 'Vision DC' then turn ON shared vision for <Computer>
- If Current Player has suffered at most 0 deaths of 'Vision DC' then turn OFF shared vision for <Computer>

I thought it does not matter... I mean if it will be vice versa the system will work in the same way (I'm not taking into account affection on allies, just for 2 players) except one case of equal number of units in the middle: when vision triggers are previous to the rest the system doesn't give vision for both players, and in the other case it gives vision for both, am I right?

Quote from

NudeRaider

I also have an idea on how to improve your improvement it to work with equal units in the middle.

Well... Improvement of an improovement, sounds nice

In my case both players got vision with equal number of units in the middle. Once more, I dont know what is better or what Nikronius wants in this particular case.

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Quote from

Wormer

Quote from

NudeRaider

What I meant is that the reset trigger must be before the set vision trigger, or it would always be 0.

Do you mean these triggers:

Quote from

NudeRaider

The reset vision trigger:
[...]
The activation trigger:
[...]

before these:

Quote from

NudeRaider

- If Current Player has suffered at least 1 death of 'Vision DC' then turn ON shared vision for <Computer>
- If Current Player has suffered at most 0 deaths of 'Vision DC' then turn OFF shared vision for <Computer>

No, I meant "reset dc" before "set dc". Because "always -> reset" after "set dc" would mean that the dc is always 0 thus you never get vision.

However to my promised improvement:
It proved to be more complex than I thought and I was also distracted a lot. This is what I found so far, and at first glance it solves the "set vision only once" problem as well as the "equal units in the middle" problem.
Right now I have other things to attend to but I thought I throw it out there so you can guys check if I made a mistake and/or find possible improvements/fixes. I'll check back later on it.

nvm - it's not working. Check my next post

Also: IMO when equal units are in the middle there should be no vision for anyone. However in my solution it just favors the player with lower player number. But imo this should be no big problem, as usually the equal units situation fixes itself pretty fast.

Post has been edited 1 time(s), last time on Jan 24 2009, 8:35 pm by NudeRaider.

OMG, I've stopped to understand anything :ermm:

Just to clearfy, do you refer to the "equal units in the middle" problem as to "when two enemies bring equal number of units to the middle their allies might not recieve vision"?

Wowish, Nude =) I cant get the idea of those last triggers of yours :unsure:

Let's see what happens in case I (P1) got the most units in the middle and my ally (P2) has not got units in the middle at all.
Initially: dcVision(P1) is 0, dcVision(P2) is 0
T1(P1) (after the first trigger (T1) executes for me (P1) ): [no changes] (subtracting 1 from 0 is 0)
T2(P1): dcVision(P1) is 1, dcVision(P1) is 1 (I brought the most units to the middle)
T3(P1): dcVision(P1) is 10, dcVision(P1) is 1 (P8 vision is ON for me)
T4(P1): [no changes] (obviously, the trigger not runs)
T1(P2): dcVision(P1) is 10, dcVision(P1) is 0 (because it subtracts 1)
T2(P2): [no changes] (because P2 has not got any units in the middle)
T3(P2): [no changes] (trigger not runs)
T4(P2): [no changes] (trigger not runs)

The trigger previous to the last (T3) doesn't run for my ally, and he doesn't receive P8 vision.
Something is wrong...

Post has been edited 5 time(s), last time on Jan 24 2009, 5:39 pm by Wormer.

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Quote from

Wormer

OMG, I've stopped to understand anything :ermm:

Just to clearfy, do you refer to the "equal units in the middle" problem as to "when two enemies bring equal number of units to the middle their allies might not recieve vision"?

Yes. What other problem is there?

Alright... I finally thought it through - completely. Gawd how I hate cross-player-and-variable-alliances triggers. Always gives me a headache.
And yes, what I posted before was just half done and not working.

Alright here are my triggers:

The idea behind these triggers is that I have 2 triggers that check the condition. One to maintain the "vision has been set" state and one to initiate the "vision has to be set once now" state.
And of course that I added a condition that if the vision is being maintained by any player already, then no player can initiate the vision giving. This prevents equal-units-at-middle screw ups.
All the rest is basically the same.

And just in case someone is interested (not that I'd think anyone else besides Wormer would be that hardcore anyway...

) here's a detailed table on how these triggers work in various scenarios. Creating that table was tedious, but helped me realizing where the problems are and what the triggers must accomplish. Thanks for initiating that thought, Wormer.

Scenario: P1 + P2 vs P3 + P4

Code

Loop Playr Trig dcP1 dcP2 dcP3 dcP4 Notes
0 0 0 0 0 0 0
NEW EVENT: P1 brings units to middle
1 1 1 0 --- --- ---
1 1 2 1 2 0 0
1 1 3 doesn't run
1 1 4 3 --- --- --- P1 gets vis
1 1 5 doesn't run
1 2 1 --- 1 --- ---
1 2 2 doesn't run
1 2 3 doesn't run
1 2 4 --- 3 --- --- P2 gets vis
1 2 5 doesn't run
P3 & 4 only execute their first trigger: subtract 1 from 0
2 1 1 2 --- --- ---
2 1 2 doesn't run
2 1 3 3 4 1 1
2 1 4 doesn't run
2 1 5 doesn't run
2 2 1 --- 3 --- ---
2 2 2 doesn't run
2 2 3 doesn't run
2 2 4 doesn't run
2 2 5 doesn't run
P3 & 4 only execute their first trigger: subtract 1 from 1
*** Repeat dc changes of Loop 2 until new event ***
NEW EVENT: P3 brings most units to middle
3 1 1 2 --- --- ---
3 1 2 doesn't run
3 1 3 doesn't run
3 1 4 doesn't run
3 1 5 0 --- --- --- P1 loses vis
3 2 1 --- 2 --- ---
3 2 2 doesn't run
3 2 3 doesn't run
3 2 4 doesn't run
3 2 5 --- 0 --- --- P2 loses vis
3 3 1 --- --- 0 ---
3 3 2 --- --- 1 2
3 3 3 doesn't run
3 3 4 --- --- 3 --- P3 gets vis
3 3 5 doesn't run
3 4 1 --- --- --- 1
3 4 2 doesn't run
3 4 3 doesn't run
3 4 4 --- --- --- 3 P4 gets vis
3 4 5 doesn't run
4 4 1 --- --- 2 ---
4 3 2 doesn't run
4 3 3 1 1 3 4
4 3 4 doesn't run
4 3 5 doesn't run
4 4 1 --- --- --- 3
4 4 2 doesn't run
4 4 3 doesn't run
4 4 4 doesn't run
4 4 5 doesn't run
P1 & 2 only execute their first trigger: subtract 1 from 1
*** Repeat dc changes of Loop 4 until new event ***
NEW EVENT: P2 and P3 brings most units to middle
I'm not elaborating on this. Basically what happens is that only the maintain trigger for P3 fires, because not All Players have 0 deaths of dcVision.

ANOTHER EVENT: Should no one have the middle currently and 2 unallied players take the middle the same time with the same amount of units the player with the lower number will get the middle. Imba, but w/e.

If I haven't confused myself this should get rid of both problems we discussed.

Quote from

NudeRaider

Quote from

Wormer

OMG, I've stopped to understand anything :ermm:

Just to clearfy, do you refer to the "equal units in the middle" problem as to "when two enemies bring equal number of units to the middle their allies might not recieve vision"?

Yes. What other problem is there?

I've asked just to make sure, because we've also discussed what to do with vision in the same case. Now that is clear.

Nice job, Nudeguy! =) I've looked into triggers and examined the table. What you've done should work fine and the idea is clear now.

Few minor notes:

1. You have forgot about the other players in the map (computer and probably observers). If you have the condition "All Players has suffered at most 0 deaths of dcVision" and actions like "Modify deaths counts for All Players: add 1 for dcVision" you either should have a trigger which clears deaths for that players or change All Players to Force 1 everywhere.

Possible fix of the problem (Fix1):

2. In the table you have a mistake at line (Loop:3, Player:3, Trig:2). The trigger wont run because P4 still has 1 deaths of dcVision, though it will run the next loop exactly as you wrote.

More things I want to point out:

1. You haven't mentioned another interesting event in your table when allies both have most units in the middle. The examination of this case leads to conclusion that everything will work fine.

2. One more point was not mentioned: what if someone leaves the game? In the case his DC dcVision will retain the last assigned value. Triggers will work fine thanks to death conditions for gropus accumulate values only from active players and thanks to set deaths actions affect only active players (active player is the player which present in the game).

3. When you have triggers dealing with alliances even more problems arise. Your method works absolutely perfect when alliance relation is an equivalence relation and when it is static in time.

Probably you remember the huge post of mine which noone read. I'm elaborating into similar problems there. Let me cite.

Quote from

Wormer

I want to introduce some conventional signs for convenience. I will write the statement "P2 is an ally of P1" (in other words "P1 has an ally flag set to P2" or "P1 considers P2 an ally") as A(P1,P2) and it's negation "P2 is a foe of P1" (in other words "P1 has not an ally flag set to P2" or "P1 considers P2 an enemy") as E(P1,P2).

When I am talking about equivalence relation I mean exactly the next property: "For all players Pi and Pj A(Pi,Pj) implies A(Pj,Pi)"

Exactly the words I want to say there concerning your triggers:

Quote from

Wormer

The method should be perfect when there are distinct coalitions of players. ~~The~~ coalitions are foed with each other and all players are allied within the coalition. This should suffice for a normal melee game. But it raises an interesting questions [...] in some... unusual cases. Let me elaborate.

So, the coalition is the maximal group of players which are allied with each other.

3.1 Lets look thoroughly into the case when alliance picture is dynamic.

3.1.1 The simpliest case: two players (P1 and P2) were allied and P1 had the most units in the middle. P1 and P2 both have vision ON. Then P1 declares war to P2, but P2 still has got vision, because P1 still "maintaining" his vision state.

Possible fix of the problem (Fix2):

3.1.2 Another case of dynamic relations: two players (P1 and P2) were not allied and P1 had the most units in the middle. P1 have vision ON, P2's vision is OFF. P1 declares alliance to P2. It does not matter whether P2 considers P1 an enemy or an ally. In both cases P2 wont get vision before P1 retakes the middle.

I dont see a fast fix of your triggers in this case. This last problem requires revision of the system which I give further.

3.2 We have nonequivalence relation now: E(P1,P2) AND A(P2,P1).

3.2.1 Let's assume events are developing the next way. P1 leaves middle and we have the starting situation: noone controls the middle, noone have vision, all DCs are 0. P1 takes middle. P2 not getting vision because of E(P1,P2). Now P2 have to struggle for middle if he wants vision. Quite fair.

3.2.2 If events were developping the other way. After P1 leaves middle P2 gets it. P2 sets vision of the middle to P1 because A(P2,P1), which is the P2's problems he is still allied to P1. Fair again.

In conclusion of 3.2 we got no problems there.

3.3 Even more complicated questions arise. Should we turn off vision for a player which was dropped from a coalition by it's member (by declaring war), but this member (which dropped the player) is not the one which controls the middle (and thus maintaning the dropped player's vision)? Get it?

3.4 Who knows what's else? :unsure:

4. Addressing the problem, I've made a revision of the system. The constant nForceSize is the number of players in Force 1.

Now it looks like this:

Let's assume we have a general setup: P1, P2, P3, P4 make up Force 1 (therefor nForceSize is 4), there are probably other players which we're not interested in. There are no units in the middle at start.

Triggers in case nForceSize is 4:

Let's see what we have in various cases. I am discussing execution of triggers on an imaginable "Free For All" game.

Initially I have all 4 players (P1, P2, P3, P4) in the game in relation of war to each other.

Note: I'm not specifying lines for triggers which do not run. Loop notation is EventNumber.LoopNumber, where LoopNumber 0 means the state just before event EventNumber happens.

Trace:

Quote

Loop    Player  Trigger dcP1    dcP2    dcP3    dcP4    Notes
1.0     -       -       0       0       0       0
EVENT 1:    P1 brings a unit to middle
1.1     P1      T5      1       -       -       -
1.2     P1      T3      21      -       -       -       P1 vision ON
1.2     P1      T5      22      -       -       -
1.3     P1      T4      21      -       -       -
1.3     P1      T5      22      -       -       -
(the last loop repeats until situation changes)
2.0     -       -       22      0       0       0
EVENT 2:    P2 brings a unit to middle
            P1 and P2 both have most units
2.1     P1      T4      21      -       -       -
2.1     P1      T5      22      -       -       -
2.1     P2      T5      18      1       -       -
2.2     P1      T1      0       1       -       -       P1 vision OFF
2.2     P1      T5      1       0       -       -
2.2     P2      T5      0       1       -       -
(repeats)
// we can see, that once P1 and P2 got most units together
// P1 will loose vision and P2 wont get it until situation changes
3.0     -       -       0       1       0       0
EVENT 3:    P1 got beaten, only P2 has got most units
3.1     P2      T3      -       21      -       -       P2 vision ON
3.1     P2      T5      -       22      -       -
3.2     P2      T4      -       21      -       -
3.2     P2      T5      -       22      -       -
(repeats)
4.0     -       -       0       22      0       0       
EVENT 4:    P2 has other important things to do and leaves
            No units in the middle
4.1     P2      T4      -       21      -       -       one loop delay 
4.2     P2      T1      -       0       -       -       P2 vision OFF
4.3     -       -       -       -       -       -       no trigger runs
(repeats)
5.0     -       -       0       0       0       0
EVENT 5:    Suddenly P1 and P2 workers meet in the middle
            Both players control the most at once
5.1     P1      T5      1       -       -       -
5.1     P2      T5      0       1       -       -
5.2     P1      T5      1       0       -       -
5.2     P2      T5      0       1       -       -
(repeats)
6.0     -       -       0       1       0       0
EVENT 6:    Players got frightened and run, no units in the middle at once!
6.1     P2      T2      -       0       -       -       failsafe runs!
6.2     -       -       -       -       -       -       no trigger runs
(repeats)
7.0     -       -       0       0       0       0
EVENT 7:    P1 declares ally to P3 and returns to the middle
            A(P1,P3), P1 controls the most
7.1     P1      T5      1       -       1       -
7.1     P3      T2      1       -       0       -       failsafe again! see the difference?
7.2     P1      T3      21      -       -       -       P1 vision ON
7.2     P1      T5      22      -       1       -
7.2     P3      T2      22      -       0       -
7.3     P1      T4      21      -       -       -
7.3     P1      T5      22      -       1       -
7.3     P3      T2      22      -       0       -
(repeats)
8.0     -       -       22      0       0       0
EVENT 8:    Finally P3 wakes up and declares ally to P1
            A(P3,P1), P1 still controls the most
8.1     P1      T4      21      -       -       -
8.1     P1      T5      22      -       1       -
8.1     P3      T3      22      -       21      -       P3 vision ON
8.2     P1      T4      21      -       -       -
8.2     P1      T5      22      -       22      -
8.2     P3      T4      22      -       21      -
(repeats)
9.0     -       -       10      0       9       0
EVENT 9:    P3 sends reinforcements to the middle
            Suddenly happens he got the same numer of men as P1
            P1 and P3 both have the most
9.1     P1      T4      21      -       -       -
9.1     P1      T5      22      -       22      -
9.1     P3      T4      -       -       21      -
9.1     P3      T5      23      -       22      -
9.2     P1      T4      21      -       -       -
9.2     P1      T5      22      -       23      -
9.2     P3      T4      -       -       21      -
9.2     P3      T5      23      -       22      -
(repeats)
10.0    -       -       23      0       22  0
EVENT 10:   Here comes an impudent P2 with a huge army
            Only P2 controls the most
10.1    P1      T4      21      0       22      -
10.1    P1      T5      22      0       23      -
10.1    P2      T5      18      1       19      -
10.1    P3      T1      -       -       0       -       P3 vision OFF
10.2    P1      T1      0       -       -       -       P1 vision OFF
10.2    P2      T3      -       21      -       -       P2 vision ON
10.2    P2      T5      -       22      -       -
10.3    P2      T4      -       21      -       -
10.3    P2      T5      -       22      -       -
(repeats)
11.0    -       -       0       22      0       0
EVENT 11:   P1 and P3 wake up P4, altogether they decide to take a revenge
            P4 declares ally to P1 and P3, P1 declares ally to P4
            Noobish still half-asleep P3 forgets to ally P4
            Altogether they attack middle
            P3 and P4 accidently have equal number of units
            By accidence P2 has got the same number of units!
            A(P4,P1), A(P4,P3), A(P1,P4)
            Everyone except P1 has got equal (the most) number of units
11.1    P2      T4      -       21      -       -
11.1    P2      T5      -       22      -       -
11.1    P3      T5      1       18      1       -
11.1    P4      T5      2       14      2       1       do you see why we need nForceSize^2?
11.2    P1      T3      21      -       -       -       P1 vision ON, glitch!
11.2    P2      T1      -       0       -       -       P2 vision OFF
11.2    P2      T5      17      1       0       0
11.2    P3      T5      18      0       1       -
11.2    P4      T5      19      -       2       1
11.3    P1      T1      0       -       -       -       P1 vision OFF
11.3    P2      T5      -       1       0       0
11.3    P3      T5      1       0       1       -
11.3    P4      T5      2       -       2       1
11.4    P1      T3      21      -       -       -       P1 vision ON, glitch!
11.4    P2      T5      17      1       0       0
11.4    P3      T5      18      0       1       -
11.4    P4      T5      19      -       2       1
(last two loops repeat)
// so we see, this is not perfect too: P1 vision glitches, everything else works fine
// the method glitches sometimes when 3 players have the most number of units
// the situation will normalize very soon when someone got leadership
(to be continued...)

So we've seen the proposed method is not perfect in all cases too, but it is much more stable and works fine when two players has got equal numbers of units in the middle (it forbits vision for all of them) and in some other cases when alliance status changes dynamcly during the game.

;-)

Post has been edited 4 time(s), last time on Jan 26 2009, 8:38 am by Wormer. Reason: I was impercise

Some.

Dam, it says post is too large, thats why I'm double posting. :ohno:

I've made an improovement. This might have another glitch, who wanna find it as an excersize?

Triggers 1

Quote

TRIGGER // T1: take vision
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least 2*nForceSize+2 deaths of dcVision
  Current player has suffered at most nForceSize^2+nForceSize+2 deaths of dcVision 
  // nForceSize*(nForceSize-1)+2*nForceSize+2=nForceSize^2+nForceSize+2
ACTIONS:
  Modify deaths counts for Current Player: set to 0 for dcVision
  Execute AI script -Vi7
  Play WAV
  Preserve trigger

TRIGGER // T2: give vision failsafe
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least 1 deaths of dcVision
  Current player has suffered at most nForceSize deaths of dcVision
  Allies bring at most 0 Men to lMiddle
  Current Player bring at most 0 Men to lMiddle
ACTIONS:
  Modify deaths counts for Current Player: set to 0 for dcVision
  Preserve trigger

TRIGGER // T3: give vision
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least nForceSize+1 deaths of dcVision
  Current player has suffered at most 2*nForceSize+1 deaths of dcVision
ACTIONS:
  Modify deaths counts for Current Player: set to nForceSize^2+nForceSize+2 for dcVision
  Execute AI script +Vi7
  Play WAV
  Preserve trigger

TRIGGER // T4: one loop give vision delay (another failsafe)
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least 1 deaths of dcVision
  Current player has suffered at most nForceSize deaths of dcVision
ACTIONS:
  Modify deaths counts for Current Player: set to nForceSize+1 for dcVision
  Preserve trigger

TRIGGER // T5: retain vision state
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least nForceSize^2+nForceSize+3 deaths of dcVision
ACTIONS:
  Modify deaths counts for Current Player: set to nForceSize^2+nForceSize+2 for dcVision
  Preserve trigger

TRIGGER // T6: init and maintain allies, disable foes
OWNERS: Force 1
CONDITIONS:
  Current player commands the most Men at lMiddle
  Current Player brings at least 1 Men to lMiddle
ACTIONS:
  Modify deaths counts for Force 1: add 1 for dcVision
  Modify deaths counts for Foes: subtract 1+nForceSize for dcVision  
  Preserve trigger

And finally the method that should be glitchless.

By "glitchless" I mean exactly that player P have vision when (and only when):
1. P brings at least 1 men to middle AND P controlls the most units in the middle AND noone, except probably player's P true allies, controls the most
2. One of player's P true allies P' brings at least 1 men to middle AND P' controlls the most units in the middle AND noone, except probably player's P (P is not a mistake!) true allies, controls the most
3. When situation changes vision modifies accordingly

Player's P true ally P' is a player which is in player's P coalition (in other words A(P,P') AND A(P',P)).

Triggers 2

Quote

TRIGGER // T1: take vision
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least 2*nForceSize+2 deaths of dcVision
  Current player has suffered at most 2*nForceSize^2+nForceSize deaths of dcVision 
  // 2*(nForceSize+1)*(nForceSize-1)+2*nForceSize+2=2*nForceSize^2+nForceSize
ACTIONS:
  Modify deaths counts for Current Player: set to 0 for dcVision
  Execute AI script -Vi7
  Play WAV
  Preserve trigger

TRIGGER // T2: give vision failsafe
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least 1 deaths of dcVision
  Current player has suffered at most nForceSize deaths of dcVision
  Allies bring at most 0 Men to lMiddle
  Current Player bring at most 0 Men to lMiddle
ACTIONS:
  Modify deaths counts for Current Player: set to 0 for dcVision
  Preserve trigger

TRIGGER // T3: give vision
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least nForceSize+1 deaths of dcVision
  Current player has suffered at most 2*nForceSize+1 deaths of dcVision
ACTIONS:
  Modify deaths counts for Current Player: set to 2*nForceSize^2+nForceSize for dcVision
  Execute AI script +Vi7
  Play WAV
  Preserve trigger

TRIGGER // T4: one loop give vision delay (another failsafe)
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least 1 deaths of dcVision
  Current player has suffered at most nForceSize deaths of dcVision
ACTIONS:
  Modify deaths counts for Current Player: set to nForceSize+1 for dcVision
  Preserve trigger

TRIGGER // T5: retain vision state
OWNERS: Force 1
CONDITIONS:
  Current player has suffered at least 2*nForceSize^2+nForceSize+1 deaths of dcVision
ACTIONS:
  Modify deaths counts for Current Player: set to 2*nForceSize^2+nForceSize for dcVision
  Preserve trigger

TRIGGER // T6: init and maintain allies, disable foes
OWNERS: Force 1
CONDITIONS:
  Current player commands the most Men at lMiddle
  Current Player brings at least 1 Men to lMiddle
ACTIONS:
  Modify deaths counts for Force 1: add 1 for dcVision
  Modify deaths counts for Foes: subtract 2*(nForceSize+1) for dcVision  
  // 1+(2*nForceSize+1)=2*(nForceSize+1)
  Preserve trigger

Who wanna check if I'm right or find a mistake? innocent:

Some.

well guys since 6 or 7 posts ago this topic is too advanced for me :lol:

in general we found the main solutions and I have to say that you two can be very good programmers (if you arent yet)

gg for me

its still an interesting point of view what you just posted worm, is true that there are few problems that become little bit more complicated when we bring in alliances.

None.

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Well to be honest, Wormer overdid this a little imo. I was with him when he suggested the 2 fixes of my triggers. But when he started with nForceSize it became simply impractical. No offense, Wormer, I really have respect for what you were doing but you tried to perfect the system for every possible situation no matter the effort. While this is nice as an exercise it's not what Nicronius wanted.

Just so you understand Nikronius, when Wormer started using nForceSize as a variable Player number he implied that you make copies of the triggers for each possible value of nForceSize and a seperate trigger that calculates it for each trigger loop.
Imo this is overkill, as it only gets rid of minor problems that are well acceptable.
You don't need to understand the discussion around the triggers below, but they are still quite simple and I am sure you will understand them. Even if not, just copy them.

So to conclude this help topic I suggest you use these triggers:

Possible fix of the problem (Fix2):

Quote from Nikronius

in general we found the main solutions

The question is how far do you want to go. On some level you just can put up with some unwanted behaviour.

Quote from Nikronius

its still an interesting point of view what you just posted worm, is true that there are few problems that become little bit more complicated when we bring in alliances.

Well, I still have not got much confidence what I posted the last is totally true. Someone should verify I've not done a mistake.

These triggers are very "archivated" and use only one Death Counter. I am sure this could be done more clearly using more death counters, switches and specifying some triggers for each player.

Now I can answer the question:

Quote from Nikronius

I have a question, you think is better to use EACH PLAYER their own triggers or for sake of less triggers is it better to use the "Current Player" option.

When making triggers try to make them in the most graphic way. Usually less triggers useing "Current Player" are more graphic than more triggers copied for each player. Usually but as we can see not always. Dont overcomplicate things for the sake of less triggers, but try to make less triggers for the sake of their clearness. You have got a good example what you might get in result.

You know, sometimes minimizeing number of triggers is nice just to see what is the minimal solution, what you can do and just for fun. But when makeing real maps never write triggers like I did less you have to do that in case of emergency. Dont follow my example.

Another example how not to do is a program in my signature. It is written in very "archivated" minimalistic manner, so you can't even understand what it does... Of course noone writes like this in real life!

Quote from

NudeRaider

Just so you understand Nikronius, when Wormer started using nForceSize as a variable Player number he implied that you make copies of the triggers for each possible value of nForceSize and a seperate trigger that calculates it for each trigger loop.

I think you dont get it right Nude

I dont imply to make copies of triggers for each possible value of nForceSize. nForceSize is a constant for a particular map. For the map with Force 1 consisting of 4 players (like Nikronius Python map) it is just a number 4. When makeing triggers you should substitute nForceSize with 4 and compute expressions. I've even wrote triggers with proper substitution:

Quote from

Wormer

Triggers in case nForceSize is 4:

I've wrote triggers in general case because:
1. It is much easier to see forest behind the trees and understand an idea, than if I had written final values.
2. In general case my method could be applied to force cosisting of any number of players (for example if someone decides to make a similar map for Hunters).

EDIT:

Quote from

NudeRaider

Well to be honest, Wormer overdid this a little imo. [...] But when he started with nForceSize it became simply impractical. No offense, Wormer, I really have respect for what you were doing but you tried to perfect the system for every possible situation no matter the effort.

I dont deny I little overdo, but what I did cannot be impractical. You just write those 6 triggers and the system should work. I am just a kind of man used to carry out job through. I'm sorry, can't do anything about it :disgust:

Post has been edited 2 time(s), last time on Jan 26 2009, 3:34 pm by Wormer.

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Well then I indeed misunderstood it. So sorry for calling it impractical. And as I already said I have respect for what you did.
I didn't try to understand it in all detail. Just tried to understand the general thought. So no, I haven't checked your triggers for mistakes, except the changes you made in Fix 1 and 2. And I won't.

So maybe Nikronius should just go for your revised triggers (nForceSize = 4) and see if they work?
(Yes, we have to go back to actually helping this guy and recommending something to him as he isn't following the discussion.)

Quote from

NudeRaider

Well then I indeed misunderstood it. So sorry for calling it impractical. And as I already said I have respect for what you did.

Please, no sorry. You just misunderstood and I just corrected what you understood wrong. That's all. Respect... well... I'm pleased to hear that, but I would be really happy if someone finally understand my triggers. Without that my work is pointless.

Quote from

NudeRaider

I didn't try to understand it in all detail. Just tried to understand the general thought.

I realize that understanding the general thought of triggers is hard, because I've packed like 4 death counters and a switch into one DC.

These triggers need explanations. I could provide them with an equivalent unpacked variant of triggers. For now I've provided only the trace as a vague "explanation".

Quote from

NudeRaider

So maybe Nikronius should just go for your revised triggers (nForceSize = 4) and see if they work?
(Yes, we have to go back to actually helping this guy and recommending something to him as he isn't following the discussion.)

Nikronius most likely already decided what variant he will use in his map. Actually he wanted to have only 2 players that's why all these problems with allies don't directly concern him. But he still might be interested in more general results.

If Nikronius is really interested what can I suggest him. First of all he should try copying these triggers and see if they work. After that he could simply examine and understand each step of traces we provided (without understanding what triggers do), why is it done this way but not another. This will be a very usefull excercise for him. At that time I'll try to come up with "unpacked" variant of the system and explanations how it works.

Nikronius, to my mind there is nothing impossible for you in understanding how triggers work (at least how they work in particular cases). Once more, this will be very usefull experience for you if you do that. Of course come up with any quesions you have, we will be glad to explain you.

NudeRaider, If he is not interested then we can consider the question answered. But still I will be glad to discuss problems till you're interested in them, because I find this theme very interesting.

If noone besides me is interested then... well...

then my job is done and I retire for good :bye2: