Quote:
|
Originally Posted by JScones
Anyway, as you may know, SH3Cmdr has been doing file mergings for quite a while, so my revelation a few weeks ago (from when it was last mentioned) was to lift and shift the function across to JSGME (it's a self contained function, no changes necessary) after I rewrote JSGME's engine (which I've now done and testing has been nothing but positive). That means that nearly every SH3 and SH4 file would be "merge capable" (binary and text), I'd just then need to expand it to include XML files and the like (to keep the "Generic" in the name  ).
Basically, if you're familiar with SH3Cmdr's Static/Randomised Settings feature, you've got a good idea about how it would work.
The big challenge is making it user friendly and presenting it in a way that doesn't turn off players that just want to "install and run". And in doing so balancing it with accuracy. I mean, changing the deck gun rate would be sweet, but if mod A changes six elements of stock SH4's menu.ini file and mod B changes two elements of the same file, is there a guarantee that all will be sweet? Ultimately, there would still need to be some manual intervention if things go wrong and I don't want to give users heart attacks by showing them menu.ini file contents! |
I have no idea how SH3Cmdr works, because I don't use it, but do you just insert/replace plain binary data at a specific offset?
I have been discussing some stuff in the past where S3D logs all changes made to a file so it could possibly be used by other software (read JSGME) to dynamicly rebuild files based on such logs. It would require the exact same source files for this to work but this is pretty much what JSGME guarantees (as long as a user uses it correctly that is). This way, modders can work on any file they wish and they then wouldn't distribute the 'dat/sim' etc file but only the log for use with such a tool... S3D currently already supports full undo/redo functionality so it would take some thinking on how to safely store this in a workable format for such a solution (which could basically be as simple as, offset,size,data). Interesting, or do you have some other solution down the pipeline?
[edit] obviously, this won't solve conflicts where two mods change things and the result is something unbalanced, and it probably won't work either if inserted data is not of exact same size (iow replacement), unless you keep track of insertions/removals too and accordingly rebase the offset.
This was just a quick thought... There are probably things I overlook at this point, but it's the idea that counts