Having issues compiling, it keeps saying this line is wrong:



Reusable_Pixel is fine, Follow_Placeholder is also fine, it points me to the @ symbol in @P(9), no matter what number I change the player to, it says it's an Invalid Argument.

Also, is the Anywhere locations defined by default? Because that also gave me an error

EDIT: Tested, and it just seems to dislike the use of Anywhere, in either spot, why is this?

Post has been edited 2 time(s), last time on Sep 20 2009, 6:24 am by Falkoner.

Not sure, but I use @Anywhere whenever I need it and it seems to work fine. You'll have to post the code for me to help you further than that, though.

Accidentally double posted. Delete this, please.

Post has been edited 1 time(s), last time on Sep 20 2009, 10:35 am by Wormer.

Alright, the problem I simply had not a chance to program on any kind of a scripting language. Though when gazing I can even understand something you've written and I believe it is quite simple to learn a language like that.

First of all, I made MT to have a little practice on programming myslef. The goal behind MT was to make something syntactically and semantically similar to the SCMD triggers, but something more compact, something which allows good graphic way to view and organize triggers. A minor thing was I didn't like how awfully SCMD actions and conditions are named (with spaces in their names), one can't use a NP++ syntax highlighting and autocompletion because of that. I wanted to have a language which incorporates meta-data (about used units, locations and such) in a source file. While a scripting language can statisfy the second requirement, you should agree it is less graphic than MT. In MT you see the triggers sequence right before your eyes. Syntactic and semantic similarity to the SCMD triggers should be more friendly for people who already have a gist about SCMD text triggers. Actually the word 'language' applied to MT sounds very loud. Inherently MT is the SCMD triggers with an option to specify sequence of triggers with a pattern and to define new names for different objects. Probably MT even has not got the full power of a scripting language (or any other language), but as practice shows (mostly my own and now also Tuxlar's) the expressiveness of MT is enough for a modest practical task of writing triggers for your map. (Though I can't think of an example of such a thing which could not be done easily in MT at the moment, I suspect there might be some examples; on the other hand one can always bureforce and specify triggers she wants manually without replication.) Usually one doesn't need very complex replication templates, but what she needs is a good way to organize triggers in order not to get tangled in them herself.

Yeah it is cost effective, but I also want to look at it and see the structure of the output triggers without all that superfulous stuff. Also, if another person will write his python triggers he probably will do his definitions in another way. Afterwards if these two persons woould like to cooperate they won't understand each other without studying each other's ways of doing this meta-stuff (or a brute-forceing infomration, as Falkoner named it) instead of directly studying each other's triggers.




Alright, that would be cool. Could you guys give me a few real examples where this can be really extremely usefull?

The first reason I won't do it right now is that I am working on my map project and I really want to finish it first. The second reason is that I have to admit that I already quite forgot the code I written more than a year ago and a lil lazy to make any signifacant changes like this one. I even don't know which is easier, to make a true CONDITION and ACTION types or an evalish-like hack. The third reason I don't feel like this is really a crucial thing to do.

Could you show me the source?

Ideally, treating condition and actions like true data would always be better than an eval function. I simply anticipate eval being the easier option, though, even if it is just a quick hack. A third option would be to release your source code and I could try to work out how to add it, if you're not willing. Not sure how far I could get, or if you'd be willing to do that, even.


Here's an example of why cond/act fields would be useful as data:

I just saved myself 3 separate triggers with a few arrays. I'm sure there's better examples for this.

Post has been edited 2 time(s), last time on Sep 20 2009, 4:44 pm by Tuxedo-Templar.

Actually, I prefer having condition and action variables over an eval function..

Yeah, I see. As I said I didn't know what would be easier. Also if this should be done I think it should be done in a right way, like CecilSunkure said.

There is absolutely no problem releasing the source code in principle. But because of the hackish way I build the MT project at the moment this might be a little difficult to release it right or to explain how I do it (the way I do is definitely not right, but it works for me). Also I use the ANTLR library for parsing and visiting the syntax tree which might take some to learn.

Okay, you've saved a few strings. But the real reason of using a language feature is not to simply save space, but to make the code better in some way (better understandability, easier support). I am sure there are better examples too, that why I want to see these better real examples when this thing will do the code better.

