download here

I wrote some wrappers to make generating trigedit (for smcdraft2) compatible triggers from ruby easy.

Trigedit is very handy because you can copy and paste into it, unfortunately it is very tedious to to actually write triggers in it.

These wrappers make it easy for three reasons:
1) There is a consistent syntax using duck typing and smart default arguments for unit, location, and player.
2) You can name any abstraction and reuse it
3) You can use loops to generate triggers that are very repetitive (binary cutoffs, shared vision ai scripts, etc).

I realize Wormer has already created a macro system for generating triggers. It might be really good, but I didn't look into it very much because I was not keen on needing to learn a whole new language just to generate triggers (well if you don't know ruby this will still be a problem for you, but at least it will be a useful language that you learn). It also seemed to still suffer from problem of having a bunch of functions and needing to remember their argument orders.

With these wrappers the arguments for nearly all conditions/actions is straightforward.

To specify the player for a cond/action use array indexing []
To specify a location, use .at
To specify a unit, use a symbol :

The default location if omitted is Anywhere
The default player if omitted is current player
The default unit if omitted is any unit

For example the condition to check if player 3 has at least 5 marines is
:marine[3]>=5

The action to create 1 zergling at "start" for allies is
:zergling["allies"].at("start")+1

The action to remove all units for the current player is
clear

This last example might seem like a special case but it is not. Clear is simply an alias to (set 0) or (self|0). any unit, anywhere, and current player are all just default. Note that when you set unit to 0 it uses remove all, if a location is present it automatically uses remove units at location. You could remove just x units by using self-x. If you wanted to kill the units instead of remove them, just specify kill (for example kill.clear or :zergling.kill-1)

To actually build triggers use trig, or ptrig as a shortcut for including the action preserve trigger. trig accepts all arguments as conditions or actions, as well as a block which is ran. Any argument that is not a condition or action is assumed to be the player to run the trigger for. You can also use "section" to specify default players trigger is for if non are given in trig. "Always" is assumed if no conditions present.

Some examples:
section All
trig(Ore.set 50)



The best thing about this is being able to create your own abstractions and reuse them. For example in my phantom map here is the trigger that handles victory for slayers. (The abstractions are reused for victory for phantoms).



This might not seem that short to handle victory. But alot is actually going on here. Some explaitions:
Phantom and BeenPhantom are death counter variables used to represent if a player is/was the phantom. They were created by simply Phantom = var. var is a function which creates a death counter variable automatically using unused units.

PhantomChosen is a switch which was created using PhantomChosen = switch.

swait is a simulated wait, which must be used to avoid wait blocks if hyper triggers are present (which they are, since in a phantom game any player could be absent so the hyper triggers just run for all players).

fi means if, but that is a reserved word in ruby.

sync, means to start running this trigger next trigger cycle starting with the first player. This is used because say there are 3 players. Player 1 is a slayer, player 2 is the phantom, player 3 is also a slayer. Player 2 is eliminated, he will have a trigger running for him that clears his Phantom switch. This means player 3 will detect the victory first. But victory actually ends the scenario in defeat for all players that do not also run the victory trigger this very trigger cycle, thus if sync was not used, player 1 would see defeat even though its victory would run just 1/12th of a second later (this was actually a bug in my first phantom map).

The triggers that actually get generated look like this:


