Other developers are always welcome to take a fork (or request access to make feature branches) and raise a pull request to development; I tend to process these in under a week, so far others have only committed some small things https://github.com/jjf28/Chkdraft/graphs/contributors , except Fary who decompiled a ton of graphics https://github.com/jjf28/Chkdraft/tree/graphics-beta (though I didn't think it stable, so I haven't merged it yet).

On the knowledge side of things, SI, Fary, and Heinermann have helped a ton when I've needed it (though SI still owes me some ISOM code ).

I should note that it would complicate things if someone were to work a ton of features while I'm completely changing the base code around https://github.com/jjf28/Chkdraft/tree/feature/fundamental-refactoring , but if anyone's particularly eager to contribute I'll make it a priority to have that stable by this weekend.

I'm just weighing the options right now but I'm glad to know you're open to it. If you can post when you're done with that fundamental refactoring, I'd be much obliged.

Mostly a note to self: not going to support preserving jump section information between saves (this violates my change-nothing-not-touched policy, and every exception needs some justification) - jump sections are a section with a negative size such that they jump backwards in the chk file to a section header embedded within some other section. Jump sections can be used both for compression and for protection - protection in that they're harder to write a parser for, so programs are more likely to fail against them; and if you build large enough compressed section data you could crash most editors/run them out of memory.

If a chk file contained jump sections that increased the scenario file size - it should be considered protected.

