C&C95 Rules.ini

[peterthepigeon]

So now that my account is back and recovered.  I'm starting a project to allow you to edit unit values as you would in RA, TS, etc.  I may make a repo for the project, I haven't decided yet.  Right now I'm just in the planning phase of the project, doing some UML, etc.

The actual project will be coded in C++, and make use of regex, along with std::map and std::vector.  For a project of this complexity, a parser is not required.  Boost may be used, although maybe not as the STL provides everything I need.  I plan to have a worker thread running every so often to query changes to the file and spit out any inconsistencies.  In other words, you'll be able to alt tab out of the game to edit values on the fly and if it causes potential inconsistencies, they'll be discarded and the file overwritten with the last stable changes.

It would be tempting to hardcode offsets and the like into the .dll itself, however, for ease of modification, simplicity sake and ease of development, I think I will simply keep it to .ini files.  I plan to add a detours.ini, or something where you specify an offset, a detour type, or a modification in assembly and whether you allocate to a new RWX section or overwrite the opcodes in the .text section.  I could use the heap for this, and then call VirtualProtect to mark the page RWX, however, I am not in 'love' with the idea, nor just willy nilly throwing out 4096 byte allocations.  A memory manager seems most appropriate.

This thread will be updated as I work on the project.

[Messiah]

Editing unit stats already can be done in TibEd, what will be the difference in your project?

Edited July 24, 2017 by Messiah

[Blade]

This sounds vaguely like a DLL injection project, similar to what ares (YR) or thyme(Zero Hour, my own project) do to inject their own code. It sounds over the top with its modifications though, allocating heap for custom code? Just reimplement functions you care about in C++ and then set jumps in the original code to go to them. Compile the whole thing with open watcom and you won't even need to write shim inline assembly to account for different calling conventions either. I've recently been experimenting with injecting a dll into RA, so I know this can work and indeed does work very well.