Yeah it's definitely not hard. Even easier when you know how to code your own language parser instead of scripting bindings.

Of course, you'll need to wrap your brain around some programmatic concepts to do that. The main reason I like Wormers' is simply because, being written expressly for triggers, it requires the least "learning" of any comprehensive macro option; if you get the basic idea of trigedit, and you understand some simple stuff like variables and loops, you're set to do 90% of anything you could ever want.


If I can arse myself to do another map after my current set, I may try using a full-fledged scripting approach for a while and see if that level of power does indeed pay off when put to use.

I'm pretty much fluent in C++, I have enough programming experience to do that, that's not the problem, I just don't want to open up another project that could take an unknown amount of time.

Well, if you want a reference, it only took me 2 and a half days to make a decent set of bindings in Javascript. I probably could have squeezed that into a single day (or less), if I were more efficient.

If you were to make something you'd want to release publicly, though, you'd want to allocate a week's worth of time. Alternatively, you could try to polish it as you work on a map project with it simultaneously. I'd be interested to see how something like that would turn out.

Well I started to make a Python script which would make it quite easy to write triggers in Python code somewhat like MacroTriggers does, but with all of the power of Python. A very basic example would be:

Which shows you don't need to do any extraneous syntax to make triggers. A more advanced example which easily makes your hyper triggers:

Another nifty thing is that the Triggers, Conditions, and Actions are all objects that can be easily accessed in any way you would like. For example, if you want to define your hyper triggers at the top of the code but still want them at the end of the trigger list, you can do:

So in the code i made one trigger object (but told it not to add it to the trigger list with add=False) then defined its conditions and actions, then at the end I added the trigger to the trigger list 3 times (instead of making three different objects with the same conditions and actions).

So since Wormer has said he doesn't plan to fully support MacroTriggers anymore, is anyone interested in this?

Edit: Is there somewhere I can find the keywords etc. of SCMDraft triggers? Thats all i would really need to finish the project.

Post has been edited 2 time(s), last time on Sep 29 2009, 8:16 pm by poiuy_qwert.

Those are useful features. If I start any new projects, I might give it a shot to see how much use I can make of scripting language features with triggers.


Hmm. All this discussion is making me think I should try finishing my trigger editor after all...

Post has been edited 3 time(s), last time on Sep 29 2009, 8:40 pm by Tuxedo-Templar. Reason: fucking typo

Ah yeah, I forgot to mention that little thing, I major reason I want to use MacroTriggers is the autocompletion and such in Notepad++, just the documentation for it makes it so much easier.

Alright,
I personally don't hold adhere to the opinion. Most general programming languages don't allow linebreaks inside of strings, neither does MT. I believe the code formatting and it's essence must not influence each other in any way.

Okay Falk, there are no crucial bugs I know of. I'll try to fix any revealed essential bugs as fast as I can, though at the moment I don't mind fixing something which has admissible workarounds, namely 1) @AllPlayers not being acceptable as trigger owner (defining "FORCE AllPlayers = @F('All Players')" works perfect) and 2) defining local variables in loops (workaround is to introduce "IF @True THEN ... ENDIF" for the local scope).

Further, I am sorry Falky, but I really don't know when I am going to implement such new features as the customizable conditions and LOOP/IF-statements inside of triggers. Such changes will have extremely spontaneous nature, it might be done during the next month, during the next year or not be done ever, with all variants being equally feasible.

That way, my personal suggestion for you is to start the map and don't rely on the fickle circumstances. Look, if you accomplish the map with the features available and then a new feature will appear don't be upset - your map would be done at least, but if you'll wait for the new features you're very risking not to accomplish the map ever.



Well poiuy_qwert, this nifty thing with the defining the trigger before it's usage might sound nice and funny and everything, but what is it's real use in real triggering? I can't think when and why one would want to define some trigger before it's usage? As a side note, you can achieve the same effect defining a macros in MT.

Then, I personally don't like saving up a couple of words omitting keywords "Actions" and "Conditions". This makes triggers less visual which matters a lot in large projects.

I want to be clearly understood. I do support MT but I don't develop it at the moment.

There is a list of actions and conditions coming with the SCMD distribution (the file "trigedit help.txt"). What else do you need?

This was just an example to show that Triggers, Conditions, and Actions are just basic Python objects which can be treated as such. Its not the best example.

It is pure Python so I can't just add in my own keywords/blocks. If it was really needed a comments and even a useless if could be used for formatting:


Ah, my mistake.

I just need Keywords as in the valid argument settings. So things like "At least", "At most", "ore and gas", etc. I finished all the types that are present in the conditions (when I got access to a Windows comp) but I need the left overs that are only in actions.

Post has been edited 1 time(s), last time on Sep 30 2009, 8:00 pm by poiuy_qwert.

I already use NP++, and Macro Trigger's color scheme clashes badly with my skin. (I can't what I'm editing without highlighting )
Under style configurator, what language is it?

In NP++ go View -> User Define Dialog...
Choose mtrigger under the User Language box.
Adjust colors you wish.

You should replace the Unused Units list in Tuxlar's Information with this one:


That's a list of all units that can't be killed in game, so basically any unit that you can use for Death Counts without any fear of them being killed.

Can Khalis and Uraj crystals (powerups) be killed?

Donno, maybe I missed a few

Hey everyone,
Is there a way to randomize 64 different possibilities using switches, while for each one of the many possible outcomes contain a different "create unit" trigger by using arrays?

I've been stuck trying to figure this out for a while, so help would be greatly appreciated.

You can easily map an array to individual fields of a trigger action, but you cannot map conditions or actions to individual triggers. Wormer hasn't implemented the ability to treat conditions, actions, or whole triggers as data.

I am afraid I was unable to comprehend what you were suggesting.
Does that mean I can place a "FOR" syntax JUST for the condition and another "FOR" syntax just for the action parts of a trigger?
If not, please correct me, and add a few examples if you have the time.

NothingZ, this is the example you need.
64 = 2^6, hence q=6 and you're using 6 switches instead of 8 in the provided example.

Afterwards, if I understand right, you need the replicated trigger to contain the action CreateUnit(m, u, p, l), but each time with different parameters. The simplest (in terms of understandability) way (or if each outcome is completely individual) is to make an array of 64 elements for each 'changeable' parameter m, u, p and l: CreateUnit(m[n], u[n], p[n], l[n]).

NothingZ, I wouldn't even do it that way, I would use single switch randomization to get your number, and THEN you could use MacroTriggers to create the outcomes if necessary.

Falkoner, actually using direct switches randomization requires less triggers and hence is more effective.

Depends on what you're going for, also, using switches becomes impossible when you require numbers any more than 65536 outcomes, I mainly like it because it's easier to work with, but the main advantage of it is if you need a non-binary amount(can be done by using larger numbers and dividing it up), or if you want multiple outcomes within a range to have the same outcome.