Jaesen has asked me to pass on the following reply.

"Please pass on my thanks and appreciation."

Salute to him!

Now I've been playing with JSGME lately to figure out some inconsistencies. And I've entered....the twilight zone. Of course we expect weirdness in a mod as large as Fall of the Rising Sun Ultimate, and we get it. One of our team members innocently suggested I try it on GFO, a small supermod.

So here was the procedure:

• delete everything out of my SH4GFO directory
• copy everything from my SH4Pristeen directory to SH4GFO to ensure I have all stock files
• write enable everything. Run MultiSH4 and Large Address Aware, then JSGME
• do a snapshot of game files
• install GFO mod only
• uninstall GFO mod
• compare files

I came up with all files matching original files. Cool! Let's do it again.

• install GFO
• uninstall GFO
• comare files

Either 7 or 9 different files! I'll post the video and you can see for yourself. That will have to be tomorrow. I'm living in the Twilight Zone! A program should execute exactly the same twice in a row, isn't that a reasonable expectation?

Please wait until I post the video just in case there's a stupid human trick in there that explains it, but if we find no error in the test procedure I'd like others to test and see what they get.
http://i196.photobucket.com/albums/a...psyp9czdjb.gif

Just to get the first video up as quickly as possible. Disclaimers: this is the first test with something other than FOTRSU. I used GFO because I understand it and it is the smallest of SH4 supermods. I surely have not eliminated all possible variables here: it's a first test. More will follow.

But what happens here is quite extraordinary. It's not a Windows problem because I don't run Windows. It could be a memory availability problem and I'll be eliminating that variable next. I'd say the likelihood is very low that it's a memory problem but until I eliminate that as a factor we have to consider the possibility.

It's pretty scary. The music (?) is too loud. Yada yada. But the results of this straightforward test are extraordinary. Here's what happens:

• I enter my SH4GFO installation, delete all game files and transfer a new copy from SH4Pristeen. These are now certified original game files
• I write enable everything after stupidly stabbing the cancel button by mistake and being unable to execute MultiSH4.
• I run MultiSH4 to make SH4 save settings and saved games in the \documents\GFO folder
• I run Large Address Aware to make \ubisoft\SH4GFO\sh4.exe use more than 2 GB of memory
• I start up JSGME and save a snapshot. Then I quickly do a compare of the files against the snapshot to show that says no changes......because.......we know no changes were made. That validates JSGME's save snapshot and compare snapshot functions
• I install GFO, then immediately uninstall it without passing GO or collecting $200 (or playing the game).
• I do another file compare. Tada!!!!! They're identical and JSGME has restored the original game Yay!
• Let's go for seconds: I install and uninstall GFO again, just as I did the first time, without passing GO.
• File comare results: 7 files different from stock. Go figure.

Please see if you can spot any errors in the test procedure. And I welcome suggestions on how this test could be altered or other tests made to help understand what happens here.

https://youtu.be/SbVl6SOdbJM

I've been wondering about maybe copying the JSGME files after the snapshot is taken of Stock, and moving them "off-site" out of the directory, so that the JSGME executable can't see the original copies, then do a file compare utility on the copy and the actual JSGME files after the 2nd round?... Does JSGME need to be LAA'd?... You follow? Do a compare of the compare yourself, if it's even possible.

What are the 7 files that are different?

If JSGME had been developed longer, a needed improvement would have been to allow you to go directly to the "changed" file (NEW; DIFFERENT; REMOVED) to see them in a list, without needing to scroll through the 20,000 plus files that Silent Hunter has.

Other than that tweak. JSGME is an excellent program that has improved our modding community as much as S3D has.

Thank you Jaesen!

You probably already know this, but you can "sort" the list by clicking on the column headings, such as "Detail" and get the list sorted together that way, which would bring "Changed" up top and all together. Click a 2nd time, and you get "Same" up top. You'll have to do a bit of scrolling to find the "Removed" sometimes, but they'll all be together...

JSGME still makes life a lot easier than it would be without it, and I think we're actually pushing it beyond were it was ever intended to go, and it still does a good job, just that there's a few things to look-out for and be aware of. I've done some "fake" mods, with text files with different naming conventions, and I cannot get it to fail. Of course, my experiments have only been with maybe 1k of data, not 3+gig... One thing I'd like to see is a copy-able list, where I can select filenames in the list, and copy them to the clipboard for use elsewhere. As an aside, here's 3 lines from a snapshot, and it looks like CRC is used to check the files against each other:

