An essay on abstract nonsense of wishfull thinking about utopian trigger editor.

I am totally taken up with an idea of an *ideal* trigger editor. What are one's expectations? What features are must for such an editor? Lets turn our imagination on. I want to share my thoughts and will imagine a trigger editor being a part of my favorite maps editor SCMD.

We are pushing mapmaking to the limit, aren't we? But when it comes to triggering one impacts considerable problems having their beginning in big amounts of information he is dealing with. As a result it is hard to manage and edit all that information.

Firstly, there are fierce indignations levelled at the lack of ability to organise triggers well. One can think of organising triggers using comments, the problem is comments eat up precious map resources, the string limit in particular. People want to organise their triggers without using up strings. Trigger comments are kind of external meta-information about triggers which is used throughout development process only. Moreover one can think of more complex ways of organising triggers unlike simple textual identification. One may wish to divide triggers on logical groups performing logically atomic task. Ususlly these groups are just solid blocks of triggers simply following one another, but there are cases when totally diversed triggers can make up a group and one trigger may be part of different groups. One may want to observe and manage these groups seperately. This is the place where now fashionable idea of labels or tags come in handly.

Since talk is considering trigger organization I should mention one more thing: naming objects. Let's take me for example. Sometimes I do want to use *different* names for the same objects. The reason I'm thinking of this object differently in several cases. Let's take a Terran Marine. Terran Marine is a unit, but I am using it as a death counter timer for players in my map and want to refer to him accordingly. Also I am using deaths of Terran Marine as a counter which holds progress of players for a computer, so I want to refer to him as a progress counter in this way. You can see that Terran Marine plays logically different roles and I dont want to mix them up. Moreover I might probably wish to change the timer death counter unit for players later, keeping the Terran Marine for the progress counter for computer. I can easily do this with global substitution (or something) when I have different names for logically diversed Terran Marine occurances.

The same thing concerns conditions and actions too. The most vidid example here might be EUD conditions. I wish to refer to an obscure EUD condition
Deaths(Player2, Exactly, 256, UnitID:1061) as to self explanatory EUDKeyPressedA(). Moreover when I want to check value at some adress I dont wish to calculate extended player value, but simply input the addres here like EUDCond1161(0x596A58, Exactly, 256). These are only EUD examples but I might want to mark out non EUD triggers as well. For example give self explanatory names for triggers working with my personal death counters like MyTimer(Add, 10), where 10 is not number of trigger loops but just time in game seconds.

Secondly, people have always invented tools to reduce the amount of tedious work. What I mean is that one may have a pattern of thousand triggers in his head but implementing all of those one by one is not a work for a white man. My imaginable trigger editor should contain abilities for easy triggers replication following one or another pattern the person might think of.

It becomes obvious all this meta information about triggers organisation should be stored somewhere. Of course, this might be a separate binary file which can be read only by the trigger editor program, but I have another solution. As far as SC map is actualy an MPQ archive we can store this info as a separate file inside of the map. One cant find a better place as the map itself! This file should be a text file written on a special language which allows to specify everything I discussed before. The file can be found inside MPQ for example: "\scmd\scenario.trigger".

The language should be designed the way to allow easy triggering for new users but also should give an opportunity for experienced mappers to specify advanced triggers. This could be achieved the next way: the language should allow to refer to the raw conditions and actions data of chk format specified in the wiki. It's *native* conditions and actions have the following form:

But it's not handy to use them in that form. To achieve useability one can define new conditions and actions in some kind of *header files* stored along with the main triggers in the map's archive. There might be some kind of *standart* library with definitions of some standart triggers for new users. The best way to explain is to show an example of how it might work:


I have not finally came up with a finished idea how this is working, but it seems that main features have already went into my head. Well actually I've not written even a half of what I have in my head. There is just too much to write! What I've written is just the main ideas. The idea is this is not a finished essay! You all can participate! I want to hear your opinions! Please tell me how do you like it, write your thoughts, suggestions, expectations! Let's imaginate together, who knows, probably some day this will become a reality!

Post has been edited 2 time(s), last time on Mar 5 2009, 2:03 pm by Wormer.

Macros would be win. Assign a label with arguments to a bunch of code...


I started an editor...


;o
Concept trigger "editor" I made. All values are inside a txt file that is parsed. You could completely overhaul the entire format with minimal effort.

About it:
Rather than using specific text values, I've just assigned a list of labels that replace specific values. You could put 0 or "Terran Marine" and they would be interpreted as the same thing. Any label will have quotes, unlike SCMD, which is just terrible with that (I could not tell you what goes in quotes and what doesn't).
I haven't made it export a whole list of triggers, though.

Post has been edited 3 time(s), last time on Mar 5 2009, 9:46 pm by FaRTy1billion.

Farty, how are you going to store these triggers? Or are you going to reverse engineer triggers and generate new text (like SCMD does) every time one loads the map? How are you going to store comments and other custom text formatting in the last case?

You know, I am more interested in the underlying *language* design itself than an editor superficial appearance.

EDIT:
By the way, when I hear "macros" I usually think of initial text preprocessing with a macro processor which makes nessesary textual substitutions everywhere (even in comments) before it passed to the main parser. Are your "labels" working in the same way? Is there a way to specify my own "labels" for a particular map and use them along with standart ones. Can I somehow attach my own "labels" specification to the map? Is it possible to define aliases of the same value (I mean differently named "labels" which substituted to one value)? How do you plan to solve problems with reverse engineering an information about aliased "labels" from raw triggers data?

Are your actions and conditions typified? For example, player in raw actions data has a long type (4 bytes), but a unit ID is an integer (2 bytes). What happens in case user provided a long value for an integer type? Is there a way to specify expressions as parameters? Looking at the picture I can suppose there might be such possibility because you've specified: "Always Display" | "Unit Type Used", but reverse engineering triggers with arbitrary expressions will loose all information about an expression (exept some particular cases like bit fileds).

Are you planning an option for a user to name actions and conditions, like he does a naming for integer values ("labels")? If yes, how are you going to solve reverse engineering problem in this case.

I am asking because such meta information which is not included in compiled triggers raw data is extremely usefull for organizing triggers.

Post has been edited 2 time(s), last time on Mar 6 2009, 11:13 am by Wormer.

This thing doesn't do more than just viewing a .trg file... It was just a conceptual parser I made one day. A true application of this would probably either have a similar interface plus the ability to export everything to a .txt file of sorts. If you edit in a txt file you could always just recompile and not have to regenerate the data... If it were put into an actual editor, it could store some metadata that gets removed in some sort of "finilazation" function.
(Though this was useful for checking triggers I made for TrigPlug... I modified the data file to parse them.)

That's what I was showing. ;o I like the idea of having labels = values, so you can use specific values in their place.

[attach=3070]

All labels are defined in data\Values.txt with specific formatting... Stuff like:

The .txt file includes instructions on how to edit and format it. ;o

Action/Condition format strings are formatted in a similar/same way as other lables.. (and even in the same file)
Condition.cond=stuff
Example:
CountdownTimer(Number Seconds, Modifier Comparison, Flags Flags);
(I'd post a whole section, but that is a bit large. )

... Briefings aren't that large. Here is an example:


I've assigned each value of an action/condition structure with a name, so the first word (e.g. "Number") is the value (and label set, which can have :value after it to use a different label set (e.g. "Type:Unit", it is stored in the Type field but uses the Unit label set) and the second word (e.g. "Seconds") is just a name for that argument.

Attachments:

Post has been edited 11 time(s), last time on Mar 6 2009, 6:20 pm by FaRTy1billion.