If you are still looking for good icons, you could probably use the Oxygen icon pack. It has an icon for pretty much everything you could possibly hope for. It has a license that I believe would be compatible with your project:

You can get them from github: (Links to 16x16 version.)
https://github.com/pasnox/oxygen-icons-png/tree/master/oxygen/16x16/actions




Also, this project may make me want to get back into mapping.

Post has been edited 1 time(s), last time on Apr 2 2013, 4:33 am by Apos.

Any updates on this project?

working out the final kinks with units and unit editing

Hey, jjf28 what's happenning to the project? I relied big hopes on this one!

code-wise, alot is going on, though not terribly much worth releasing just yet

- Isolated a group of 'core files', these files can be used to make plugins or quick, stand-alone mapping programs (see location ripper)
- Separated map class into 3 classes, the scenario file, the map file, and the gui map, (scenario files is a list of all the chk sections, map file is a scenario file with a title, optionally with mpq details, gui map is a map file with a ton of UI details (ie: current layer)
- Ripped all the constants that weren't assigned by the resource editor out of resources.h, improved existing functions/initlizations
- Disabled everything but new/open + some stuff when no map is open

- Worked to mold things designed solely for tile editing so they would work for all layers
- Designed a 'quick paste' system that works with the existing clipboard (for things like selecting units from the tree and placing them, or a tile from tileset indexed)
- Redesigned undo/redo to be more simple and more extendable

- De-tangled most of the pure-graphics from the former map and maps classes, now graphic functions simply take in a scenario file (as some other classes do now as well)
- Working on a managed, ordered list of sprites for each map so they will be drawn in the correct order, and in the further future, with the AI defined frames/wait times

- Units are mostly done, undo/redo for them is finished, can edit properties and delete units but working on unit placement and copy/paste (what i'm working on right now)

Pleased to hear the work is going! These internal changes are usually something that is required for a quick progress.

Please tell me, how are you going to implement the plugins system? I'm especially interested in making a MacroTriggers-alike plugin for text triggers. It is going to read and store triggers in text files written in a specific language. I want to have an option to store these files along with the map in the mpq archive (there of course should be an option to store a "final" version of the map with everything redundant ripped). If a mapmaker choses to work with my plugin then these files become the primary source of triggers for the map in a sense that there is no way to reverse engineer and fully restore the full text of these text triggers files from map triggers themselves. I'm not interested in writing a text editor. In a nutshell my plugin is going to do two things: 1) invoke external program (text editor) on text triggers files stored along with the map, 2) on every change of these text files run a compiler that transfers text representation of triggers into the triggers sequence that your editor can understand (coupleing the info from text files with information from the map itself like location names, players names and etc.). Do you think something like this is possible to achieve?

Since you're working on units placement here are some things to consider: I wish there was a way to retrieve the unit ID (for purpose of EUD triggers of course) right from the editor (with all nuances like Start Locations doesn't assigned an ID and doodad units are always assigned IDs first and etc.). Also I wish there was a way to assign units IDs on my desire.

All in all, nice work there! I'm looking forward to a new version!

For plugins i'm thinking that i'll create a message that will send the plugin in question a pointer to the currently active scenario file (which should be sufficient for programs that use the 'core files').

I'll probably also send the program the same scenario file pointer as one of the startup parameters (argc/argv) if the plugin program is opened from chkdraft.

I actually have a text triggers system 90% complete, it would be very easy to read in triggers if sent to chkdraft as a character array (through another message or something). But you can also edit the TRIG section directly through buffer methods with the scenario file pointer if the 'core files' are included.

A 'Predicted in game index' is one of the things I plan to add to units but it will be just that, a prediction subjected to which extended units show up and so fourth.

As far as I understand this won't allow plugins to save any additional information along with the map in mpq archive, right?

Do you mean that you already have a text triggers language that chkdraft can read and transfer to map triggers?

I would rather love to pass chkdraft an array of triggers-classes in a specified format, since you already should have some classes for triggers. But probably TRIG section is just enough.

I mean I've already implemented most of a text trigger editor that reads and is a little more lenient than SCMDraft's, all that's left to do is write the condition/action ids and fields to the 'TRIG' section, currently it cleans the text, identifies the different condition/action/field strings, and has an empty space for writing to the TRIG section.

I'll pass the map file pointer I guess, but currently I haven't implemented any MPQ handling things besides reading the scenario file as that is handled by SFmpq, though dealing with WAV's and stuff will be done there so you should be able to edit MPQ stuff with that.

You can pass chkdraft the triggers in binary format (the way they appear in the chk file ref), but I haven't started abstracting TRIG data yet (though I will have by the time I finish text trigs).

Post has been edited 2 time(s), last time on Aug 2 2013, 9:24 pm by jjf28.

Ok, that's all is nice to hear. Hopefully we'll have time to discuss it when more stuff will be done.

glad to see progress is being made

Update 8/9/13 - Download Latest



- Tileset Indexed added, displays with tile values if option is on
- Separate tile number displays for MTXM and TILE, now shows 'DNE' for the tile value if the tile does not exist
- Undo/Redo for tiles
- Display tile elevation option under view/terrain, green for low ground, blue for med ground, red for high ground, darkened colors when unwalkable
- Began updates to tile properties window (incomplete)

