ProTRG v1.1 by poiuy_qwert
Download Windows EXE: ProTRG v1.1 (1.7mb)
Download the Source: ProTRG v1.1 (49kb, requires Python)

ProTRG is an advanced trigger creation language (like MacroTriggers) built on top of Python that is very useful for generating lots of SCMDraft triggers (and now even .trg files!) in an easy and efficient way. ProTRG is a command line "compiler" which runs the code in a plain text file and outputs SCMDraft triggers (or a .trg) to another file. It also comes with Notepad++ support, in fact its meant to be used with Notepad++ for a much easier experience.

Changes
ProTRG v1.1:
* Updated readme
* Fixed LeaderboardComputerPlayers (changed parameter from SETSWITCHSTATE to SETOTHERSTATE)
* Fixed the default trigger file from "triggers.txt" to "triggers.protrg"
* Fixed the convenience global ACTIONS so it's set to True
* Fixed some TUNIT vs UNIT inconsistancies, and the definitions for conditions/actions with the PERCENT parameter type
* Fixed multilines and slashes in string conversion
* Fixed potential problem with script filenames starting with "protrg" (without quotes)
* Fixed switches to be numbered the same as SCMDraft switches (1-256 instead of 0-255)
* Fixed many unit names
* Added support for compiling straight to .trg's, including GOT compatible .trg's (Note: StarEdit has problems loading recycled strings)
* Added an optional mechanism to have stronger typed values for parameters (Explained more in the Coding section)
* Added support for Extended Unit Deaths (EUD's) using the new stronger type mechanism (using EXTENDEDUNIT type)
* Added DefaultString, which is set to an empty string (""), and all default AI scripts as Globals
* Added @include preprocessor to iclude ProTRG files in others
* Added better command line support
* Added better support for Properties
* Added the keyword argument "disabled" for conditions/actions
* Added the possibility to collapse code in Notepad++ using #> and #< for the start and end
* Added a list of the Globals and their values to reference.txt
* All conditions and actions now inherit from the Condition and Action classes instead of directly from Raw
* LOCATION id's are now 0 to 254 instead of 1 to 255 to conform with map editors default location names
* If an error happens in your script it will now print all the current triggers in the Trigger list (if any) after printing the error traceback
ProTRG v1:
* First public release

Post has been edited 2 time(s), last time on Mar 27 2010, 2:55 pm by poiuy_qwert.

Seems a bit redundant since there's already MacroTriggers to do basically the same thing, or am I wrong and there's stuff in this that MacroTriggers can't do?

It's much less strict of a language than MacroTriggers, and since it's built on Python, anything allowed in Python goes, which means a lot more open coding. My only complaint is that the style of the code, although efficient once you understand it, doesn't seem very user friendly. I'm currently writing Mystic Islands RPG in MacroTriggers, but when that's finished, I may try this one out for working on Fort Ethanios and see how they compare.

yoonkwun: Well actually I wouldn't have made this since MacroTriggers is there, but I actually started this a while before MactroTriggers and it has been sitting on my USB, 30 minutes of coding away from being done (and a few people have been asking me about it). You are correct for most of the things you need to do, MacroTriggers can do it, but there are a few things ProTRG can do that MacroTriggers cant. Also, as Falkoner said Python is a much more open language (its also dynamic and not strongly typed) and has a large backend if you so happened to need something from it. I've also released the source code, and since its written in Python it can be use on Mac and Linux (like MacroTriggers i believe).

Falkoner: Yeah the syntax is a lot less strict and I agree can be a user unfriendly for newer users. In its bear minimum the triggers can be hard to follow, but there are a couple ways to fix it. Here is the minimum:

You can make it easier to read with comments:

Or using the convenience globals Conditions and Actions (both are set to True) in if's:

Does it actually make triggers into data structure representations or is it simply a collection of functions that print to trigedit text?

Everything is custom classes. Trigger is a class, every condition is a class that inherits from the Condition class (which inherits from the Raw class), every action is a class that inherits from the Action class (which inherits from the Raw class as well). The way it works is there is an internal list of triggers (which can actually be manually modified), when you create a Trigger object with the add keyword parameter set as True (which is default) or use the addTrigger method on a Trigger object, that object is added to the end of the list. When the script is done the Triggers are printed in order they are in the internal trigger list. Some more info can be found in the Coding section of the readme or original post.

Cool.

Edit: Ah neat, just finished reading. I'll see if I can't learn me some Python later to try it out.


Also: Does it validate condition and action field types? It'd help a lot to not have to dig through compile errors in trigedit to find out I accidentally put a unit where a location was supposed to go in some random trigger (an annoyingly common mistake for me, alas).

Post has been edited 4 time(s), last time on Jan 11 2010, 7:38 am by Tuxedo-Templar.

Oh, very interesting. I've been having some technical issues with getting the Macro Triggers auto-complete to work, so I'm definitely going to try this out. I also find this extra appealing since it is written in python, and I've gone through and written a few of my own small programs in python already. I'll definitely be taking a look at your source code. Thanks a lot for posting this

There is a little bit of compile checking, but the scenario you stated could happen, since the parameters are meant to be as accepting as possible.

I'm glad it can be of use to you!

I can print hello world in python. I think (if you do decide to release an update) that you should automatically add conditions and actions comments.

I definitely will be updating ProTRG, but I don't know what you mean by condition and action comments.

Edit: I thought of a way to have an optional mechanism to make ProTRG more strict about parameter types. This would involve using the type classes to hold your parameters. For example, this code will compile (and shows some of the power of ProTRG) but might be erroneous in most situations:

In conditions/actions UNIT parameters can take a unit id which is just an int, but the LOCATION parameters can also take an int as the location number. There is no way to tell if an int is meant to be a unit or a location. To make the type more strict you will be able to do:

And it will be able to tell myUnit is not meant to be a LOCATION and throw an exception.

Edit2: I knew i forgot something! EUD support! Which parameters of which conditions does SCMDraft support extended units and extended players?

Edit3: Changed example code above to something better

Post has been edited 3 time(s), last time on Jan 12 2010, 11:22 pm by poiuy_qwert.

Cool. That'll work.


Also, what about compiling multiple source files into a single project? Don't say "just run it for each file" because I like to do stuff like put variable declarations and code into separate files.

Also, what's a good way with Python in Notepad++ to make foldable blocks for hierarchically organizing large groups of triggers? I couldn't live without something like that.




If I can manage to wrap my brain around this and Python, I'll go ahead and shelve my Javascript API and just use this. Save me a bit of work, and we can just stick with one standard that way. Notepad++ doesn't like Javascript much, I'm beginning to find, so it's just as well.
even though they'd both be able to do basically the same shit anyway

Post has been edited 5 time(s), last time on Jan 15 2010, 9:01 am by Tuxedo-Templar.

I didn't quite think this one through when making it. You can use Pythons built in import command but that only lets you import files with Python extensions (not .txt or .protrg). I'll add a specific pre-processor for ProTRG imports in the next version, which should be out fairly soon.

This is my one problem with Notepad++, custom highlighters cant use a Python based system for foldable blocks, which means using the ProTRG user defined highlighter will not give you the folding blocks. The only way to do it is to switch to using the built in Python highlighter. The problem in this case is the ProTRG specific keywords and stuff will no longer be highlighted and/or give autocomplete hints (unless you can add the ProTRG stuff to the Python stuff, i'll look into that the next time I can), but the reference.txt can be used in its place.

I'd be glad to know that at least someone is using it!

Hmm. MacroTriggers uses a custom highlighter and managed foldable blocks by using block openers and closers within line comments (//> to open, //< to close). Would doing something like that be an option?

Does your autocomplete let you fill in each of a function's parameters one after the other? If not, then it's nigh useless anyway. I rarely use autocomplete with MacroTriggers since I can only autocomplete condition or action names; not parameters. I use NP++ macros bound to numpad keys + Ctrl for the most common condition and action types, though, which is just about all I need.

Post has been edited 4 time(s), last time on Jan 15 2010, 11:40 pm by Tuxedo-Templar.

Ah yes I forgot about that option. I'll add that for the next release.

The autocomplete is the same for any Notepad++ language API, there's not really any way around it.

OMFG ME TOO!

This is just perfect. I'm spending my time today learning to use this.

Oh yeah, this should be more flexible than MacroTriggers, which I've been semi annoyed with due to Wormer not working on it, but since this is built on Python, there should be very few things that are annoying, comparatively. Also, make sure you add the collapsable comments (//> //<) because those really allow you to do serious organization, splitting trigger systems into functions, that can be tucked away neatly once finished, I can't begin to explain how wonderful making Mystic Islands has been with that ability.

Well there is one thing that annoys me about APIs versus custom languages: Readability takes a major hit. Not that there aren't ways to compensate, and through them, perhaps even improve readability... but at a cost. Doing that ventures into a territory solidly away from trigger making and into near-full fledged scripting. The complexity involved stands to become amped up significantly.

Still. It is the 'right' approach, if it's trigger abstraction we're going for. Though I'd probably revert back to MacroTriggers if it were just upgraded a bit (or maybe not; I am starting to enjoy having regex again, now ). Trigger making can (and should) be handled in only so many advanced ways, really. No matter how much scripting you wrap it with, triggers can't (or shouldn't, I should say) be turned into a scripting language themselves. You could get pretty darn close, though. A lot of Starcraft's functions need to be handled much too intimately for proper abstraction, though.

Simplicity and readability are still important goals, therefore.

Post has been edited 6 time(s), last time on Jan 18 2010, 4:11 am by Tuxedo-Templar.

So I messed a little bit with this today, and here is one of the things I made. What this does, is it defines the function Hyper() as a hyper trigger. Now, within the code I can call the function Hyper and it will output a hyper trigger for me. I can also use loops to call multiple amounts of hyper triggers. Here is my code that goes into the input .protrg file.




Just thought I should share this, as some people might find it useful.


Here is an example of defining a trigger as a function with parameters for the function:




Post has been edited 4 time(s), last time on Jan 18 2010, 7:41 am by CecilSunkure.