Staredit Network

I am asking for your preference on a Trigger GUI. This is not a VS thread I'd just like to know what you would prefer and why.

-Staredit Based GUI
--Not text based at all.

-Starforge Based GUI
--Somewhat Text based.
--Shows you Syntax.
--Guides you through each trigger.
--Customizable Syntax.

-Text Based GUI
--All features current Starforge GUI has.
--Shows all Triggers in a Tree for quick navigation to each one.
--Toggable Syntax Highlighting.
--Advanced Syntax Debugger.
--Customizable Syntax.

-Other
--List your own idea.

I prefer Starforge's text based editor because it is faster but I always end up using SCM Draft's class trig edit because Starforge's is a little confusing with display text and ai scripts and such.

Staredit is too slow for me.
Starforge is best for me, especially with autocomplete. It's not confusing at all.
SCMDraft's text-based editor is slower to work with than Staredit.

Classic. I've never taken the time to learn text triggers.

I am not comparing Starforges to Scmdrafts in any way. I am simply asking what style do you like better. In terms of Syntax what if the Ai Scripts were nice and easy and even listed for you for both Starforge Based GUI and Text Based GUI. The Syntax would be very easy to understand and be well documented.

I am basically asking in what GUI would you be most proficent in Triggering with. For me it's pure Text but I am not everyone so I would like to know before I continue my work. Although if I don't get enough answers I will create just a Text Based GUI.


And what if the Text-Based one had auto complete, a list of all the triggers that you could double click and get there syntax. It would show you each Triggers syntax similar to what Starforge does.

I am not comparing Starforges to Scmdraft 2's. I am comparing a set up similar to Starforges vs A Completely Text Based system with all of the same features and more features.

I would like something sort of like autocomplete in BASH, you press tab and it scrolls through all applicable things, like you type P and then tab and it autocompletes it to pauseGame and you press tab again and it changes to pauseTimer and then you press tab again and its playWAV and then again and it says preserveTrigger.

I want a text-based one with autocomplete and an option list (on the side) that automatically puts everything into a staredit-like form for easier reading and understanding of triggers. The triggers would look like Staredit triggers but you would only have to type in what you want (or select it from the list), not the whole phrase that it shows, and you could copy-paste them and everything. You'd get the speed of a text-based editor with the ease of Staredit.

Nice ideas Doodle and Wing, keep them coming.

» Text Based GUI
That doesn't make any sense.

Starforge's style of triggering is very well thought out. They are very easy to comprehend and use, and are pretty fast. However, I haven't spent any time to learn more than a couple of text-based triggers; if I did, this would definitely be my fastest way to trigger. Even without knowing any syntax, quick copy/pasting and editing of triggers make Trigedit a great choice. Classic Staredit triggers are nice, but are way too slow. Usually when creating triggers, I'll create a base in the Classic Trigedit plugin and then open up text-based Trigedit and go from there.

Well just to let everyone know what im working on and how far I am I guess I could give a glimpse.

Current Projects
Project Alanah is a C++ dll of mine. It is my dll for interacting with the CHK itself. It contains the SFMPQ static library to open archives, maps, etc... Once opened I can read from it. Most of the work on this is completely done I just have to add functions for writing back into the CHK. It's been fully debugged and tested and works 100%. I will document the dll for other applications to utilize it.

Project Surfus is a C# application. It is the main GUI of everything. It uses the Project Alanah to read\write to the maps. I have already tested interaction with another C# project and Project Alanah extensively to be fully debugged and working.

Syntax and the GUI
Syntax will be overall loose. It wont be very strict, infact I will be trimming all unneed spaces and it dosn't matter if you press enter during the middle of a trigger. Capitilization wont matter. If you forget something the Compile\Save button will bring you to where you gotta be and give you a broad idea on how to fix it (Trigger not closed, condition not closed, action not closed, etc..) . I made a quick test of compiling the text that included just about everything above so most of that shouldn't be to hard.

