ScummTR corrupts MONKEY1-VGA "v1.0" in ScummVM about scummtr HOT 4 OPEN

Comparing the game data files before a simple scummrp reimport show that only 000.LFL is modified, in 4 bytes:

--- 000.LFL.original
+++ 000.LFL.modified
@@ -219,7 +219,7 @@
 00000f20  00 00 00 00 00 00 00 3c  c2 67 00 00 0b 67 d9 00  |.......<.g...g..|
 00000f30  00 2d 84 79 00 00 0e 34  82 00 00 0a bb ae 01 00  |.-.y...4........|
 00000f40  0b a1 de 00 00 0a 9f b0  01 00 3a a4 83 01 00 2d  |..........:....-|
-00000f50  7a db 00 00 55 97 e0 00  00 3b[82 8e 01 00]3b d8  |z...U....;....;.|
+00000f50  7a db 00 00 55 97 e0 00  00 3b[ff ff ff ff]3b d8  |z...U....;....;.|
 00000f60  9b 01 00 25 e0 42 01 00  25 8e 58 01 00 35 14 2b  |...%.B..%.X..5.+|
 00000f70  01 00 35 11 49 01 00 35  84 1c 01 00 35 2f 25 01  |..5.I..5....5/%.|
 00000f80  00 3b bb fc 01 00 00 00  00 00 00 00 00 00 00 00  |.;..............|

The ff ff ff ff probably come from setting the offset to -1 in the workaround. I don't know if it's a valid value there; I doubt it, although the DOS version does appear to tolerate it (but I haven't played a full game to confirm it; the duplicate costume is only triggered at the very end of the game, when LeChuck sends you through the grog machine).

It looks like ScummRp may have a special treatment when an offset is set to -1 for duplicate scripts, but maybe something is wrong/missing when dealing with duplicate costumes.

By the way, my French version (with the bug) shows Version 1.0 in Ctrl-V, while my English version (without the duplicate costume) shows Version 1.1. So this problem is maybe just limited to the earliest VGA floppy versions, but we'd still like to have a proper workaround for them, as as far as I know there's no 1.1 French FLOPPY-VGA version.

Anyway, I've pushed commit 4f92fe2, so that ScummTr 0.5.0 just rejects this version, instead of corrupting the game. I just don't know how to fix this at the moment, and I'd like to release ScummTR 0.5.0 this month. Since no earlier version of ScummTr had support for these variants anyway, it's not going to be a regression…

from scummtr.

Looks like this bug may exist in all "v1.0" versions of the VGA game:

https://forums.scummvm.org/viewtopic.php?p=89717#p89717

from scummtr.

I actually wonder if this corruption doesn't just come from the parsing problem which causes #54 and #56…

EDIT: If you unpack/repack MONKEY1-FLOPPY-VGA with ScummPacker, the same glitch is triggered.

from scummtr.

FWIW, regarding the "glitch" above, if the issue only shows up in ScummVM, that's maybe because the 000.LFL index file gets changed a bit, and so ScummVM won't recognize it as Monkey1 VGA but Monkey1 EGA (which is wrong), since its fallback detection code is currently a bit limited.

So actually ScummPacker's fix for the index problem in Monkey1 VGA is maybe OK, but the ScummVM detection bug just made me misdiagnose the issue.

from scummtr.