Note if you reuse this abstraction the first two triggers would not also be duplicated, they would be reused automatically. This may now seem like alot of bloat in the actual triggers. But it is pretty much the bare minimum if you actually want to do it right. (When I did it by hand, I had less because I used toggleable hyper triggers instead of swait, but I switched to swaits because I didn't want replays to desynch).

This trigger generation system is something that I just made, there may still be bugs and quirks, but the could thing is it is fairly simple, if you want to change the way something behaves you can just do it your self, since it is just a couple of ruby files. I realize this quick tutorial I have given is not really enough to learn how to use them to their fullest, I may try to explain it in more detail later. If you use them, it probably will be confusing at first. But if you map alot, this really does make it easy once you understand it. I would prefer to use them to using menu based triggers for anything, even non repetitive stuff. There are tons of things that could be added or improved, but I make no promises to update. (I wrote these primarily to help with my own mapping)

If you want to try to modify what I've done or add your own abstractions, I'll give a brief description of the files:

units.rb: loads the list of units
bindings.rb: creates a bunch of functions that do the trig edit equivalent of all actions and conditions, for example
displaytextmessage(AlwaysDisplay, "asdf") generates:
Display Text Message(Always Display, "asdf")
wrapper.rb: creates the class like consistent behavior wrappers
abstractions.rb: a bunch of abstractions like swait
phantom.rb: the code to generate my phantom map triggers
autohotkey.ini: you can use with a program called autohotkey to automatically copy out.txt to clipboard, switch to trigedit, paste, compile, check if error and save map.

This looks pretty nice, however, to tell you the truth, it seems like more of an entire language than Wormer's MacroTriggers, the syntax looks like it would take a bit of memorization, but I think once you get it down, it'll be totally worth it, nice work.

Nice thing Though I don't know ruby at all =) I am gonna to enumerate some number of random opinions, thoughts and questions that accidentally came to my mind which even does not necessary strictly correspond to the wrapper itself.

What is confusing at first glance is that sometimes you have conditions as parameters to a "function":
and sometimes you have conditions at start of a "block":

Just a random offtopic thought now. Triggers are event-driven machinery by their nature. People learned how to use them to do a bit more than was intended, but this is achieved by complexity of the triggers. We unite such triggers dealing with the same task in trigger systems. I thought that probably some higher-level system of notions and abstractions could be invented to represent trigger systems in more natural way.

Anyways, what I liked about the wrapper was that it enables to express such constructs as "if C is true then do A, further if additionally D is true then do B in addition to A". IMO, this is more natural way of human thinking than reducing all conditions to the disjunctive form.

+1 A very nice way of "electing" a leader of the game! I call a leader of the game the player who accepts the responsibility to execute triggers which are intended to execute only once per cycle. Also I usually divide players on 3 groups: an opening player, intermediate players, and a closing player. The opening player is the player who's triggers will execute first, the closing player is in contrast the player who's triggers will execute last and intermediate players are all other players. So the leader there is also double jobbing as an opening player (or is it vice versa? ).

I thought that in addition to what have been said, the scenario also ends in the victory to all allied victory players to the players for whom the victory action executes. Not perfectly sure though.

The Macro Triggers Language sounds loudly but actually there is little new to learn. And now I have autocompletion and hints

Will this generate a command condition or a bring condition?

What do you mean under "abstraction" there. When read I thought of a "sych" abstraction and from personal experience with Macro Triggers the ability to introduce "variables" (actually constants ) to name units. Is there anything else you understand under the "abstraction"?

Yay! this is really fun! I always thought of adding something like this to Macro Triggers. The same for switches.
Also,
you have tremendous plans!



Probably "iff"?

Wow, haven't known! Could you please explain, how do toggleable hyper triggers desynch replays?

A usefull thing! Might also be used with Macro Triggers...

I came here from the Phantom map showcase thread. I like how you tweaked the phantom rules to make it more fun. Don't know how this will work on practice but anyways it is a good attempt to make the map more interesting!

Good job

Hey Wormer, glad you got a chance to look at what I've done.

Yes, this is true, possibly a design flaw on my part. How it is now is conditions or actions can be in either arguments or blocks. It can tell what is a condition and what is an action, so it is just a matter of style. As a convention I put conditions in arguments. Blocks however don't get run at function call time, but when yield is used, so for some macros, everything needs to be in the block. This is less than ideal, and if I had to do it all over again I would probably rethink this to avoid using side effects and make it more functional. (I may try and tackle this, which would result in major changes)

I thought about including a closing/intermediate player type thing, but for my uses I didn't have any need for it (people can still just definite their own as they go though). Not that there is no need, I have really only used these to develop 1 map so far. At one point I almost made closing player but instead just made the action for first player, done before it reset the things in question (vote detection).


I saw that written in thread somewhere, and so I did a quick test a while back, the result was it only ended it in victory for the current player. (This was done by ending in victory for a computer player with mutual allied victory to me). As a side note there is actually a bug in default melee triggers for ums map. buildings of non allied victory players at most 0 is not the correct way to do it because if there are 3 players, A,B,C. Everyone is allied to A, but B and C not allied. A has no non allied victory players, so it will end in victory for him, defeating others.


Ah sorry, this is really a flaw of my own, I tend to prefer to develop my own solutions rather than learn other peoples. Also it wasn't a totally conscious choice to not use your trigger macros. What happened was originally I liked writing in classic trigedit, I only needed macros for the binary cutoffs for resource bonus, and later the giving vision stuff when I added it, so at the time I thought it would be easier to write a ruby script than learn macro triggers. However the original code for my binary cutoffs was ugly and hard to understand, I had problems changing it when I needed to make it work for 2 phantoms mode. So I thought I would make bindings for the trigedit rather than use strings. Then I thought it would be cool if syntax was the same for all types of values, regardless if it was a mineral count, score, death counter, etc.

If no location is specified it will use a command trigger, otherwise a bring. There are a couple more things that use this optimization too (I think it doesn't matter much though, may run slightly faster in starcraft).

I think of abstraction as any concept for getting something done. By writing your own abstraction, you use this concept directly rather than reusing how the abstraction works everytime and needing to consider how it actually is implemented. One problem I had when making abstractions was I had written in trigedit classic for so long, that I would automatically write out all parts of an abstraction. I would have to go back and say hey, this is what I was really thinking, this is what should actually be shown.

Haha, its not a plan it's an idea... Probably will never get done (or even attempted). But it could be done.

I think that means if and only if in math, also a flaw with fi is in some langs in means end if. This is another flaw in my system, my function names (for some abstractions) are confusing to other people.

Well originally I was toggling the hyper triggers off during the part where it does the intro (several messages separated by real waits). However wait, waits real seconds and a real second is a different duration depending on game speed (replay watchers will fast forward). So I shouldn't have said toggleable hyper triggers don't cause desynch, but real waits do, but only reason to toggle hyper triggers is to use a real wait (not an issue for end of game message though).

Thanks for your feedbacks. Your system is more mature and more suitable for people who do not know ruby, but I hope that some of my ideas can benefit it. Specifically there are three areas which I think my system does something better. (I say this to be constructive and give ideas, there are also many many ways yours does something better).

1) is the same type of operation (addto, set, leaderboard, etc) having the same way of being called regardless if it is a switch, units at location, deaths, opponents, etc
2) is the default values (anywhere, anyunit, current player), and lack of arguments and thus argument order
3) is the power of abstract macroes, via having the power of ruby. Like is it possible to define something like swait as a macro (without having to modify your java source?).