Mostly everything will be customizable by text files. Most of this is already implemented. Syntax will not be right away, but I hope to eventually devise a nice method to implement this. Heres a picture that will give you a quick idea of the first GUI.

It looks good...

The only aspect I don't like in that screenshot is having to type out which players you want the triggers for, as well as the squiggly brackets. :/

Well inspecteur you must remember this is completely text based. Remembering P1, P2, P3, F1 shouldn't be to hard. P being player and F being Force and AP being All Players. You will though be able to double click on the players in the Syntax Tree and it will add the proper text in for you.

The brackers are there to seperate conditions\actions. I could make one set of brackets that can hold both conditions and actions, although I believe two sets make the code neater. I at least need a way of knowing where a trigger starts and where a trigger ends.

I will eventually make a simple add trigger function that will remain similar to staredit and add in the proper text for you. This I believe will be a great way to learn the syntax. Infact there was a tool like this for HTML that got me into web site making.

I think he ment the fact that you need to hold shift to make squiggglys. Make it square brackets. []

Squiggilys are tranditonal code block separators in programming languages

Yep doodle lol. Since i've been 11\12 I've worked with squiggilys!! Anyway I will throw in code so you can either use {} or []. If you want I'd even add in an option so you could choose if they are [] or {} when you open a map.

Anyway I through in some test code for writing to an archive. I had an error so that pissed me off for a few hours....you wanna know what it was??? One simple overlooked thing. I had to put in the length of the buffer....I used nNumberOfBytesToRead...but the length of the buffer was nNumberOfBytesToRead + 1. Yeah spend a few hours debugging something to find it's as simple as that.

Depending on what im doing tonight I'll try and work on the syntax debugger\compiler. I got the basics already in the program. Most of what is required revolves around getting all the conditions\actions in there and then I have to throw in code for the string section of the CHK. Fun Fun....

Do you think you will release Project Alanah to the public with a documentation?

Actually I am working on another project to replace Alanah. It's called Oreo. It covers every(Hopefully) section of the CHK.
It currently has the Type, Ver, Iver, Ive2, Iown, Ownr, Era, Dim, Side, Puni Although I havn't tested them they should work, testing will go on tommarow. The one im most worried about is PUNI although simple tests show my equation is right.

Alanah was oringally just for me to get a dll to access the archives and read the CHK. Alanah has been a learning experince. I remember when I first looked at this stuff how confused I was. Now I know it pretty damn well. I will continue to work on Alanah for writing to MPQ's which then I will implement furthor into Oreo.

Oreo will not accept wrong data and will return an error. All errors are documented on each function so you will know whats wrong. I've also been documenting functions as I write them. On a side note I'm not sure if I will add in terrain sections. Do I need to add in the Vcod section? I probably will....not sure why anyone would want it.

I do have the full intention of releasing Oreo and its export files. Oreo is a managed dll so implementing it should be a snap.

Also Heimdal did release the dll for Starforge and documentation if you want to look into that.

Also all of my code has been built on the free Visual C++ 2005 Express with SDK header files. Allowing anyone to modify the code for free.

I like your project names, heh.

Add in VCOD, incase sometime in the future it randomly changes or something

Please add in terrain sections, and even better when you get a spare moment teach me the basics of terrain. I know NOTHING about it

Starforge.dll is HORRIBLE for terrain. It places it the exact same way Starforge does. ISOM = horrible.

It'll be hard to learn ISOM and some sections ill contact SI and do some of my own debugging, but terrain sections will be the last implemented. I'll add in VCOD when I have everything done. When I begin sections for writing I will definently include a section such as VCOD. All VCOD holds is a set of bytes that never change. It's basically a code that staredit makes sure is there before it opens the map. If the section is missing or it's bytes are different it wont open it. Could be a simple protection scheme blizzard thought of...to bad they never thought we would of figured out the CHK let alone storm and staredit functions.

The problem with the ISOM section right now is that I have no documentation for it. None what so ever so this will be the last implemented.

