What are you looking for here?

You can copy a trigger in SCMDraft and the string will be copied over, alternatively you can open up the string in SCMDraft, hit ctrl+C and it will be copied to the clipboard which you can then paste in another trigger (ctrl+V).

A way to copy strings without opening up the string? The ability to copy actions? A view of items recently copied to the clipboard?

Is there any reason to use SFmpqapi over StormLib?

it was what was suggested to me, should be ez to change if I decide to

https://github.com/jjf28/Chkdraft/blob/b066c4b8ffca3ea9e8ab4fecc2d3618e38a2f257/Chkdraft/Source%20Files/Windows%20UI/DataTypes.h
Just a question, why aren't types defined by <cstdint> used?

didn't know it was a thing, but why i'll prolly continue not using it is cause mine are shorter and don't use the _t notation

you'll also see the same notation defined in basics.h in the mapping core

Well the types defined by the header will have guaranteed sizes, though it looks like the Chkdraft project isn't meant to be portable so it's fine I guess.

Have you decided whether a plugin system is viable or not? It would be a really cool feature to add in.

My first pass at plugins (message based). After a while I decided some sort of dll/sub-gui-able plugins would be nice, so i'll do some more work on it some time.


I suppose I could define them using the <cstdint> variable types , the GUI portions aren't really meant to be portable (being built on pure windows stuff) though mapping core I've tried to keep fairly portable (though SFMPQ will probably have to go to get it fully independent from windows, but Scenario and below are good to go AFAIK)

Edit: replaced them with typedefs using the cstdint types, I was worried about having them multiply defined but I guess that's not an issue with typedefs.

Post has been edited 3 time(s), last time on Apr 6 2015, 11:38 pm by jjf28.

AFAIK, Stormlib is portable, has good documentation, still maintained
GUI stuff could be written using Qt(instead maybe also offer command line feature for users not on Windows, or those who want to automate stuff like triggers)
Strings, filesystem, etc. could be handled by Boost(I recommend using utf8 strings so that for example, korean maps can be opened and translated)

The latter 2 libraries are quite large unfortunately and have somewhat of a learning curve.

SFmpq will work on Linux and Mac (I use it for PyMS and I am on a Mac). It is 32-bit only though the last time I checked.

Re-posting these (they were in shoutbox) so I can refer to them.




As discussed it will be in listbox/full sentence form by default for easy reading, if you select a condition/action it will transform to the listview form you see above for editing, if you click off of the listview it will revert back to listbox/full sentence form, cells will have suggestion dropdowns, double clicking some cells will bring up a larger editor.

Update 2015-06-04 - Download Latest

It's a bit lighter than I wanted this update to be (wanted to finish conditions and actions, but getting ListViews to work like excel was no picnic, and heck I still haven't started carets and editing).



Feature changes:
    - Finished trigger-players window
    - The trigger modify window now swaps the selected trigger upon selection
    - Drastically improved string processing time (editing a string in maps near the string limit went from ~40 seconds to real time; this processing time is also shaved off text trig compilation)
    - (Started on the conditions window, not yet functional)

Bug/Error fixes:
    - Fixed a text trig bug where flags were not checked for when there were no actions.
    - Fixed a bug where using the single-trigger-text-compiler would not correctly add most players
    - Fixed a bug where addTrigger improperly appended triggers to sections

Code changes:
    - Fixed an inconsistency where text trigs checked for quotes on players in the ParseTriggers function when condition and action arguments did not.
    - Fixed a bug that was previously hidden by player quotes check, where the text trig compiler would search for ,'s and )'s (player terminators) past the trigger header terminator '{'
    - Changed the execution flag's group box to a fixed height
    - Made player window appropriately resizeable
    - Most string handling functions now use a vector rather than a list, addAllUsedStrings now internally uses a hash table to prevent duplicates and is now called less often during composite string operations.
    - Created most of the functionality for GridViewControls which will be used with conditions/actions (and probably several other editor functions)
    - Lots of touchups in various code files

Post has been edited 2 time(s), last time on Jun 5 2015, 4:29 am by jjf28.

Most of those options are useless >99.9% of the time, and it really clutters the UI. Consider having a "Show Advanced Options" checkbox or a configurable setting that hides them by default, so as to avoid scaring away or confusing users.

Yeah only "executing Players" should be shown by default. Hide the rest until someone activates it in the options. Not sure if there ever was a practical use of the other parts yet.

"For each trigger cycle this trigger will run thrice for Player 1?"

No, it can't be. Since childhood mom told me Triggers are run once per cycle no matter if Player 1, Force 1, and All Players are all owners altogther.

You might find this topic interesting: http://www.staredit.net/topic/11981/

I'm sorry for a little offtopic, but I don't understand then. I always thought there are 8 subcycles in each trigger cycle, where for i-th pass SC engine executes triggers for i-th player. How it turns out those triggers execute several times? And when the additional trigger copies are executed? For instance if I got Player1 and Player2 in Force1 and two triggers


What is the order of execution?

First lets discuss trigger generation at runtime, then lets look at the order: You got Triggers for P1-8. That's 8 triggers, 1 for each player. Then you got the forces which gives everyone another copy of the trigger. And again for All Players. Yes, triggers aren't stacked together, they are created in a kind of dumb fashion whenever the parser hits a trigger owner that refers to the current player.

The order in which they are created and thus executed per player* is visible when you mark all triggers and all player groups and then check the trigger list.

* meaning this applies to one player's execution order. The well-known rule that first all triggers of P1 run before any of P2 run remains intact.

OK, thanks Nude, I tought for a moment I was missing something important about triggers all these years =) Well, that's interesting because in the map it is stored as a single trigger according to Roy's link above.

is there any way you can make the string editor window resizable? it's very painful to scroll through now when you have lots of strings.

also a way to deal with strings like the text trigger editor could be nice.

Post has been edited 1 time(s), last time on Aug 12 2015, 2:59 pm by sigsaucy.