E:\Ubisoft\FotRS Ultimate\um.dll 8a984e947532dfd9bf3c2ae31e5af5a6
E:\Ubisoft\FotRS Ultimate\Utils.dll b9fd268e57834298c2e17809d0ee4997
E:\Ubisoft\FotRS Ultimate\zlib1.dll 80e41408f6d641dc1c0f5353a0cc8125

I wonder if that is what gets implicated in this?... who recognizes how big of a CRC is used here? 8-bit? 16?? It checks for flipped bits in the files for the compare. Comparing one bit in some big files is way less than comparing a human sneeze to their lifetime...

I also would also like to again thank Jaesen for his app, and the spirit with which it was made and distributed.

I show that in the video, clicking on the header and bringing the changes to the top.

That's right. This is not a gripe session or a JSGME sucks session. We're seriously asking this program to do things that are pretty extraordinary and seeking to understand why we're getting effects we see.

JSGME's snapshot and compare functions appear flawless, and they make any errors quickly correctable. This is the mose reassuring takeaway from experiments so far.

I'm going to try using Large Address Aware on JSGME itself and see if we're dealing with memory overflow problems.

Attention!!!

JSGME is not able to deal with large mods. However, I just ran Large Address Aware on JSGME.exe. I then installed and uninstalled GFO three four times in a row without any mismatches in the stock game files. If you are running a 32-bit operating system, anything GFO size or bigger will not work for you. If you are running a 64-bit operating system the fix is in!

Next, back to FOTRSU--3.6 GB of monstrous gobbeldygook--a tad more than 10,000 files.

Are you tired of testing RR? excellent news though...

Tomorrow I run FOTRS Ultimate through the Large Address Aware JSGME Gauntlet of DEATH. Several times. I won't be making a video of that one.....:D
:D:D

The seven files are in the video where I show how to sort the files by result and bring the anomalies to the top of the list.

Awww ma-annn.... You know what'll happen if you ~don't~ video it? Something really ~strange~... If you tape it, it'll go smooth. :D

Murphy?.............
 

Murphy............Murphy?...............is Murphy's Law here?.........

Be interesting if the 7 anomalies of GFO are the same line anomalies listed in FOTRS ULTIMATE are a link to the SH 4 pristeen copy. Maybe like you said adding JSGME after large address aware will correct this issue.

GOOD LUCK with the mad scientist computing!!:Kaleun_Cheers:

There IS an answer out we have yet to stumble over, fall, trip, upon it!!

Fith

That was the interesting part. They were NOT the same. They were entirely different files. In FOTRSU it was ConteVerde and German flags. But GFO doesn't change any of that stuff. So those files were unaffected. In order for a file to be affected, JSGME has to replace that particular file with a mod file. Then JSGME must forget to change it back on the uninstall.

So in that respect it wasn't a fair test. I just wanted to find out if there was a lower limit to the size of a mod JSGME would have trouble with. And GFO wasn't small enough to find that limit. I was surprised by that.

Nobody tested more than Webster. He is the only supermodder ever to make an RSRDC mitigation patch to avoid being squashed like a cockroach when it was installed on top of GFO. I would have expected that he would encounter the problem. But if you weren't doing a compare and were just looking at game effects, with GFO the effects would be subtle. After all GFO is designed for an essentially unchanged game experience from stock. Anybody who thinks the stock game is crap needs to play GFO and find out how good it really is. GFO is a blast!

You have to remember than in 2010, when the golden era of SH4 modding died, 64-bit computers and operating systems existed, but nobody used them. 64-bit Windows didn't have drivers for enough hardware and if you were to be bold enough to use it you'd find your printer, monitor, keyboard, mouse, touchpad or any combination of those wouldn't be working. So everybody pretty much stuck with 32-bit Windows.

Are you telling us that you've tried the 32 bit LAA setup and it doesn't help. Or, are you just guessing?

You do realize that there's an additional "Switch" to throw for a 32 bit OS before LAA works??

You aren't making your procedures clear with your "test" results, if you've tested it at all.

32-bit Windows can directly address only 3.2 GB of memory, period. Yes, you can make it seem like more by bank switching, but there's a lot of overhead to a bank switching scheme. The Large Address Aware module was specifically made for 64-bit Windows.