Heres a question, should I just pass a pointer of all the bytes in the Trig Section or should I have a function that returns a condition\action as a string based on the trigger number and condition\action number you provide and create another function that returns how many Triggers there are?

The way I would do it is:

Split the trigger section into sort of a "tree" of arrays:



Then you could have a function of:



Something like that, it provides full customability

Well I cannot return an Array. I can return pointers and refrences but I want to stay away from those.

Therefor I can technically only transfer over one piece of data at a time on less I put them in a string and they have to be read as a substring. The eaisest way, when transfering one piece of data at a time, would be doing what I oringally did with Alanah:

I had a function like,
GetTrigger(int Trigger, int X, int data)
{

}
X could be something between 0 and 15 for a conditon and then 16 - 79 for an action. Data would be what piece of information you wanted. It could be between 1 and 11 with 0 reserved for returning the number of triggers in the section.
Because there are 6 action longs and 4 condition longs. Therefor I take the higher one which is 6. They both have 1 int, and actions has 3 bytes while conditions has 4. 6 + 1 + 4 = 11.(You may not understand all\any of this if you don't know the Trig section)

Basically you could do a simple while statement and construct the actual triggers on the programs end. I would have documented what each long, int, and byte do so you would know what ot request. It would return -1 on if a trigger didn't exist, if you requested something for an action when working with a condition and vice versa, if you requested a condition\action beyond 16\64.

Although in Alanah I split all these into probably 3 or 4 different functions which could be done in one single function.

Another thing is that I never actually store any data besides the entire CHK in bytes on the dll. So when you request something I find where the section starts and then what you request I use an equation(depending on what your looking for) to find the right piece of data. Then I have different functions for converting bytes to ints and longs.


Now see this could be somewhat tedious and I would like to streamline this. The only question is how in the world would I do it without an array\reference?

What I would do is create CCondition, CAction, and CTrigger classes. CCondition/Action would contain all the stuff associated with one particular thing (trigger type, parameters, etc.), and CTrigger would have an std::vector of CConditions and CActions. Then you could return all the triggers as std::vector<CTrigger> from your function.

Yes but does C# support vectors? If C# doesn't support it im not doing it because my program is in C# and well im not going to include something so it's entire purpose is defeated. As far as I know vectors are not on C#.

Ah, my mistake. I do not have any experience in C#. Oh well.

C# is nice but it is still quite a developing language. Perhaps when Vista comes out with the .net SDK 3.0 we will see it mature more.

I will probably do the same thing I did with Alanah but keep it on 1 function. That way im not opening up new buffers.

ADDITION:
Heres a question, flags are stored as bits.

Would you prefer all the flags sent over as a int\string or having to request them from the function indivdually? I'm guessing sending them all over as a string? That would allow you to take a substring and read each flag.

There will be a seperate function for retrieving flags except for triggers\mission briefings.
For Triggers I am going to probably do something like this,

TriggerNumber is obviously what trigger number it is
Type would be 0 for condition and 1 for action
Entry would be what condition\action.
LPCSTR ReadTrig(int Triggernumber, int Type, int entry)
{

}
how it would return is this:
First 2 numbers in the string = condition\action number
Example: 00, 01, 02, 10, 11, etc..

For conditions, the next bytes. Based on what condition you should be able to figure out what the next bytes are. They are also in the same order as they are found in the CHK:
If there is a location the next 3 numbers
Example: 001, 002, 003, 004 etc...

If there is a group the next 2 numbers
Example: 01, 02, 03 etc..

If there is a number I can't anticipate for I will put "" around them so therefor when you find a " you keep reading until you find another " and the number between them is the qualified number.

I think you get the point, anyway I'll document it extensively. If you want to know what numbers come next just take a look at the documentation:
http://www.campaigncreations.org/starcraft...chkformat.shtml


The next section I have to do is the MRGN & Trig section and once I get that done I will work back on Surfus. Then I will have every section to make a complete trigger editor.