SUBSIM Radio Room Forums - New JSGME update coming

SUBSIM Radio Room Forums (https://www.subsim.com/radioroom/index.php)

- SH4 Mods Workshop (https://www.subsim.com/radioroom/forumdisplay.php?f=219)

- - New JSGME update coming - feedback sought (https://www.subsim.com/radioroom/showthread.php?t=123176)

BTW, thanks again for continued support on this important tool for open modding.

<S>

tater

Jaesen I have used JSGME in Sega's Football Manager 2007 as well without any problems. Most probably it will be fine for Football Manager 2008 (it's out in a couple of days), but as soon as I know I will let you know.

Hey a q for those using non-English language OS. When you create a new folder in Windows Explorer, what is the default? Is it "New Folder", or is it something in your language? If it's the latter I don't really need to know what the text is, just that it's *not* the English "New Folder".

Yes, the 'New Folder' default name is localized in all Windows OS's.

Quote:

Originally Posted by skwasjer

Yes, the 'New Folder' default name is localized in all Windows OS's.

Thanks. :up:

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 ;)

Forgive me for quickly scanning the new posts, as I'm on the run....

I see it was touched on above, but just want to add/reconfirm;

If we could combine the text comparing feature of Jimimadrid's tool with JSGME, that would be ideal.

A one stop step of enabling a mod, and having only the required lines of text in an .ini file be altered, that would be the perfect thing for everyone here.

Sorry if this is addressed above, I'm racing off to work.

Later.

Quote:

Originally Posted by skwasjer

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?

Yes, that's pretty much it. The modder provides the offset, size and data and SH3Cmdr just inserts it.

Quote:

Originally Posted by skwasjer

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?

I was thinking that in addition to their modded files, modders would include a text file stipulating any merging required. The format SH3Cmdr uses, which most likely JSGME will too, is:

Code:

...

[data\Cfg\SomeTextFile.cfg]

SECTION1|Key=Data

SECTION2|Key=Data

SECTION3|Key=Data

 

[data\Cfg\SomeDataFile.dat]

OFFSET1|Data size=Data

OFFSET2|Data size=Data

OFFSET3|Data size=Data

...

Binary, text, doesn't matter, it can all go into the one merge file; JSGME will be smart enough to tell the difference between binary and text file merging.

So, after JSGME copies across any included modded files as it does now, it would then merge the contents of this file into each respective game file, backing up the specific data that it replaced (or added/deleted). The backup log would be in the same format as the source merge file, but with, obviously, the replaced data. To maintain content integrity the merged files would be added to the dependancy list that JSGME maintains with the full files that the mod replaced earlier on. So no chance of any "unmerging" out of sequence.

Quote:

Originally Posted by skwasjer

[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.

Yeah. There'll always be exceptions. Even with SH3Cmdr GWX users must use a different set of files to stock users to NYGM users because of differing offsets. But some of this will have to come back to the modders: "Make sure you've enabled mod X before my mod". It would be impossible for any application to know if a merge will crash a game; it has to come back to manual intervention at some time. With this in mind I'm not sure that rebasing the offset (and possibly size) would be worthwhile; it may just cause more problems.

The likelihood of unbalanced mods is what's put me off this for so long - I'd hate JSGME getting the blame because, using my example above, a mod that changed two parts of menu.ini "broke" an earlier enabled mod that changed six parts. But I guess it's really no different to now when a subsequent mod screws up an earlier mod...

Quote:

Originally Posted by skwasjer

This was just a quick thought... There are probably things I overlook at this point, but it's the idea that counts ;)

Keep them coming. If you have a better way of inserting binary data, I'm all ears. My intention though it to keep it as generic, dynamic and as easy to use as possible.

I see, interesting.

I understand the problems involved with merging both text/binary data. It's why I said in other threads, it will prove pretty much impossible. Not so much technically, but there's no guarantee everything works as expected. This is also true using current JSGME, but the problems are less likely and at least more transparent to both end-user as well as modder as to what's the cause.

Quote:

Imo, I think rebasing can be worthwile, as long as JSGME is used right from the get go (aside from any supermod custom installations, or shall we say the base install). Data can then be inserted/removed as well without a file going at least corrupt (as far as file structure is concerned).

The big problem that remains is again whether specific mod changes are compatible with previous installed mods... You - the author - can never know. This will always be up to the modder. Come to think, how about a 'dependency list' for modders to include, lol :rotfl: Sorry I get carried away to easily :)

Anyway, I trust your instincts, like you said it's not the first time you've thought about this. I only thought of this 'on the side' of other work...

Quote:

Keep them coming. If you have a better way of inserting binary data, I'm all ears. My intention though it to keep it as generic, dynamic and as easy to use as possible.

Keep that thought. It is the real power behind your app, simple, effective.

I feel in someway though that creating such binary/text cfg's for JSGME, could become at least somewhat easier for the modders if S3D can generate the 'binary' part!

Firstly thanks for developing this really useful mod tool. I really doubt I would have used mods extensively without JSGME.
Probably too late for this version, but a bell or chime when the enabler is finished would be good for those big mods and sound/radio mods that take several minutes to complete. "Ting, you are now free to move about your modded submarine!" :rotfl:

Quote:

Originally Posted by ironkross

No, it's not too late. ;)

I want to release v2.0 in the next week or so. I've had some guys using it for the last week and feedback has been positive.

However, as this new version contains a totally revamped engine, I'd like to broaden the testing conditions a wee bit.

So, if you want to test the latest (as in try to break it and let me know the result, not just take it and use it without giving feedback), pls PM me. I'm particularly keen for some Vista users, and even some Win98/2000 users (OK, perhaps not likely here, but who knows, one of you may have a few machines). Experienced users and novice users are both welcomed. Doesn't matter what game you test it with either.

Could you implement the soon to be released SH4 Commander into the JSGME :D

Well i tried! :lol:

I so miss Commander for SH4 :cry:

Quote:

Originally Posted by skwasjer

I feel in someway though that creating such binary/text cfg's for JSGME, could become at least somewhat easier for the modders if S3D can generate the 'binary' part!

Absolutely! Anyway, after I release v2.0 I'll turn all my JSGME development attention to the merge component inclusion. So feel free to throw any thoughts or ideas this way. ;) Same goes for anyone else - JSGME is pretty much what it is because of user feedback.

BTW skwasjer: kiwi's post reminded me - I gave the merge code I use in SH3Cmdr to Potoroo to use in SH4 Patrol. I dunno if he is running with it (let alone even working on SH4 Patrol any more), but if so it'll mean you could write one export function to suit both products.

I need a few Vista users to test something for me...

It appears that Vista's UAC gets in the way of certain new JSGME features (surprised?). One is the simple playing of the system sound when a mod has been enabled or disabled :sigh:

If you use Vista, can you pls d/l the quick test file at http://www.users.on.net/~jscones/Project1.exe and perform a few simple tests:

1. press button 1, you should hear a sound. Press button 2, you should hear a sound. Note the results.

2. run the file as administrator (the usual right-click then "Run as administrator" process) and repeat the test.

Pls post your results here for each test.

You don't need to be a JSGME user, just a Vista user. ;)

XP users need not test.