Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: Exclusive triggers but with different orders?
Exclusive triggers but with different orders?
Nov 22 2020, 10:26 pm
By: armitage  

Nov 22 2020, 10:26 pm armitage Post #1



I'm trying to do something with an exclusive trigger like the one below:
https://staredit-network.fandom.com/wiki/Queue_or_Exclusive_Triggers

But I can't figure out how to make different ordered versions with death counters.

For example, I want to bring a dropship to *location 1* and a trigger moves it to location A if a foe doesn't have a unit there, or location B if location A is occupied, C if B is occupied etc, but if I bring a dropship to *location 2* it moves it to location C first if unoccupied, then B, then A. Basically I want the map to check if locations A...K don't have another player there, then move the dropship based on the preferred destination order of location 1, 2 ...80. I don't want to have to use a trigger for every combination of number and letter location and it should keep moving the players units brought to the location until switched off.

Any suggestions?



None.

Nov 23 2020, 4:37 am NudeRaider Post #2

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

Did I get this right? You have ...
1) originator locations labeled 1-80
2) destination locations labeled A-K
3) originator 1 that moves forwards through destinations (A-K)
4) originator 2 that moves backwards through destinations (K-A)
5) only teleport to unoccupied destinations

My question when I look at 3) and 4) is what is the direction for the rest of the originators (3-80)?
This makes me think I misunderstood one of the conditions.


Some general thoughts on these kinds of problems:

If you have just 1 unit (or a few that are all different types) that can get teleported:
One trigger per destination. Instead of locations you place neutral burrowed units at the location spots. Then you always center a location on the unit you want to teleport and detect the burrowed unit. Use a 2nd set of destination triggers for the backwards order. You can decide which is which by the burrowed unit type. (e.g. ling = forward, hydra = backward)

If any unit is to be teleported you need a locations and a trigger for each originator. As for the destinations it's a bit tricky. You could again use the burrowed unit trick, but then the physical locations of the destinations matters because you'd cycle through the neutral units by giving to another neutral player and it would always pick the leftmost-topmost unit first. So you'd have just 1 fixed order (or semi-random) in which the locations get checked and it would take a few trigger loops if the first few are occupied. Alternative: You DO make a trigger for each combination using a trigger duplicator.




Nov 23 2020, 6:48 am armitage Post #3



Quote from NudeRaider
Did I get this right? You have ...
1) originator locations labeled 1-80
2) destination locations labeled A-K
3) originator 1 that moves forwards through destinations (A-K)
4) originator 2 that moves backwards through destinations (K-A)
5) only teleport to unoccupied destinations

My question when I look at 3) and 4) is what is the direction for the rest of the originators (3-80)?
This makes me think I misunderstood one of the conditions.

All five points are right, but 3-80 would each have their own preference ranking like KDEFHAJ up to perhaps 7 possible destinations for each origin location?

Quote from NudeRaider
Some general thoughts on these kinds of problems:

If you have just 1 unit (or a few that are all different types) that can get teleported:
One trigger per destination. Instead of locations you place neutral burrowed units at the location spots. Then you always center a location on the unit you want to teleport and detect the burrowed unit. Use a 2nd set of destination triggers for the backwards order. You can decide which is which by the burrowed unit type. (e.g. ling = forward, hydra = backward)

If any unit is to be teleported you need a locations and a trigger for each originator. As for the destinations it's a bit tricky. You could again use the burrowed unit trick, but then the physical locations of the destinations matters because you'd cycle through the neutral units by giving to another neutral player and it would always pick the leftmost-topmost unit first. So you'd have just 1 fixed order (or semi-random) in which the locations get checked and it would take a few trigger loops if the first few are occupied. Alternative: You DO make a trigger for each combination using a trigger duplicator.

Unfortunately I want to use multiples of the same unit and with different players. I will probably end up making many combinations. Below is what I have so far:

Quote
Trigger("Force 1", "Force 2", "Force 3"){
Conditions:
Deaths("Current Player", "Alan Turret", At most, 0);
Switch("Switch2", Set);
Switch("Switch1", Not Set);
Bring("Current Player", "Terran Dropship", "TerraEnter", At least, 1);
Bring("Foes", "Buildings", "Terra", At least, 1);

Actions:
Set Deaths("Current Player", "Bengalaas (Jungle)", Set To, 2);
Set Switch("Switch2", clear);
Set Switch("Switch12", set);
Preserve Trigger();
}

