I'm starting to understand.
global marine_count[3];
bring(Player1, AtMost, x, TerranMarine, LocationA),
bring(Player2, AtMost, y, TerranMarine, LocationA),
bring(Player3, AtMost, z, TerranMarine, LocationA) => {
spawn(TerranMarine, Player1, marine_count[Player1], LocationA);
spawn(TerranMarine, Player2, marine_count[Player2], LocationA);
spawn(TerranMarine, Player3, marine_count[Player3], LocationA);
}
If for example the code above emitted one trigger for the computer player 8, then what's written below will generate additional triggers for players 1 and 2.
global marine_count[3];
bring(Player1, AtMost, x, TerranMarine, LocationA),
bring(Player2, AtMost, y, TerranMarine, LocationA),
bring(Player3, AtMost, z, TerranMarine, LocationA) => {
spawn(TerranMarine, Player1, marine_count[Player1], LocationA);
spawn(TerranMarine, Player2, marine_count[Player2], LocationA);
spawn(TerranMarine, Player3, marine_count[Player3], LocationA);
print("Text for player 1", Player1);
print("Text for player 2", Player2);
}
Only one of those 3 triggers will actually own the specified condition. The rest triggers will rely on a switch set by the first trigger that is going to run. The switch is cleared in the epilogue of the player 8 triggers.
EDIT:LangUMS code runs sequentially, meaning all statements in the file are executed one after another. This guarantees that the effects of any statement will be visible to all statements that follow it which makes code much easier to reason about. This is a very nice and strong guarantee but it sacrifices the "parallelism" of the trigger machine, meaning that it's no longer possible for two things to "happen at once" (they never actually happen at once but can happen within the same trigger cycle). LangUMS guarantees that any two triggers the combined result of which depends on their order of execution will always give the same result. In practice this does not mean that a new trigger is emitted for every single statement in the code or that every single statement takes at least 1 cycle to complete. There is a lot of optimization going on and in the end instructions which can be put into a single trigger without affecting the outcome of the program will be.
LangUMS reminded me of Verilog - a language of specifying the behavior of electronic circuits which are concurrent in nature. There is a notion of blocking and nonblocking assignment in Verilog which you can borrow when something should depend or not from the execution order. In fact Verilog has similar constructs to describe something that should happen after several preconditions are met. I believe you can have inspiration from the language.
EDIT2:More ideas for you.
The player selected with --triggers-owner (player 1 by default) must always be in the game (preferably a CPU player). The triggers owner leaving the game leads to undefined behavior
There is a trick that allows to vest a human player with a function to execute such triggers that have to be executed only once. When player leaves, the next player takes his role. Have a look at the trigger:
Trigger("Force 1"){
Conditions:
Deaths("Force 1", "Danimoth (Arbiter)", Exactly, 0);
Actions:
Set Deaths("Current Player", "Danimoth (Arbiter)", Set To, 1);
// Preserve trigger isn't needed.
}
Every trigger that has to be executed
like for a CPU have to be 1) owned by the whole Force 1, 2) put below the specified trigger, and 3) must have a precondition Deaths("Current Player", "Danimoth (Arbiter)", At Least, 1).
Post has been edited 6 time(s), last time on May 6 2017, 6:24 pm by Wormer.
Some.