PLJ's stubborn attempt to track CTD's

[Bathrone]

Its a red herring. That just usual windows behaviour with the file system and the latency/bandwidth limitations of moving the files around

If you wanted to get all scientific, you could run a checksum hashing algorithm over the unmoved mods files and then move it with a profile, see the not responding due to latency/bandwidth, then once the mod enabler has all moved the files, re run the hashing algorithm over the same files just moved and you *WILL* see that the hash values are identical

This is not the problem folks

[Mikemike47]

Originally Posted by Bathrone

you could run a checksum hashing algorithm over the unmoved mods files and then move it with a profile

Just curious. Running JSGME, tasks, generate snaphot of game files produces files with a whole bunch of numbers/letters afterwards. Is the whole bunch of numbers/letters considered a checksum hashing algorithm?

I have used his MD5Mate.

[plj]

Originally Posted by Bathrone

Its a red herring. That just usual windows behaviour with the file system and the latency/bandwidth limitations of moving the files around

If you wanted to get all scientific, you could run a checksum hashing algorithm over the unmoved mods files and then move it with a profile, see the not responding due to latency/bandwidth, then once the mod enabler has all moved the files, re run the hashing algorithm over the same files just moved and you *WILL* see that the hash values are identical

This is not the problem folks

Given mike's finding here it seems that JSGME is err-ing sometimes for some reason.

I went through the documentation yesterday, and the unresponsive UI for JSGME is by design .. described as some sort of optimization to make JSGME focus on the task at hand .. while in fact, it's lazy coding. In that loop should be the equivalent of vbscripts DoEvents().

All scientific, the files could vastly differ due to how JSGME handles files .. open/locked files are ignored and will not be copied, so it takes as much as having a file open by accident in notepad++ or something, and en/dis-abling your modlist at that moment. This could even happen if windows for some reason wont release the lock on the file .. for instance cuz the game crashed.

But you are right in that the unresponsiveness is an issue .. it's just not so elegant coding :p

[THE_MASK]

I am 99% sure most ctds are ubi game launcher related . TDW says that and the fact that I can reload all previous saves and the game works .

[volodya61]

Originally Posted by sober

I am 99% sure most ctds are ubi game launcher related...

Unfortunately no.. I've never used launcher..

[plj]

I dont use the launcher either .. so everything I can replicate, is not launcher related .. same for volodya ... that leaves us with verry few scenarios to ascribe to the launcher .. and tbh, I think it can be ignored as cause unless we are able to replicate the issue.

[Trevally.]

Originally Posted by volodya61

Unfortunately no.. I've never used launcher..

Originally Posted by plj

I dont use the launcher either .. so everything I can replicate, is not launcher related .. same for volodya ... that leaves us with verry few scenarios to ascribe to the launcher .. and tbh, I think it can be ignored as cause unless we are able to replicate the issue.

Then how are you starting the game

[gap]

Originally Posted by Trevally.

Then how are you starting the game

... they are listening

[plj]

Originally Posted by Trevally.

Then how are you starting the game

Set to offline in uplay screen .. be done with it. You loose the (useless) online functions.

[Bathrone]

Originally Posted by plj

Given mike's finding here it seems that JSGME is err-ing sometimes for some reason.

I went through the documentation yesterday, and the unresponsive UI for JSGME is by design .. described as some sort of optimization to make JSGME focus on the task at hand .. while in fact, it's lazy coding. In that loop should be the equivalent of vbscripts DoEvents().

All scientific, the files could vastly differ due to how JSGME handles files .. open/locked files are ignored and will not be copied, so it takes as much as having a file open by accident in notepad++ or something, and en/dis-abling your modlist at that moment. This could even happen if windows for some reason wont release the lock on the file .. for instance cuz the game crashed.

But you are right in that the unresponsiveness is an issue .. it's just not so elegant coding :p

Hi there mate

With concerns about locked files etc from the mod enabler, this is easy for people who are concerned to test. Ive suggested one method of using a hashing algorithm. I'd encourage people to test out these ideas so it becomes empirical and certain. If there is error handling problems with the mod enabler, perhaps the mod enabler can be enhanced to be more robust with these sort of error conditions. If the tests prove there isnt a robustness problem for error conditions, then we can all relax in that certainty.

As for MikeMike and a bit of cruft being left over with the mod enabler, I dont see this as a problem if it is indeed cruft. Again people can easily test this instead of being superstitious For example, if I created a cruft file named:

thisfileisguunactdmygame.py

Since the file is obviously made up, it not used by anything in SH5, it is indeed cruft and will have no impact on the game.

[plj]

Leftover NewUI files are an issue .. as their names dont change between versions. They SHOULD get overwritten, but apperantly this doesnt always happen .. could be due to JSGME abuse .. has to be checked tho.

My deleted (from within save menu) savegame's deathmarks showed up on a new game (same captain name) 20 days before they happened in that game. These are deatmarks from patrol 2 while I'm on patrol one. This should not happen an is only explainable with leftovers remaining while they shouldnt.

I'm poking around atm, and I'll start hashing my gamedir after mod enabling/disabling with reference to .mep used and date and list changes if they occur.