//-----------------------------------------------------------------//

Trigger("Force 1", "Force 2", "Force 3"){
Conditions:
Deaths("Current Player", "Alan Turret", At least, 0);
Switch("Switch1", Set);
Bring("Current Player", "Terran Dropship", "TerraEnter", At least, 1);
Bring("Foes", "Buildings", "Terra", At least, 1);

Actions:
Set Deaths("Current Player", "Bengalaas (Jungle)", Set To, 1);
Set Switch("Switch1", clear);
Set Switch("Switch12", set);
Preserve Trigger();
}

//-----------------------------------------------------------------//

Trigger("Force 1", "Force 2", "Force 3"){
Conditions:
Bring("Current Player", "Terran Dropship", "TerraEnter", At least, 1);
Deaths("Current Player", "Bengalaas (Jungle)", Exactly, 2);
Switch("Switch12", Set);

Actions:
Move Unit("Current Player", "Terran Dropship", 1, "TerraEnter", "Dest1");
Preserve Trigger();
}

//-----------------------------------------------------------------//

Trigger("Force 1", "Force 2", "Force 3"){
Conditions:
Bring("Current Player", "Terran Dropship", "TerraEnter", At least, 1);
Deaths("Current Player", "Bengalaas (Jungle)", Exactly, 1);
Switch("Switch12", Set);

Actions:
Move Unit("Current Player", "Terran Dropship", 1, "TerraEnter", "Dest0");
Preserve Trigger();
}
-Alan turret deaths checks whether the player isn't currently moving units to a different destination. It's reset in another trigger to let the player to move through a different location in the future.
-Bengalaas is the death counter tied to this origin location, the number being one of the destinations A-K.
-Switch12 is the switch for this origin location; each will have its own.



None.

Nov 23 2020, 1:13 pm GGmano Post #4

Mr.Pete-Tong

you need to do alot of triggers for so many combinations. i have 6option combination in my map i needed to do 64 or something around that number just to detect which combination needs to be checked or fired. I used switches for my combinations for excample

condition
switch 1 is cleared
switch 2 is cleared
switch 3 is cleared
switch 4 is cleared
switch 5 is cleared

is one out of many combinations

another could be

condition
switch 1 is cleared
switch 2 is cleared
switch 3 is cleared
switch 4 is cleared
switch 5 is set

that way you can do different combinations with just 5 switches.

Good luck with your combinations sounds like many hours of trigger working to me



Trust is everything

Nov 23 2020, 4:00 pm NudeRaider Post #5

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 armitage
3-80 would each have their own preference ranking like KDEFHAJ up to perhaps 7 possible destinations for each origin location?

-Alan turret deaths checks whether the player isn't currently moving units to a different destination. It's reset in another trigger to let the player to move through a different location in the future.
-Bengalaas is the death counter tied to this origin location, the number being one of the destinations A-K.
-Switch12 is the switch for this origin location; each will have its own.
You're overthinking it a little, I think. But step by step.