- Player color for units
- Modeless unit properties window (syncronizes your actions in this window and on the map, undo/redo currently forces a full refresh)
- Unit selection/creation/deletion
- Unit moveup/movedown indexes
- Unit undo/redo (index based, for ex: undoing a unit delete will recreate the unit at its old index), includes creating, deleting, changing a property, and swapping indexes

- Updates to view-only mode (for protected maps), properly handles layered MTXM sections
- Updates to... so many things... (some of which were listed a few posts earlier)



Upcoming:

- Removing the cursor lock for quick paste items (units selected from the left-bar's tree, tiles selected from tileset indexed)
- Text trigs
- Basic plugin framework
- The asterix that tells you when saving is done
- Graphics restructuring
- Locations or Sprites

Post has been edited 2 time(s), last time on Aug 9 2013, 8:47 pm by jjf28.

Update 9/9/13 - Download Latest

- Tile Elevation now displays within Tileset Indexed
- Cursor lock removed from chkdraft entirely (at least for now)
- Move Top, Move End, and Move To buttons now functional ('Move To' prompts you for an index to move your units to, of your selection, the unit with the lowest index will occupy the slot you specified, and they'll increment from there, unless you specified a value that was too high to fit them all within the current amount of units, in which case this will behave like 'Move End')

- bug fixes with move down, move up and their respective undo/redos
- fixed an error where the same unit would get selected multiple times (and cause more errors)
- fixed some errors where changes to multiple units were not undoing/redoing properly
- fixed a bug where selecting the last unit you place, to place again wouldn't start the unit placement process
- fixed a bug where selecting a unit to place wouldn't clear your current selection until after placed

Upcoming:

Same as last minus cursor lock

Post has been edited 1 time(s), last time on Sep 9 2013, 11:20 pm by jjf28. Reason: typing words inProgrammingSyntax

Update 10/17/13 - Download Latest



Updates:
- Text trigger input (not output), completed (beta).


Rules:

- Basic format is just like SCMDrafts: Trigger ( player, morePlayers ) { Conditions: conditionName(conditionArgs); Actions: actionName(actionArgs); }
- Condition names, action names, and argument orders are the same as SCMDraft
- Quotes are ignored unless their use is imperative to avoiding ambiguity (meaning they should always be used for strings and named parts of the map (ex: locations, wavs), even if they are sometimes accepted otherwise, if you fail to use quotes for a string, it will be capitalized by the text cleaner and will probably not reflect what you wanted)
- Names as defined in the map are accepted for: Locations, Units, Switches, Wavs, and Groups (players)
- Default names are always accepted for units, switches, and groups, as well as some shortened forms (ex: f1 for force1)
- All default names are cap-insensitive
- Numeric Values are always an acceptable substitute for a field (ex: you could enter a 0 in the location field instead of '"Location 0"'), keep in mind that many items are 0-based, so a 0 in a switch field equates to "Switch 1")


Other info:

- 'Memory' action available
- 'Custom' condition and 'Custom' action are new, 'Custom' condition's format is: "Custom(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9)", where arg1-9 are the fields as shown HERE, same deal for action's format ("Custom(arg1, ... , arg11)"); in addition to accepting raw numbers, the custom condition/action also accept any form of text that would be stored in that field (ex: you could put 'Terran Marine' in the unitID field).
- Arbitrary 4-character script names (as well as numbers) accepted (note: this gives the user the responsibility of ensuring a script name is valid).

- Separate compile and compile & save buttons (so you can hit 'compile & save' and the map will compile, and if it's successful it will save (or open a save-as dialog if you haven't yet saved), and then inform you it's done).
- The window's modeless, so you can do other things to the map while it's open


Up Next:

- Text trigs text output
- Basic plugin framework
- The asterix that tells you when saving is done
- Graphics restructuring
- Locations or Sprites

---

Please let me know if you find anything not working or any of the above rules broken!

Post has been edited 5 time(s), last time on Oct 17 2013, 9:14 pm by jjf28.

Something that should have been in every text trigger syntax since the beginning. I've always wanted this.

I haven't been active on this forum for years, but I decided to pop by and see what's up for nostalgia's sake. I think it's incredibly cool that you're doing this. If you had to estimate, how close to "fully featured" would you say this project is?

Keep up the good work. Looking forward to seeing more updates.

If we pretend ISOM doesn't exist (because I have no idea how long that will take)

Done:

Terrain
Units
Most File IO
Most Operational Framework
Some View options
Most trigger framework

What's left

Things I probably forgot about
Locations (Builds on framework)
Fog (Builds on framework)
UI Options ("Editor Options")
Dimension Changer
Unit settings, upgrade settings, tech settings (long and boring)
Wav editor
Sprites (trivial with units completed)
Classic Triggers (trivial with text trigs completed)
Briefing (trivial with text trigs/Classic trigs completed)
Map Properties & Force Properties (trivial)
Strig edtior (trivial after text trigs)

I'd say i'm 'halfway' there, but not halfway time-wise as i'm a much better programmer now than when I started, halfway as if I started recently

Awesome! Thanks for the response Looking forward to see this project progress.

Update 10/21/13 - Download Latest

Small update, or is it large?

- Compiled statically so end users will get less DLL errors/don't have to worry about redistributables as much (adds 200kb, but that's well worth the convenience).
 

Post has been edited 1 time(s), last time on Oct 22 2013, 2:41 am by jjf28.