So maybe Large Address Aware could have minimal benefit for a 32-bit machine. Probably not, since it was designed for a 64-bit OS. In a week I'll have a 32-bit virtual machine to test it on, but there's a lot of time in setting that up, a disk drive to buy and install--just doesn't fit my priorities right now.

The question I'm asking later today is "Will Large Address Aware fix our Conte Verde and German Flags problems on my 64-bit machine? We'll address later the questions of whether FOTRSU is appropriate for a 32-bit OS and machine.

From my old days (pre-Win2k), if you had 4 gig of ram on your 32-bit OS machine, you could use one of those utilities, but you also had to change settings in the Boot.ini file for Win-2k or XP. You use BCDEdit in Vista, Win7 & 8. Thirty-two bit versions - not 64. I haven't a clue about 10... Both the program ~AND~ the OS have to be "aware", and still, some apps just don't like it and will crash.

Anyway, about the most concise site for that still is the AutoDesk Knowledgebase. I used to use that for video editing back when... Doing that on a machine with 2gig of RAM would be an exercise in futility and crash recovery.

I think you guys are barking up the wrong tree in thinking huge files make the reason why JSGME causes corruption in changing stock game files. Which moots the idea of testing JSGME with LAA and seeing if it does any better. I think you'll be wasting your time. It's nothing more than modders not following good modding techniques.

I just ran a little test. A 64Kb, JSGME compatible modification that only has two folders changed containing 6 total files. I copied the two FOTRS TLowRes/tex/German.dds-remove and German_m.dds-remove to my mod. I also copied from FOTRS..... TNormal/tex/German.dds-remove and German_m.dds-remove along with the new images it uses of the German flags (they contain the German Swastika)....German.dds and German_m.dds

I compared my present game files through JSGME "Compare Snapshot" to my original game files, all was in order. I ran the game with the test mod only. I viewed the newly changed German flags in the games Museum for the German ships, then exited the game. I deactivated the test mod, then ran the Compare feature again. The results were two files REMOVED. Yep, the two TNormal/tex/German.dds and its partner the German_m.dds were removed from the stock game.

I've had stools bigger than a 64Kb file!! Yet, this stock game corruption occurs with a very small file size.

But here's the interesting thing.....The two TLowRes/tex/German.dds files were intact and back where they belong after the "-remove" modification was used on them! What's the difference???

The difference is the FOTRS modder used replacement images in his mod of the same name that he also used the "-remove" flag for. There are no replacement images in the TLowRes/tex folder....there are in the TNormal/tex folder.

In this case, the modder simply needed to replace the original images with the Swastika images, using the same naming scheme as the stock game, and leave out the "-remove" files from the same folder. JSGME doesn't know what your trying to do if one pair of files make changes to the original, yet another pair ask for you to remove them?!?

Modder error, nothing more.

I'm finding the exact same thing. However, without LAA being applied to JSGME.exe, loading and unloading GFO always results in errors eventually. With LAA applied, GFO loads and unloads properly every time. So even GFO is over the threshold of how much memory unassisted JSGME can handle. Applying Large Address Aware fixes it.

Round 2 LAA plus JSGME vs Killer FOTRS Ultimate in a death match. Verify stock, then install and uininstall FOTRSU. The same seven files are changed. Inspection reveals that all 7 files use the -remove feature.

As you say, on the German flags the feature is used improperly as substitute files would take the place of the originals anyway. In the ConteVerde, that is not the case. So I removed all the -remove files for the seven files. Instantly, LAA plus JSGME installed and uninstalled all 3.6 GB of FOTRS Ultimate correctly every time. 4 times done, 4 times correct.

So we can explain away the German flags issue. That's just a stupid modder trick. But the ConteVerde stuff isn't so easily explained. I'll just leave the stock stuff untouched there, but changing in a new radar silhouette to get the position marker. All will be right in Denmark, even though absolute full understanding isn't achieved.

And yes, large size rendered JSGME unreliable for restoration of GFO. LAA fixed that instance. It had no effect at all in the reliability of FOTRSU. It isn't a DOS or Windows error. I don't use DOS or Windows. So something isn't quite right in the -remove handling of JSGME and we don't care what it is. We'll work around it.

That's good to know...and to try LAA with the JSGME.exe to see how it works.

I know the creator of LAA, FordGT90Concept, is still on his Large Address Aware thread from time to time. He just added his newest LAA for Net Framework 4.5 (Windows 10 enabled) back in July. Between him or one of the other tech savvy experts on the TechPowerUP forum should be able to answer any questions we may have.