Download Latest

Project on GitHub: https://github.com/TheNitesWhoSay/Chkdraft/

-- Original OP --

I thought it might be a fun project to attempt recreating SCMDraft.

As a start most of SCMDraft's features will be recreated as-is (with the exception of the true ISOM formula), avoiding a few select pitfalls and annoyances (seriously, no hover-text for the buttons?!). After which new and glorious myriad of features can be added.

I feel it's critical to make a similar GUI, the mapping community is smaller and ought to be set-in to SCMDraft way of doing things. That said, there will also be more advanced windows (i'm thinking spreadsheet style) where you can copy-paste and otherwise code units, map/unit/tech settings, sprites, and of course, triggers.

I'm doing this for fun and to get a better understanding of GUI programming, source code will be released once it's legible.


As of 10/8/12
- The main GUI has been hammered out and standardized
- The program can load up chk, scm, and scx files
- The program can save chk, scm, and scx files
- A temporary text editor has been setup in which you can edit the chk data, backslash used as escape character, any character following a backslash is -48 ASCII values (ex: \0 = NUL character)
(the text editor is shoddy with a long load time, it's just used to illustrate the loading/editing of files)


Now that scenario file can be loaded into a buffer and outputted to the desired file, it should be quite easy - though time costly - to setup user-friendly ways to edit map data.

The next big hurdle will be to work out programmatically loading terrain and unit images from the starcraft MPQs.


(The first number on the status bar tells you how long it took to get the file into the buffer, the second number is how long it took to put in escape notation and print to the screen)

Post has been edited 4 time(s), last time on Oct 25 2020, 4:50 am by jjf28.

Ambitious. Good luck!

I'd test it... I seem to be good at breaking things

If you need help with deciphering or using terrain, graphics, data files, or basically anything, you can always ask me. If I've been successful, I shouldn't have to say that I have plenty of experience playing with these things...

Not sure if possible but you should try and get more people on this project. Crowdsource this thing SEN 2012!!!

Not sure how ambitious you are thinking but you could try and get Oreos built in, then going the next step you could create custom triggers that makes EUD use easier, etc.
Also take off the limit on unit names so you can more easily do overlaps.
Getting way hardcore now but you could make extended isometric terrain tool.

The project feels redundant at this point and I would prefer to see new plug-ins developed for SCMD2. (SCMD2 uses plugins, Moose? Yes, TrigEdit is a plugin.) If you're lucky, you can catch SI and he can tell you how to integrate them into SCMD2. The reason I say this is because you specifically said "recreate SCMDraft". The spreadsheet style/"more advanced" thing for editing units, settings, etc, would be much appreciated and give mappers some much needed automation, but I could see that as a very nice plugin to SCMD2, too. This would also save you a ton of time (and get it into mapper's hands faster) because you'd have to code a plugin instaed of a full map editor. Then again, you said you're doing it for fun and experience, so that's your choice.

Yea yea yea do what Moose said.

Actually something everyone would really want is trigger comments that don't take up strings.

Oh and a plugin that bypasses the string limit, that would be nice.

That's a limitation of Starcraft, not just SCMDraft.

There's seems to be no documentation available for creating SCMDraft plugins, so I don't consider that a particularly viable route... the only example plugin I found link too was on the old beta site which cannot successfully create new accounts AFAIK

Comments without strings would no longer be the comment action created by blizzard, but it would be easily doable (though not readable by SCMDraft / other mapping programs). I'll put color support to the comments as well when it gets to that point


If you could point me in the right direction (perhaps with a library or some code) for loading graphics from a .grp programmatically that'd be great i'm presently programming in c++ using SFMPQ to open archives.

I thought things like TrigEdit were originally plugins but that got scrapped, so now they just appear as plugins ...

This could be possible, but the strings would only be usable in the specific editor ... Also it wouldn't need to use a special comment, you would just need some way of indicating which outside comment it is supposed to point to (like use a different location in the action structure for the string ID. StarCraft would ignore it.)

I probably have some code laying around ... I've used ShadowFlare's grpapi in the past.

this might be a good place to start if you want a custom routine. (More helpful formats).

EDIT:
I found a GRP function of mine in PHP. If you would like I can summarize it and PM it to you.

Post has been edited 1 time(s), last time on Oct 9 2012, 7:46 pm by FaRTy1billion.

Thanks! I'll get looking into grpapi.

Source should be postable ~tomorrow

The only thing with GRPAPI is you'll want to specify your own "SetPixelProc" function (SetFunctionSetPixel) so you can do the color remapping that SC does (for transparency, shadows, fire, or even player colors).

So... I went ahead and rebuilt my entire program to get rid of all the crap and use generally better coding practices.