You might be 1 step ahead of me for 3) here (again I need to look more into what you've got already). But it seems to have that kind of power, you would really need to have to write your own total language (where as I have everything ruby can do for free). However you can make any syntax mean anything whereas I am stuck to ruby syntax. This is the tradeoff of new language versus building on an existing one.

I will read more about your system, instead of just making guesses about how much it can do (hopefully I am not complete off base here).

I see that you've developed the Wrapper for personal use to simplify own life and released it just in hope that it could be useful for someone else. You did it exactly as I did with MacroTriggers, that is why I understand you very well. You shouldn't be sorry for something not done or done in not obvious way because you've done it for yourself. Habits of other people obviously must not match yours.

I simply told you what first came to a mind of a man who is not familiar with Ruby when he looked at it. This might or might not be helpful if you decide to improve the wrapper. I am also glad there is an alternative to MacroTriggers, because alternatives always make you see your own flaws or ways of further improvement.

I'll tell you how I came to MacroTriggers, if you're interested. I was working on a map (that intended to be a new version of a Macro Micro map) and realized that copying text triggers by hand is not the best way, because if you want to change something later you'll have known problems. I decided to use text macro generation tool called M4. However on half way of using it I realized that triggers written in M4 look ugly and were inconvenient. So I decided to make my own "macro" "language", hence the name MacroTriggers. What is funny that I've never finished that new version of the Macro Micro map because I became too lazy

I just told what notions I mark out. Probably the closing player is somewhat odd, because executing triggers for closing player is almost equivalent to executing triggers for the opening player. The closing player is harder to determine, and what is more essential I believe that every system which determines the closing player should have a latency of at least 1 trigger cycle, because to understand that the particular player is the last one should necessary try to execute triggers for next players.

It is nice how you've noticed this! Indeed. One should use opponents condition instead (Current player has got exactly 0 opponents remaining in the game). This condition is equivalent to the statement "all remaining players are allied victoried to each other". I don't know how exactly SC calculates the number of opponents, but I think I have a right feeling of understanding the number of opponents in each particular case. In the described example player A will still have 2 opponents (I've just tested this to be 100% sure). I also believe players B and C will have 1 opponent (not tested but I'm 90% sure).

There are some wired and not obvious things about alliance statuses. You may read this post, in case you're interested.

Just an idea for your phantom map. Probably it might be interesting not to reveal phantom elimination. What I mean is to announce victory only when 1) all players are allied victoried and 2) there is no phantom among them.

