Holy freakin crap. I've been hoping for this for so long. i think its best to keep the SF trigger editor. i could trigger so freakin fast with that editor. Plus its kind of like scmdrafts text editor combined with Classic.

Exciting! I've been waiting years for thisssss! I also like the trigger editor, its actually like you're programming your map!

Omg <3! I've always been a StarForge user, even now. Hopefully all the features in StarForge2 are in this.

I love the changes. I love the mix between StarEdit-style blocks and the SF-style triggers. Now I don't have to search through masses of "No Comment".

By the way, are the text and player colors accurate? They look a lot darker or something... I can get a list of colors if you'd like (I have them laying all over). ;o
Also I have formats for fnt files if that interests you for the string preview...

Will it include a commenting system which doesn't consume string usage? I believe this is NECESSARY.

definitely. Also, don't forget location/switch naming.

Just to be clear, this text trigger editor will have some sort of AutoComplete right?

As you can see in the String Table screenshot, SF:U can identify strings that are only used in non-critical items - that is, location names, switch names, comments, etc. When you save your map, you have the option of saving these strings in a secondary string table, so they don't take up room in the main one. SC ignores this table and the map will play as normal. No other editor will be able to correctly use a map saved like this, but SF:U can switch between saving modes easily if you need to use another editor. Similarly SF:U can turn string recycling on or off, so it can play nicely with editors that don't support recycling. It's also an easy way to unrecycle strings if you have a map that already has them recycled.

SF:U's trigger editor has the same autocomplete support SF1 did, plus a few improvements. As you can see from the Trigger List screenshot, each trigger has its index labelled, so you can see what order triggers evaluate in. You can also save and load triggers in SF or SE file formats.

Signed up

I'd like to help in any way I can, so I signed up. ;o
I can do any sort of data collection, formatting, etc. If you need any information related to SC (such as fonts, colors, etc.), I can get that too (though I'm sure you probably could, too).

This alone makes buying a laptop worth it.

Make it install friendly this time around, there seemed to be a skill to it last time !

I never had a problem..? Just install it? ;o

I had it installed after trying 100 things, then when I got a new computer I couldn't for the life of me solve the riddle of missing files.

This is great

Considering strings I would like to suggest reusing the same strings data for similar strings, when one string is the tail of the other string. For example, if one uses two strings: "<03>Item" and "Item" in a map they share the single strings data block: "<03>Item". This little improvement to strings recycling is very useful when implementing various in-game menus. Read more.

About trigger editor. MacroTriggers is not flawless. If one wishes to make an advanced text editor for triggers, implementing macro capabilities for triggers replication, I can help him with the design. I have got some fresh thoughts on this topic.

To my mind a perfect trigger editor should not be either fully textual, nor fully user interface based. Such an editor should combine UI and text as a one. To get an idea of what I am talking about, have a look at the picture:

Currently selected trigger is in the blue box. From current selection you could select previous or next triggers pressing up and down arrows. If one wishes to modify the trigger he presses Enter, which moves focus inside the trigger and toggles to the text mode (just in place!). After finishing he let's say presses Shift+Enter which saves changes to the trigger and pops user up to the triggers selection level. If user wants to add a new trigger directly below the selected one he presses Ins. There are collapse boxes (red on the picture) to collapse triggers (also one can group triggers and collapse whole groups, then he can group groups of triggers and so on). One can write trigger comments which display directly above or below the trigger not hiding actions and conditions (unless collapsed). Also one can assign labels to triggers and display only triggers with the specific label.

A perfect example of such an interface is a Google Notebook plugin for Mozilla Firefox, which looks like this:


Also capabilities for triggers replication are strongly required. The design should support specification of replication of the desired trigger. This meta-trigger will then make up a group of similar triggers, which could be previewed but should be stored in the original form. I don't know how to explain it well at the moment, but if you'll have a look on Tuxlar's Astrogears triggers you'll probably get the point of what I am talking about.

With my experience of MacroTriggers I came up that other things which are required for a handy triggers tool are capabilities to define different "variables" (or in other words a way to give various names to map objects), to evaluate expressions with these objects, to specify raw conditions and actions in text way, and to define user conditions and actions via existing ones (technically, if one has means to define conditions from other conditions, only two kinds of "native" elements are required: raw condition and raw action, all other conditions and actions are defined via these). Read more.

All the data is pretty much collected up already. It loads the player colors and the fonts from the SC files. Right now the string textboxes use a Windows font but I'll eventually try to make them use the SC font. I might need some help to get overlapping working the way it does in SC, but that's it.



Right now SF only needs the .exe and a data mpq to run which can be placed anywhere with no installation. For the public version the data mpq might be embedded inside the .exe meaning it'll only consist in one file. It can't be simpler to install.


Well my original idea for my trigger editor was making it C-like with a preprocessor. Then have the triggers split in several files and a #include directive. That'd allow the user to classify the triggers in several files then include them in the main file.
You could also do things like #include <HyperTriggers> or something like that.
Still long time to go until I start coding another trigger editor, if I ever do...

Hold on...

Is this... a joke? A dream? Did I die?

Wait just a minute, I need to whipe the tears from my eyes.

That is reasonable. You could simply (YEAH simply ) make an extension of the C language with additional function-level constructs to specify triggers, like: "trigger T { owners: <players list> conditions: <conditions list> actions: <actions list> }" (this reminds me of "class A { public: ... protected: ... private: ... }" ). You then can have two kinds of new objects (conditions and actions) with definition syntax like "condition <identifier> <formal parameters> <definition body>" and "action <identifier> <formal parameters> <definition body>". I believe that is really almost all you need to add to C language. Then you probably need to write some kind of standart library with types definitions, common conditions and actions definitions, unit definitions and such. Writing a C compiler probably is not a very difficult task (but still). Moreover you don't need to generate machine code. But this is only a language part. Then you need to write a good Integrated Development Environment for your language, with syntax highlighting handy UI and such and such, which is probably even harder than writing a C compiler itself.

this looks like it will evolve to the editor everyone wanted...

very promising...
but I fear it came to late

Wait.... so this is... going to be better than SCMDraft?

Well, I am still going to use SCMD2 at least for triggers, because of it's text trigger editor I get used to and because of Tuxlar's triggering style I am inspired with.

Oh dear Si, it looks like you finally got some competition! Just joined the googley group and I can't wait to see how this stacks up to draft. Gl!

Post has been edited 1 time(s), last time on Aug 19 2009, 5:01 pm by m.0.n.3.y.

Then why do the colors look weird?