EDIT:
Also I am sorry but I've added your information files only today When I wanted to add them few weeks ago unfortunately the media-fire (host where I upload all my files) was not working and I decided to wait for a while and then forgot

Alright, finally information files from Tuxlar are available at the downloads section!

Post has been edited 6 time(s), last time on Sep 20 2009, 5:30 pm by Wormer.

Well it's a bit more than just saving space. Arrays with items mapped to triggers on a 1-to-1 basis is 'just saving space', as per my example. Using expressions to map conditions or actions to triggers is where it would begin to find its usefulness.

In any case, yeah it's not critical. But I still want it cause I'm spoiled.

Post has been edited 1 time(s), last time on Sep 20 2009, 7:06 pm by Tuxedo-Templar.

Better example:

I have a MACRODEF that is meant to transfer the value of one Death Count to another, of course, with the current implementation, in order to add a condition to make sure the triggers don't always run, I have to permanently add the same condition to each trigger, and allow the user to change some variable in the condition. With a CONDITION variable or an eval function, I could simply put any condition I want for all of the triggers and it would be added in.

Falkoner, what about your problem with Anywhere location? Sorry, haven't noticed your PM.

Ummm, developing your thoughts one condition might not be enough then. Anyways, you can transfer a switch to the macros definition and check it in every trigger. The switch hold the required condition and must be set by triggers before invoking this macros.

Post has been edited 1 time(s), last time on Sep 20 2009, 9:55 pm by Wormer.

Would you also be able to assign more than one condition or action to a variable? This would allow you to modify great amounts of trigger by simply modifying the variable definition. A good example would be with a text based menu. When I created my menu, I found that each trigger that displays an "empty" slot in my inventory required another condition. That was a couple hours of tinkering, which could have been resolved in seconds if I had the triggers I need to be modified all have a variable as their conditions, in which I could add remove or modify the trigger conditions.

Yes, of course that is the work around I was already planning on doing, but it's definitely less efficient, since usually you can reuse the conditions from the trigger that would be setting the switch in the Binary Count-Off triggers.

Honestly, it seems to me that all you really need is the ability to put a string variable in a blank spot and have MacroTriggers put the text for that string there, and then perform the other compilation functions.

Alright guys,
here comes a minor bugfix related to the generated SCMD triggers syntax.

The following Macro Triggers actions

Generated the wrong SCMD actions (with the misprint marked in red).

FIXED. The new version 1.6 available at download section of the head post.

When using long strings, specifically those with line breaks and such, it seems like MacroTriggers should autoconvert it, because if you compile something, in this case I had this:


That's the output from MacroTriggers, however, it doesn't compile in SCM Draft, because SCM Draft has a special character for line breaks, it seems like that should be automatically created with MacroTriggers

Use strings concatenation, it is made mostly for formatting purposes. You should have written like this:

Hmm, it still seems like line breaks inside of a string should be converted to the linebreak character SCM Draft uses.

Wormer, within 2 weeks I'll finish up doing small test maps and I'm going to begin work on my actual map, so I'd really appreciate it if you fixed up any bugs, or inconveniences, I don't mind doing workarounds, but if you're going to fix it, I'd rather you did it now, instead of me learning it one way then having it get fixed.

I seriously doubt you're going to end up doing something with text triggers that makes adapting to version changes prohibitive.

Yeah, but I like having my stuff be uniform, not suddenly get a new feature and wish I had had it for something I had to brute-force earlier.

Well, you could try switching over to Azala's Python bindings if you really need that nearly irrelevant extra bit of power. Or heck, I could even clean up my crappy Javascript bindings and send you those. Or you could even write your own Macro Triggers version based on the spec file that comes with MacroTriggers and using the same ANTRL parser Wormer used. Might want to study up on this for a bit, first, though.

Edit: Well, maybe I shouldn't call it 'nearly irrelevant'.

Post has been edited 2 time(s), last time on Sep 28 2009, 9:39 am by Tuxedo-Templar.

No you're right, don't use my custom functions, I'm not maintaining them at all.
They're just an example of how you can use a scripting language to quickly define your own.