Do you imply the replay of a UMS which has not any other waits except hyper triggers will work fine on any speed?

Yup, the command condition seem to work little faster. But sometimes it does matter what is specified: bring to anywhere or command. The reason is wired and lies in so called location invalidation thing, discovered a year go. The discovery started from here (actually it started on now lost Warbox forums ). Here is the second part of the discussion. The final solution is stated here (Firinite was a Disiple of Adun, so I refer to him as to DoA in the thread). Somewhere in the last thread you can find explanations why command works a little bit faster than bring.

The invalidation thing, and some other subtle things made me very attentive and cautious towards any kind of far going abstraction and powerfull automation. Of course abstraction makes life easier but sometimes triggerer requires subtle control over situation. This becomes even more essential when there are very limited resources one can use (quite limited number of DCs, strings, CPU power and such). That why MacroTriggers does not have complex means of defining abstractions. I believe that in complex cases a man could do the job better than the machine. That why MacroTriggers gives only an opportunity to specify sequence of triggers and nothing more. The so called macroses in MacroTriggers is simply a way to remember and parametrize a continual "block" of triggers in case to easily substitute it in various places. When making MacroTriggers my primary goal was not to provide a powerful abstraction of triggers, but to eliminate manual triggers copying.

So it is impossible in MacroTriggers to specify something in actions or conditions which will lead to generation of additional triggers (like swait). That why probably it is you who is ahead of me.

The first and the second seem to be correlated and are an advantage, but I can't understand how I can know (and thus have control over) what condition or action will be generated in the particular case. The last seems like a disadvantage, if one can't do it. Actually this gave me an idea of simpler syntax... I need more investigation on this though.

I don't know how to consider the third. Generally this seems to be an advantage, but again if one constructs a complex system usage of macroses may limit him. But you'll probably say that more specific macroses could be written to satisfy his needs... That is why I don't quite sure how to consider this. Also you can say that in some simple cases it is easier to use ready abstractions, but on the other hand the system is valuable when it can help writing complex triggers because in simple cases triggers could be easily written with one's own hand.

Once more, what you've made is something new and definitely deserves greater attention.

Good to know, opponents should definitely be used instead of non allied victory players.


I'll think about this, so you mean replace Slayer|Phantom eliminated message with just Player eliminated. And then change victory conditions to be all remaining players are in same "force", and are allied victory?


Using non zero waits definitely causes it, but there might be other things/bugs in sc that I am unaware of (besides EUDs) that can also cause desynch.


