Quote:
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.