If a chk file contained jump sections that decreased the scenario file size - it should be considered compressed, if changed, original jump sections should be discarded, and upon saving (or upon releasing, if there's a substantial runtime impact to doing compression operations on every save) jump section compression should be reattempted. Compression is much less important in remastered since blizzard has greatly improved download times, so losing this info entirely may be acceptable.

Jump sections present numerous challenges trying to preserve - having to setup alarms on every data change potentially affecting the header, the data inbetween, or the size between (including changing one sections size, or adding or deleting sections), and because we're talking raw data monitoring it would serve as a great complication to any object-based abstraction - requiring something like holding the raw data form and object form and keeping them in sync at all times, or rapidly generating the raw data form (and risking out-of-memory errors for otherwise low-impact operations), notifying the exact changes to the jump section for handling, and in the handler recalculating the position of the jump sections (which may not always meet user expectations, as they might not want a jump section header in a action in something like a trigger they just copied).

Because there's no actual point to jump sections except compression, the compression can be recalculated at save time, and preserving the information would mean tons of work, overhead/resources, and imperfect user-experiences, maps with jump section compression will lose it (have the sections recompiled into one chunk) and potentially have it recalculated during save.

There might not be much attention around, but hey! I've just learned something new and beautiful at technical part of things! Thank you for sharing that bit! Any updates coming soon?

Not sure if this is done, but if you could abstract the CHK parsing code from the GUI into its own library, e.g. think a CHK to JSON and JSON to CHK, that would be infinitely helpful. Ideally written in Python...

CHK to Json is one of the things I want to do, but that's not in my short term plans (think 6 months from now). A library in python is not something I'd be personally interested in unless python became super relevant career wise - you'd have to use a LIB or DLL or other inter-language feature of python to interface with libraries from Chkdraft, or write your own port.

You can also write a C++ pymodule that compiles natively for python. But speaking from experience that is a pain

It's not clear how to use any of the Chkdraft code to do what I want--interpret triggers from TrigEdit or similar style to the TRG binary format and back. If you had an example that would help. For example even StormLib had examples in C++ and I could reuse this in Python by using the DLL as you mentioned, which is how I wrapped it into my Python MPQ library.

I'm curious why Python is not relevant to your career? In fact I'd think the opposite about C++/C. Everyone uses Python or Java in my circles and even Java is considered cumbersome, let alone C++! It's the defacto scripting language and has one of the lowest barrier to entry, along with an easy way to learn AI/machine learning/data science. I have been coding for almost 10 years and work full time as a SE but I wouldn't touch C++ with a 100 foot poll. I guess you work on hardcore game development, embedded systems, or optimization?

I'm not sure why the community is resistant to this idea. I mean if I did any real modding project, the first thing I'd do is write a library or module that does one thing good and one thing only which would be to read CHK to and from a human readable and friendly format like JSON. I'd build all my projects on top of that dependency. And then anyone else in the community can use it, so we don't end up fragmented and write 12 different parsers for CHK format.

Parsing the format seems tedious, but it's not innovative nor where any new projects should spend their time. Progress is hard to make when we can't re-use existing work.

This includes you too, Suicidal Insanity. Could you release whatever code interprets TrigEdit into the TRG format at least? I am about to write my own interpreter and would rather avoid repeating that work.

Unfortunately most tool devs have a strong aversion to releasing their source. pq and jj are anomolies compared to the insane number of devs who have chewed me out for even asking. It seems foolish but most of them don't want their code looked at, in my experience.

C++ is also used for bw plugins fyi, you will need to get a 101 foot pole or write an alternative library if you want to get involved with those. There is a lesser known library in rust but it's not very fleshed out yet iirc.

As a project yet to complete the basic features I don't regularly package libraries, but I'll get a DLL for you here and some example code in the near future.


I write backend stuff, maybe that'll be python someday but at present I don't need it, it hasn't shown up big on job requirements nor in my job training (it has shown up a little, which is why I know a little python, but not enough to justify spending weeks or months on it).


Not at all resistant to the idea, there's a reason Chkdraft is open source and a reason I carefully isolated all of the mapping code (and am even redoubling isolation efforts in my current refactor) - cause that part of my project is intended as reusable CHK handling code, with serializations to JSON and binary and all that jazz. That said Chkdraft isn't intended to do that one thing and that one thing only, there are several goals, and I chase down whatever I most need or most fancy at the time

Post has been edited 1 time(s), last time on Mar 12 2019, 9:47 pm by jjf28.

I just maintain the text trigger code, I'm not the original author of that plugin.

Understood and now it makes sense from your point of view. If I did work with C++ I could probably reuse your work (but I may still reference it) but I need everything in Python.

I went ahead and started my own implementation of the CHK format into JSON/Python objects called chkjson. It is rudimentary right now, but if you look at the organization and type annotations, you can get an idea for the standards I expect from a library that would parse CHK. I only do STR section now (and it's far from complete) but also intend to add tests for the compile/decompile and every other function, like adding a new string to the STR section. I don't plan on adding every section (but community members could make pull requests once I finish the code for the sections I care about, like TRG and MRGN.

See: https://github.com/sethmachine/chkjson

Update 2020-05-09 - Tentative Release Attached (not yet remastered compatible, still 1.16.1, so not updating the main file yet)

Chkdraft is now on the other end of the large refactor, the development and master branches have been updated on the Chkdraft Github, if anyone wants to contribute you can fork from development and raise a pull request to development when finished.



Feature Changes:

- Now using a new extended string scheme, most string users (e.g. locations, switches) you can now specify an "editor string" (which is stored in the map file and doesn't take up any game string space) in addition to a game string (which starcraft/staredit/scmdraft will recognize), currently the properties button on location name and switches allows you to do so, and the general tab of triggers will automatically use editor strings for comments (comments show up in the trigger list) and notes (notes don't show up in the trigger list, they're for more in-depth detail about the trigger that you can see when you open it)
- Automatically upgrades maps using Chkdraft's old extended string format
- Improved experience for loading StarCraft's resources (only need to find the executable, individual MPQs are auto-located)
- Logger on the GUI providing more details about what's going on/what errors might be occuring


Code Changes (Broad):

- Remove SFmpq, SComp, and all evidence of submodules
- Add StormLib for MPQ handling, IcuLib for unicode, GoogleTest for unit testing
- Separate the Chkdraft solution into several projects for faster builds, separation of library code, and to enable unit tests
- Convert project from 8-bit ASCII to unicode (UTF8 everywhere except in GUI code/system code where UTF16 is required)
- Heavily refactor mapping core, removing all buffers, emphasizing self-documenting code and focus on building quality APIs for editing scenarios, accessing StarCraft resources, etc.
- Add a logger (similar to log4j) to the code, which goes to a logger window in the GUI and a logfile
- Upgrade to VS2019
- Upgrade to C++17
- Upgrade to 64-bit builds (32-bit build optional)
- New extended string format, extended trigger format

Post has been edited 1 time(s), last time on Aug 10 2020, 1:16 am by jjf28.

Does this only work with an older version of Starcraft or something? I can't seem to even find Stardat or Broodat etc. in the new Starcraft's folders.

That's because they've all been axed in 1.23.0 together with Staredit (turns out they've only been used by StarEdit since 1.18 while most of the actual data in in CASC files anyway). However, there have been "clean" installs of 1.16 floating around where you can get the files.

Correct, at present remastered data files are not supported, you need the StarDat.mpq, BrooDat.mpq, and patch_rt.mpq files from 1.16.1 (or similar versions).

Help me jjwan kenobi, you're my only hope.


I've had some great success with your trig editor. Where SCMDraft has failed to compile you have succeeded, but I am having trouble understanding how to proceed with my endeavour to translate my RPG into Korean.

So here's some screenshots coz I don't trust copy/paste these days...



The top line is the korean text, and the bottom is how that text displays in your trig-editor. Problem is, I need to input a lot of korean text into your editor and then compile it, so how exactly do I go about doing that??

I'm thinking I have to lay it all out in classic trigedit, then open it up in trigedit to get the "machine-code" version, then find and replace that throughout my triggers. Is that the best way?

Many thanks,
Oh_Man.

Could you attach that text file with that small example of korean text?

Don't worry dude. I actually just plugged the korean text straight in and ran it and it compiled! When I reopened your trig editor it had automatically changed it into that machine code! Very impressive!!!

My only concern now is you said CHKDraft doesn't use SCR, does that mean it can't take advantage of the new extended string limit? I can't even tell how many strings I've got left because in string editor it says "TODO" so I guess you haven't coded that part yet.

Neat, I haven't done much testing on the unicode portion but it looks like it's writing correctly (I did my own little test); though reading & displaying could use a little more work (at a glance this is only an issue due to automatic escaping of character values > 128, which was nice when this was English only but now holding back language support).


Yeah I haven't gotten around to SC:R things including the extended string limit and new terrain tiles yet, so you can't use/take advantage of those sorts of things in Chkdraft.

Additionally if you have a map already using SC:R features it would be unwise to resave it in Chkdraft (a backup created using plain file copy before your first save can be found in the chkd folder though) as Chkdraft will automatically change the version information to at most the Broodwar version.


I'll get you a version with a primitive statistic there maybe tomorrow, that should have been there already.