I was unaware of that difference between command and bring. However you can still easily generate the desired trigger using unit.at("anywhere") instead of just unit. I understand your point about over abstracting triggers. It is like comparing assembly language to a high level language. The high level language is much easier to program in but it can be extremely wasteful with resources. However the case is even more extreme with triggers, because abstractions can be messier and even less efficient due to the lack of power and side effect nature of triggers themselves. However just because an abstraction exist doesn't mean you have to use it. I think it is best to provide both ways of doing things, a direct way where you know and understand exactly what will be generated, but also providing ways for higher level thinking. Then again by having only one way, you make it easier for people to learn and help them make decisions since they do not have to consider which way to do it.

Looking at your work I see that you have auto completion for triggers, this seems like it would solve the problem of knowing what the names of commands are. If it also tells you about argument order then I think it is very good, and just an alternative style to the points I made under 1) and 2). Maybe it would be possible to automatically reorder arguements based on their type, so that in most cases the order would not matter. For 3) I would say that it is also a style thing. MacroTriggers is already so much more powerful than writing in triggers, that there is not need to complicated it any further for further power.

I have started going over my code and cleaning it up. First I will simplify the wrapper and make it more consistant (for example sethealth will be gone and health will be like a value, etc). After that I will try to make it easier to write abstractions.

Have you looked into generating output other than trigedit? There are a few limitations with it, like you cannot seem to use 10 digit numbers (useful for some EUDs), and also you cannot do some invalid things which are useful, like playing a wav that will make SC crash. Going straight to the CHK seems daunting though.

I'm sorry for my silence, I had not time to answer earlier.

Right, that was exactly what I wanted to say.

Also, having defaults sounds nice, but defaults can be source of mistakes. I like when everything is specified explicitly and is there right here before your eyes when you look at it.

Yes, a good idea, it is possible in most cases. Exceptions are when there are two arguments of the same type: GiveUnits, MoveUnits, Order, Transmission. Not qute sure what to do with this.

The other solution might be assigning labels to arguments, like:

GiveUnits(Unit: @All, Location: @Anywhere, From: @CurrentPlayer, To: @P(2))

(But then you have to remember labels names. )
There are few things that MacroTriggers requires. The main thing is (like Falkoner fairly noticed) having arrays to place units, locations and such things in arrays and later pick out items using math operations. There were few other things, but I don't remember right now. As far as I don't need them right now and not much people use MacroTriggers I'm not motivated to add this yet.


Yeah, right. Making a tool which would compile triggers right into the map is too complicated for me, because 1) you should examine ways of working with mpq archives and 2) work directly with raw data stored in the map. Also SCMD handles strings well. If only there was an easier front-end for operations with maps...

Yes, I was so happy when SI added support for the memory condition, but unfortunately there is a bug with trigedit about memory condition I already reported it there. By the way, you can remind SI of this bug...

There is one easier way to begin with instead of compiling directly to CHK. You can generate .trg file to import into the map. Find the description of it's format in the Wiki. It is quite simple. Unfortunately there are also limitations, for example I was very surprised to know you can't specify WAVs in .trg files. But using this method seems like a good start if you wish to compile into CHK later.

Also, this thread inspired me of writing a wrapper for triggers on Scheme. I've written an experimental 5-minute prototype and it seems that a functional language fits very well for the task of writing triggers. I generate .trg file right now. I realized how using an existing language have an advantage that you can use the full power of the target language instead of writing your own compiler to implement everything manually.

I have kind of stopped working on this. I did go though and rewrite the wrapper to use a config file and be much more consistent. But then when thinking about abstractions I thought of a very uniform and simple method for abstractions which would then need me to write an optimizer to keep the trigger size down (it could keep size to as low as human written). However the maps I am making aren't that complicated and it is frankly not worth the effort. (Might post the re written wrapper though, reason I haven't is because I haven't actually used it to make a map so it might have bugs)