Incredible frustration resulted when I tried to setup the familiar listview as blizzard had absolutely no organization system when it comes to UnitID's simple for-loops were out of the question, couple that with the fact that C++ disallows assignment statements for multiple array values at once and you get, well...



That fun aside,
- the menu is complete with all the callbacks setup for every item to give a little info about themselves
- all toolbar items are linked to the corresponding menu item callbacks
- the main tree is set-up and loads default units, when a unit is selected the corresponding UnitID prints out

Wanted to add back in my open/save functions and some preliminary image loading functions before updating, but also wanted to update tonight so, here's for now:

So you're trying to group the units into categories and then display them alphabetically in each category? A better way to do this than what you've currently got is some sort of simple list structure, like this:
Zerg_Ground_List.add (UnitDisplayName[91]);
Zerg_Ground_List.add (UnitDisplayname[92]);
....

Then sort your list. More flexible than doing x = y with arrays like you are, and less code.

Also I think however the units are stored by the game, they must have additional flags like ground/air unit, structure, what race they belong to etc. So you could loop through the array of units, when you find one with Ground + Zerg flags, add it to the Zerg_Ground_List, etc.

This solution would be more flexible for working on modded maps (does Scmdraft handle mods?). Or, you could work out all of the IDs in the correct order and just hardcode them in an array:
Zerg_Ground_Array[] = {94, 92, 63, ...};
Then have another piece of code that loops through this hard-coded array and populates another one:
Zerg_Ground_List[i] = UnitDisplayName[Zerg_Ground_Array[i]];

Post has been edited 1 time(s), last time on Oct 11 2012, 10:39 am by Lanthanide.

This is how staredit does it. The flags are in units.dat. If you've ever noticed, in StarEdit the units are all sorted by unit ID. (StarEditAvailabilityFlags)

Also I just noticed this unit.dat listing isn't that helpful since it doesn't really say how to use any of the values .. When I get home later I can try to find a better one (I've seen one somewhere ... I used it for TinyMap.)

Would look nicer, but the code would be less efficient (has at least more than the current amount of operations), I find it hard to make myself do stuff like that.


Coolio, that could replace some of the yuckiness! Regardless, this is just the tree that's going to be hardcoded into the editor, i'll probably be setting up different methods for populating custom/user-defined tree's.

You have much to learn when it comes to software engineering . This was also mainly meant as a starting point to spur your thoughts on better ways to do the code than what you have. Certainly X = Y like you have right now is very tedious if you want to change it or make a mistake.

In large projects, it is often better to go with simpler code even if it's slightly less efficient. Often, the compiler will create the same result anyway.

Also see this: http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize

I should probably give a little news at this point:

Apart from that time suck known as college, I'm working hard on the multi-windowed interface and attempting to work out some kinks with resizing and so forth, lotta nitty gritty, GUI stuff that has to get done (this content is all new to me & learning it is part of the project!)

I'm finding this particular aspect of programming relatively boring, and I think it'd be equally boring to hear about it

---

So apart from GUIs:

I've thoroughly sketched methods for adding, removing, and swapping sections of data in the scenario file buffer

I've worked logic for setting a unit's index (both moving to and fixing to - at least for the duration of the editing session)

I've also been giving a lot of thought to specific considerations that I want to program in "the first time" - such as:
- Correctly considering unit sprites and start locations when calculating indexes
- Being able to manipulate the order/index of locations, sprites, strings, and so forth (as a perfectionist it haunts me to see location "track" between "x256" and "x512")
- Setting spriteIDs (a-doy)
- Being able to view mathematically significant data such as the units dimensions, unit range, whether a unit is initially in a location, etc.
- Having the option to perform some final map cleanup - remove things like unread CHK sections, comments, never triggers
- Ability to insert sound files directly into the MPQ - saves on space

Once I finish with the front-page GUI (no idea how much time this will take) i'll be concerning myself with reading some of the most critical data into the editor from map files (units & terrain) into workable forms and subsequently getting their matching images/animations - hopefully at ease via the dat files; though a cursory look suggests non-expansion terrain is something of a puzzle!

Set yourself the goal of replicating StarEdit before you get too immersed in all those extra little features. It's easy to get bogged down, get bored and give up, before you've achieved anything usable.

This seems like this is an excellent way to practice your skills. I can't speak much from a programming perspective, but as a mapper, having a recreation of SCMDraft2 that could actually be updated and expanded upon would be absolutely incredible. A lot of the things that are currently painful or impossible to do in SCMD2 could actually be given proper implementation.

All in all, I'd say this is an admirable task you've set yourself to. Best of luck.