Not sure what you mean. This is a single trigger.

Depending on which player it's owned by, can drastically change the results of the trigger, because if it runs for P1, that may prevent it running from P2. Maybe the map author wants it to run for P1-3, or maybe they want it to only run for P4. How does LangUMS make the right decision for who the owners of the generated triggers should be?

You called it logical construction.

But okay, if it's a (single) trigger, then we have 3 conditions that all have to be true, and 3 actions that will all run. (= like I assumed)
Who owns it, doesn't even impact the outcome since there's no current player involved.
But it's influenced by how many owners you add, because that means it will create copies and potentially fire multiple times. But that's the equivalent to another trigger loops (just speeds up the giving).

So what I said applies: Why is it important if LangUMS creates the resultant triggers for the human force, a computer player or even splits it up? (Again, as long as it doesn't break the statement you formulated.)

I'm not sure if this is supposed to be an example of one trigger or three so here are both answers.

If it's one trigger the LangUMS code is:


Who owns the emitted triggers I really can't tell you that easily. There is a lot going on in the background that decides who owns what. Ideally this whole code will be emitted as 1 trigger owned by whatever of these players makes sense (or maybe the reserved player will own it) but I can't promise that is true 100% of the time. It really depends on the context around the code as well as how the compiler decides to optimize that particular case. There is no ambiguity to the semantics of this code though, it should do what it says.

If it's three separate triggers:


If the bring() quantity is equal for all three players there is a shorthand way to do the above:



I am well aware of the actual implementation (i.e. how the triggers are actually processed by the game) and LangUMS takes advantage of this a lot. When I talk about triggers being a parallel construction I'm talking in the abstract sense, not literally how the game code does it.


Sorry if it seems like I'm ignoring any questions. I do try to answer everything, but some responses require more thought than others so my responses are somewhat out of order.

Post has been edited 4 time(s), last time on May 6 2017, 11:58 am by nlight.

*sigh* I am done. I really don't know anymore if you are trolling me, are just dumb, live in a fantasy world, have trouble communicating facts, or come from the multiverse.

Triggers never run in parallel. Stop insisting they would "in a sense". And thanks for wasting my time.

I'm starting to understand.


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.



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 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.
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:

Code
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.

Yeah. There will be 1 trigger emitted for the conditions which sets a switch and the rest will be sequenced using deaths()/ set_deaths() chains. The print() calls specifically will always be emitted for the player to whom they're printing because there is no other option.


This is a cool trick and though I currently haven't found a use for "one off" triggers in the compiler it may come in handy later. Thanks.

This is quite amazing, and I am very grateful you spent the time to create this abstracted language to replace using the vanilla Triggers.

I would certainly try using this tool.

I have some questions:

(1a) Are there syntax highlighting plugins available? E.g. if you had one for JetBrains PyCharm that would be fantastic!

(1) Can you provide an example of organized project? E.g. would a developer just have a folder with different src files plus the .scx file, and then decide their order (rather than one big src file)?

(2) Can we define locations' dimensions/will they be created automatically if I reference a new location e.g. "Location64"? The way some of the my triggers work, the initial coordinates of the location don't matter, just their width/height. Even Warcraft 3 has this feature (called RegionCreate, which takes 4 values, x, y, width, and height).

(3) What implementation of hyper triggers are being used (reference or show the Triggers output)? There's a recent post with a hyper triggers version that repeatedly sets a DC to 0 and 1 in a single trigger and seems to be the general preferred version.

(4) Can you provide an example of a Death Counter timer loop, e.g.

[code]
DC = startValue;
while DC > value:
DC -= 1;

if DC == value:
callback();
DC = startValue;
[code/]

(5) Finally, what would be really cool is if you remade a popular map using your LangUMS, and showed either (1) how much time it took, (2) how more efficient the map was, (3) how easier it was to update the map, etc.