You want each origin to have a handpicked order of destinations to check (randomness is not an option, right?) so you somehow have to define those. Thus there's no way around making 80 triggers (1 per origin). But then we can use some logic fu to save triggers and just using 1 variable (death counter) to store the order in. I'll call this rank. The locations with rank 1 gets checked first, rank 2 second, etc. To do this with just 1 variable you correlate the destinations A-G to player numbers 1-7 (if you don't have more than 8 locations). So Benglaas count for P1 stores the rank of destination A, the count for P2 stores the rank of destination B and so forth. This is what it would look like in triggers:

Origin 1 ABCDEFG
Players

  • Player Force(s)
  • Conditions

  • Current Player brings "any unit" to location "Origin 1"
  • Actions

  • Set deaths for Benglaas for P1 to 1 A = rank 1
  • Set deaths for Benglaas for P2 to 2
  • Set deaths for Benglaas for P3 to 3
  • Set deaths for Benglaas for P4 to 4
  • Set deaths for Benglaas for P5 to 5
  • Set deaths for Benglaas for P6 to 6
  • Set deaths for Benglaas for P7 to 7
  • Move location "teleport origin" to "any unit" owned by Current Player at location "Origin 1"


  • Origin 2 GFEDCBA
    Players

  • Player Force(s)
  • Conditions

  • Current Player brings "any unit" to location "Origin 2"
  • Actions

  • Set deaths for Benglaas for P1 to 7 A = rank 7
  • Set deaths for Benglaas for P2 to 6
  • Set deaths for Benglaas for P3 to 5
  • Set deaths for Benglaas for P4 to 4
  • Set deaths for Benglaas for P5 to 3
  • Set deaths for Benglaas for P6 to 2
  • Set deaths for Benglaas for P7 to 1
  • Move location "teleport origin" to "any unit" owned by Current Player at location "Origin 2"


  • Origin 3 GBCAEFD
    Players

  • Player Force(s)
  • Conditions

  • Current Player brings "any unit" to location "Origin 3"
  • Actions

  • Set deaths for Benglaas for P1 to 4 A = rank 4
  • Set deaths for Benglaas for P2 to 2
  • Set deaths for Benglaas for P3 to 3
  • Set deaths for Benglaas for P4 to 7
  • Set deaths for Benglaas for P5 to 5
  • Set deaths for Benglaas for P6 to 6
  • Set deaths for Benglaas for P7 to 1
  • Move location "teleport origin" to "any unit" owned by Current Player at location "Origin 3"


  • ... etc. for all origin locations you set the Benglaas deaths to signify rank of the associated destination

    Okay, now we've defined all the teleport orders. Now on to the triggers that teleport based on the rank we set. The idea is that the viable destination has rank 1. If it's already blocked by foes units, you lower the rank of all destinations. Now another destination will be rank 1. The former rank 1 will now be 0 and thus ignored. It's important that all of this happens in 1 trigger loop or we run the risk that other players want to teleport at the same time and interfere with the logic. Correct trigger order is obviously vital. Thus we need a couple of copies of these 7+1 destination triggers.

    Teleport if destination A is rank 1
    Players

  • Player Force(s)
  • Conditions

  • P1 has suffered exactly 1 death of Benglaas
  • Foes brings at most 0 units to "destination A"
  • Actions

  • Move all "any unit" for Current Player at "teleport origin" to "destination A"
  • Set Benglaas for All Players to 0 [just to clear up ]


  • Teleport if destination B is rank 1
    Players

  • Player Force(s)
  • Conditions

  • P2 has suffered exactly 1 death of Benglaas
  • Foes brings at most 0 units to "destination B"
  • Actions

  • Move all "any unit" for Current Player at "teleport origin" to "destination B"
  • Set Benglaas for All Players to 0 [just to clear up ]


  • ... for all destinations

    Now it's entirely possible none of these fired because the "desired" destination was occupied (2nd condition). Thus we decrease all the ranks to get another candidate to rank 1:

    Decrease rank by 1 for all destinations
    Players

  • Player Force(s)
  • Conditions

  • Current Player brings "any unit" to location "teleport origin"
  • Actions

  • Set Benglaas for All Players subtract 1


  • and now we have a different candidate, so we repeat the destination triggers:
    Teleport if destination A is rank 1

    Teleport if destination B is rank 1

    Teleport if destination C is rank 1

    Teleport if destination D is rank 1

    Teleport if destination E is rank 1

    Teleport if destination F is rank 1

    Teleport if destination G is rank 1


    and decrease the rank again
    Decrease rank by 1 for all destinations


    we need a total of 7 copies of these 7+1 destination triggers to give every destination the chance to fire.


    Now I realize that logic may be a bit complicated on first glance, which is why I colored things to keep track of. If you still have questions feel free to ask!

    Also disclaimer: I've not tested this at all, so there might be a bug in there or even a neat trick * to reduce the redundant triggers.

    *) 1 variation I can think of right away:
    You could let this run multiple trigger loops so every trigger loop 1 destination will be checked. It's only a slight delay as usually it will find a viable location to teleport to after 3 or 4 tries at most. If that sounds interesting you have to add a switch that gets turned on by the origin triggers and turned off by the teleport triggers that blocks any additional teleport attempts until the first one got resolved. Why a switch and not a death counter? This is more or less down to taste, but the reasoning is I use switches to affect triggers globally, death counters are convenient for "by player" triggers.




    Nov 25 2020, 1:18 am armitage Post #6



    Quote from NudeRaider
    This is really clever. I tested it and it does work bringing units to each destination A or B if the other spot is occupied, but as soon as I block both A & B with enemy units it doesn't want to teleport to C or another lower priority destination. When there's 7 copies of the triggers, is that 7 copies of Teleport if destination A is rank 1 followed by 7 copies of B is rank 1, or 7 copies of the list including the +1 trigger? I've tested with the latter. I wonder if it's possible that the trigger is not firing after the first 2 destinations because I have player 3 in a different force from 2 and that's messing with the order in which they fire (because the triggers are owned by forces).
    Quote
    You could let this run multiple trigger loops so every trigger loop 1 destination will be checked. It's only a slight delay as usually it will find a viable location to teleport to after 3 or 4 tries at most. If that sounds interesting you have to add a switch that gets turned on by the origin triggers and turned off by the teleport triggers that blocks any additional teleport attempts until the first one got resolved. Why a switch and not a death counter? This is more or less down to taste, but the reasoning is I use switches to affect triggers globally, death counters are convenient for "by player" triggers.
    I tried putting switches on the origin and teleport (set on origin, clear on teleport), and it didn't seem to make a difference. I will be incorporating switches though to add conditions when someone enters an origin location.



    None.

    Nov 25 2020, 7:33 am GGmano Post #7

    Mr.Pete-Tong

    in a so many trigger setup system chances that you made a single text or edit fault is big, if the system works for short time while testing. at least here is where you need think whats happening in the trigger step by step. to easy out finding blocks stops or whatever causing the trigger system to stop you could add small display text for the triggers in system that way you can while your testing see excaktly what is firing in the system and when it stops. this has been a good way for me to correct advanced systems

    like origin 1 switch set display text origin 1 is set and opposite display if cleared

    and display text add deathcount 1 to add systems and set deathcount system

    when you get your system to fully workind as you want you can remove display text triggers again

    EDIT:
    I would do this with switches as nuderaider says its good if they are global which it seems in your case.

    A trigger setup for this i would make like this

    Having 80 locations

    Having a switch for a-k

    having triggers to toggle switches a-k looking like this process described further down

    Post has been edited 4 time(s), last time on Nov 25 2020, 11:09 am by GGmano.



    Trust is everything

    Nov 25 2020, 8:03 am NudeRaider Post #8

    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

    Oh! Scratch all that. I think I just realized...


    ... what's going wrong: IIRC you can't change death counters of players that don't exist. So if Player 3 stores the rank of location C but was not in the game lobby at game start, then when you set the Benglaas for P3 it would still be 0. Can you check that with a debug trigger? Just make a text that gets displayed for Current Player when P3 has at least 1 death of Benglaas. If that doesn't show I'll see if we can salvage the logic somehow.




    Nov 25 2020, 8:22 am GGmano Post #9

    Mr.Pete-Tong

    Idk tryid to put up a system for you it was deleted for some reason

    EDIT1:
    clear switch A
    Players

  • Player or force
  • Conditions

  • If player or force bring at least 1 unit to location A
  • Switch A is cleared
  • Actions

  • set switch A
  • Preserver trigger



  • set switch A
    Players

  • Player or force
  • Conditions

  • If player or force bring at most 0 unit to location A
  • Switch A is set
  • Actions

  • clear switch A
  • Preserver trigger



  • do this with all switches a-k

    than do the combination triggers

    Move unit to loca A
    Players

  • Player or force
  • Conditions

  • Player brings at most 0 unit to location A
  • Switch A is cleared
  • Actions

  • Move unit to location A
  • Preserver trigger



  • EDIT2:
    And do same with all other switch locations the A is simple K is has more conditions

    Move unit to loca K
    Players

  • Player or force
  • Conditions

  • Player brings at most 0 unit to location K
  • Switch A is set
  • Switch B is set
  • Switch C is set
  • Switch D is set
  • Switch e-i is set
  • Switch K is cleared
  • Actions

  • Move unit to location K
  • Preserver trigger



  • EDIT3:
    to move the dropship you need deathcount

    switch A-K is cleared

    set dc to 1 bengaladas

    Swtich A-I is cleared, switch K is set

    set dc to 2 bengaladas

    and so on with all the combinations

    than add trigger for moving dropship

    If dc bengaladas is 1

    move dropship to location 1 (out of 80)

    if dc bengaladas is 2

    move dropship to location 2

    and so on with all the 80 locations

    Than youll have the dropship moved dependant on whitch switch A-K is set

    EDIT4:
    Quote from NudeRaider
    ... what's going wrong: IIRC you can't change death counters of players that don't exist. So if Player 3 stores the rank of location C but was not in the game lobby at game start, then when you set the Benglaas for P3 it would still be 0. Can you check that with a debug trigger? Just make a text that gets displayed for Current Player when P3 has at least 1 death of Benglaas. If that doesn't show I'll see if we can salvage the logic somehow.

    I believe you can store deathcounts for computer players. But if a player is set to human and is not in game deathcounts cant be stored for that spot/player. its best to use force when doin global deathcounts for players/forces.

    Post has been edited 1 time(s), last time on Nov 25 2020, 11:33 am by NudeRaider. Reason: merged the posts



    Trust is everything

    Nov 25 2020, 11:43 am NudeRaider Post #10

    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 GGmano
    if a player is set to human and is not in game deathcounts cant be stored for that spot/player. its best to use force when doin global deathcounts for players/forces.
    Thanks for confirmation. Using force doesn't work with the system I proposed. The player number is tied to destination locations. It's not like it usually is that every player has its own counter of the same variable. It's actually 7 distinct variables for the 7 locations.

    I'll try to figure out an update to the system that also works when you're not playing with full house. Could take a bit so bear with me.

    EDIT:
    Quote from GGmano
    triggers 1-3
    Not sure what the purpose of the clear, set and teleport triggers are. You seem to have wrong description, and missing player qualifiers etc. You need to explain better and make precise triggers.


    Quote from GGmano
    Move unit to loca K
    Players

  • Player or force
  • Conditions

  • Player brings at most 0 unit to location K
  • Switch A is set
  • Switch B is set
  • Switch C is set
  • Switch D is set
  • Switch e-i is set
  • Switch K is cleared
  • Actions

  • Move unit to location K
  • Preserver trigger

  • How does this cycle through the destinations if the first is occupied?

    Post has been edited 1 time(s), last time on Nov 25 2020, 12:10 pm by NudeRaider.




    Nov 25 2020, 12:58 pm GGmano Post #11

    Mr.Pete-Tong

    Quote from NudeRaider
    Quote from GGmano
    triggers 1-3
    Not sure what the purpose of the clear, set and teleport triggers are. You seem to have wrong description, and missing player qualifiers etc. You need to explain better and make precise triggers.

    How does this cycle through the destinations if the first is occupied?
    The Clear and set triggers is for map to know whether theres a unit occupied in hes locations (1-80) when he have a system for detecting this he can setup the combinations of wheter to move the dropship to location (1-80) if the location is not occupied.

    I dont know the specific players he use for the triggers but he could use a computer player slot to detect the bengaladas deathcount and switches is global. i think he should make all this trigger system for a computer player that way it wouldnt matter how many human players is in the game.

    I didnt think he wanted to cycle the movement to locations, i just read hes topic as he wanted a dropship to be moved to 1 of 80 locations depending on which switch a-k is set thats what i get from hes explaining. sorry if i was wrong there. it sure seems abit complicated

    Quote from armitage
    I'm trying to do something with an exclusive trigger like the one below:
    https://staredit-network.fandom.com/wiki/Queue_or_Exclusive_Triggers

    But I can't figure out how to make different ordered versions with death counters.

    For example, I want to bring a dropship to *location 1* and a trigger moves it to location A if a foe doesn't have a unit there, or location B if location A is occupied, C if B is occupied etc, but if I bring a dropship to *location 2* it moves it to location C first if unoccupied, then B, then A. Basically I want the map to check if locations A...K don't have another player there, then move the dropship based on the preferred destination order of location 1, 2 ...80. I don't want to have to use a trigger for every combination of number and letter location and it should keep moving the players units brought to the location until switched off.

    Any suggestions?

    I dont think theres an easy way to do hes wishes if he wanted the dropship to be moved to random destinations 1 of 80 it would be more easy but since he wants this done in a very specific way, he needs alot of triggers for detecting switches and combinations and moving dropship actions to the total of 80 locations thats really alot. thats what i think

    Post has been edited 2 time(s), last time on Nov 25 2020, 1:23 pm by GGmano.



    Trust is everything

    Nov 25 2020, 3:56 pm NudeRaider Post #12

    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 GGmano
    I didnt think he wanted to cycle the movement to locations, i just read hes topic as he wanted a dropship to be moved to 1 of 80 locations depending on which switch a-k is set thats what i get from hes explaining. sorry if i was wrong there. it sure seems abit complicated
    Yeah took me a while to figure out what he wants as well. Refer to the two posts below the opening post, that should clear it up. He has a bunch of destination locations and depending on where you initiate the teleport a couple of destinations get picked as candidates and given priorities (rank as I say). And then the unit should move in a order through the candidates given by the priority, picking the first location that isn't yet occupied.




    Nov 25 2020, 11:52 pm GGmano Post #13

    Mr.Pete-Tong

    sounds complicated too me but maybe it isnt if you get the full picture of it. i would definately need more specific and precise needs that he wants to understand it fully, i hope you can give him good help here nude it seems like you got the picture at least xd



    Trust is everything

    Nov 26 2020, 2:03 am armitage Post #14



    Quote from GGmano
    in a so many trigger setup system chances that you made a single text or edit fault is big, if the system works for short time while testing. at least here is where you need think whats happening in the trigger step by step. to easy out finding blocks stops or whatever causing the trigger system to stop you could add small display text for the triggers in system that way you can while your testing see excaktly what is firing in the system and when it stops. this has been a good way for me to correct advanced systems

    like origin 1 switch set display text origin 1 is set and opposite display if cleared

    and display text add deathcount 1 to add systems and set deathcount system

    when you get your system to fully workind as you want you can remove display text triggers again

    EDIT:
    I would do this with switches as nuderaider says its good if they are global which it seems in your case.

    A trigger setup for this i would make like this

    Having 80 locations

    Having a switch for a-k

    having triggers to toggle switches a-k looking like this process described further down
    I've been using display text to find out what's been firing, it's a little difficult with this though especially with hypertriggers spamming. I might try coloring the text on my next pass.

    Ideally you'll only be allowed to teleport units from one origin to one destination area at a time, but you can keep bringing multiple dropships to the same origin. Once all your units have left the destination area only then can a new origin location teleport units.

    Quote from NudeRaider
    Oh! Scratch all that. I think I just realized...


    ... what's going wrong: IIRC you can't change death counters of players that don't exist. So if Player 3 stores the rank of location C but was not in the game lobby at game start, then when you set the Benglaas for P3 it would still be 0. Can you check that with a debug trigger? Just make a text that gets displayed for Current Player when P3 has at least 1 death of Benglaas. If that doesn't show I'll see if we can salvage the logic somehow.
    I ran a display text trigger for a unit death for a player 3 that doesn't exist in game and it did display, the trigger just can't be owned by player 3 and fire. Interestingly, what happens is that if I create a computer player 4 and then occupy both A and B destinations with foes it teleports to destination rank 4 (player 4). If I replace player 4 with player 5, it teleports to destination rank 5 when the first two are occupied.

    If reducing the bengalaas death count of all players doesn't work without the player being in game, can it be salvaged by using a separate death counter for each destination owned by one (computer) player and have all death counters reduced by 1 at the end of the trigger loop?

    Post has been edited 1 time(s), last time on Nov 26 2020, 2:26 am by armitage.



    None.

    Nov 26 2020, 7:39 am GGmano Post #15

    Mr.Pete-Tong

    Quote from armitage
    If reducing the bengalaas death count of all players doesn't work without the player being in game, can it be salvaged by using a separate death counter for each destination owned by one (computer) player and have all death counters reduced by 1 at the end of the trigger loop?

    you could use a computer player to store the deathcount as your saying that would be good. than use force on the activation of the teleports the custom score system here would be the way to go if you want each players(humans) in the force triggers to fire one at a time in a cycle. that way if one player(human) is not in the game the system will still work. and yeah to change the system you would than need to subtract for the stored deathcount for the computer

    you can also susbtract the computer player deathcount in the same trigger as youre firing teleport
    A custom score is preset to 1,2,3,4,5,6,7,8 for the human players than the teleport trigger could look like this

    teleport
    Players

  • force human players
  • Conditions

  • Computer player suffered excaktly 1 death of bengaladas
  • current player has the highest custom score
  • Actions

  • add 1 for custom score current player
  • teleport unit to origin/destination
  • substract 1 for bengaladas computer player


  • if this trigger dosent need to fire each cycle you need to make it in queue
    Youll then need three more triggers for this system.

    Reset the custom score to 0 for players when the reach 9. im assuming you have 8 human players if you had 4 human players you need reset to 0 when reach 5

    than you need a trigger owned by an computer player that adds 1 to custom score for for force human players. than all players playing numbers will go one up each cycle. you can set restrictions to time this cycle in other ways too if teleports triggers shouldnt fire each cycle than you need make this trigger in queue also

    at last you also need reset the computer player bengaladas deathcount at the point where you want this to restart. like setting the bengaladas from 0 to 11 or something in your case if a-k

    This way you could have more individaul systems stored with computer player like a-k and k-a you need two deathcount for such two systems one for each system and have em fired by the human force players

    and preserve triggers added too

    Post has been edited 3 time(s), last time on Nov 26 2020, 8:13 am by GGmano.



    Trust is everything

    Dec 2 2020, 8:01 pm NudeRaider Post #16

    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

    Sorry took me a while to get back. Have you made any progress? Anyhow, reading your findings the solution seems possible without changing much.

    Quote from armitage
    If reducing the bengalaas death count of all players doesn't work without the player being in game, can it be salvaged by using a separate death counter for each destination owned by one (computer) player and have all death counters reduced by 1 at the end of the trigger loop?
    Ah right. I seem to be a bit rusty. Now you say that I remember that you can modify absent player's death counts if you specify a single player, but if you use groups like "All players" or "Forces" it will ignore absent players.

    So the simple solution is to to subtract from P1, P2, P3, etc. instead of All Players in the "Decrease rank by 1 for all destinations" Trigger. Similarly I suspect you have to modify the "Teleport if destination X is rank Y" triggers when setting Benglaas to reset.




    Options
      Back to forum
    Please log in to reply to this topic or to report it.
    Members in this topic: None.
    [02:29 pm]
    MTiger156 -- u
    [06:58 am]
    NudeRaider -- m.0.n.3.y
    m.0.n.3.y shouted: Mini Game Party was featured on Artosis's channel recently! Pretty cool win for UMS: https://www.youtube.com/watch?v=gSydfyOfOpI
    "xKrayZee sux"
    [04:36 am]
    m.0.n.3.y -- Vrael why do you say that?
    [12:03 am]
    Vrael -- thats awesome money, for you, but artosis is a giant turd of a human being
    [10:12 pm]
    RdeRenato -- a
    [09:59 pm]
    m.0.n.3.y -- Mini Game Party was featured on Artosis's channel recently! Pretty cool win for UMS: https://www.youtube.com/watch?v=gSydfyOfOpI
    [2021-1-17. : 3:47 pm]
    C(a)HeK -- greetings all, friends, can you check my new post? :) http://www.staredit.net/topic/18183/
    [2021-1-17. : 3:17 pm]
    IlyaSnopchenko -- Neiv
    Neiv shouted: Depending on your situation you may be able to use 18/19/20/21 to select all players in a force?
    thanks! Will use the force # instead most likely, if they're in the same one
    [2021-1-17. : 2:26 pm]
    Neiv -- Depending on your situation you may be able to use 18/19/20/21 to select all players in a force?
    [2021-1-17. : 2:25 pm]
    Neiv -- IlyaSnopchenko
    IlyaSnopchenko shouted: Anyone knows whether current player (13) is counted among allied (15) when specifying targeting flags for idle_orders in AISE?
    It is not counted; the dll seems to accept a combination of multiple players there like most other extended commands, but pyai doesn't seem to allow specifying them in targeting flags
    Please log in to shout.


    Members Online: jjf28, NudeRaider