Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#5920 closed defect (fixed)

SCI: LSL5 memory.drv (Password) file issues

Reported by: SF/captainjei Owned by: Kirben
Priority: blocker Component: Engine: SCI
Keywords: Cc:
Game: Leisure Suit Larry 5

Description

I copied the required files from the LSL5 CD to a folder on my hard driver. The file 'memory.drv', which holds the password information, is not included on the CD. I load up the game for the first time in ScummVM, and after the intro I am asked to enter my password. Of course, nothing works, and after five tries, the game quits.

To get around this, I had to run the game in DOSBox. This time, after the intro, I was asked if I wanted to CREATE a password, which is what's supposed to happen. I said 'Why bother?' and quit. The file 'memory.drv' had been created, and when I ran the game again in ScummVM, I was asked if I wanted to create a password this time around, instead of being asked in enter a password that hadn't been created yet.

It seems that ScummVM should optimally be able to handle the absence of 'memory.drv' in the case of first runs.

ScummVM version:1.5.0git1072-gcc81dfe (Dec 5 2011 12:38:40)
English language CD-ROM (Sierra Originals version)
Windows 7

Ticket imported from: #3458932. Ticket imported from: bugs/5920.

Attachments (2)

LSL5 Test.md5 (1.9 KB) - added by SF/captainjei 8 years ago.
LSL5 MD5 Sum
LSL5-diff.txt (1.7 KB) - added by digitall 8 years ago.
Differences between Bug and No Bug LSL5 versions…

Download all attachments as: .zip

Change History (32)

comment:1 Changed 8 years ago by digitall

captainjei: Tried replicating this with latest Git master on Linux x86_32. Can't replicate this.

Please note that the memory.drv file which contains the password should _NOT_ be created in the game datafile path by ScummVM, as this is generally read-only. It is generated in the savegame path as "lsl5-MEMORY.DRV".

Please ensure that this bug is not due to a pre-existing lsl5-MEMORY.DRV file in the savegame path for an older password.. If not, please attach a text file containing a listing of your lsl5 datafiles with md5sums i.e. the output of a tool such as http://md5summer.org/ would be optimal, so we can look at whether this is a problem with scripts in one of the LSL5 variants.

comment:2 Changed 8 years ago by digitall

Summary: LSL5 password lock-out on first run (without memory.drv)SCI: LSL5 memory.drv (Password) file issues

comment:3 Changed 8 years ago by digitall

captainjei: Since you haven't responded, I'm going to assume that this was due to an old lsl5-memory.drv file...
Setting bug to "Pending", Unless you respond with 14 days, it will automatically be closed.

comment:4 Changed 8 years ago by digitall

Owner: set to digitall
Resolution: invalid
Status: newpending

comment:5 Changed 8 years ago by digitall

Component: Engine: SCI
Game: Leisure Suit Larry 5
Keywords: script added

Changed 8 years ago by SF/captainjei

Attachment: LSL5 Test.md5 added

LSL5 MD5 Sum

comment:6 Changed 8 years ago by SF/captainjei

Status: pendingnew

comment:7 Changed 8 years ago by SF/captainjei

Apologies for the wait. I've been trying to replicate the problem, and I've managed to do so on my own system.

First of all, there is no lsl5-memory.drv in the save folder whatsoever (and I have folder settings set so that hidden files are shown). I can see the individual lsl5.000 etc. save games, though.

Since this is the first time I've owned and tried adding the game, I can't see how there could be an old lsl5-memory.drv that could be causing the problem.

To replicate the problem I launched ScummVM and removed the game. I created a new folder and copied all the files from the CD-ROM game folder (which does not contain MEMORY.DRV by default) to the new folder. I added it through ScummVM and launched it. The same password problem ensues.

This is a listing of the files I copied:

ADL.DRV
CMS.DRV
IBMKBD.DRV
IBMPS1.DRV
INSTALL.EXE
INSTALL.HLP
INSTALL.SCR
INSTALL.TXT
INTERP.TXT
JOYSTICK.DRV
LSL5.BAT
LSL5H.BAT
LSL5RS.BAT
MT32.DRV
MTBLAST.DRV
MTPRO.DRV
PROAUDIO.DRV
README.TXT
RESOURCE.000
RESOURCE.001
RESOURCE.002
RESOURCE.003
RESOURCE.004
RESOURCE.005
RESOURCE.006
RESOURCE.007
RESOURCE.CFG
RESOURCE.MAP
SCIDHUV.EXE
SIERRA.BAT
SIERRAH.BAT
SNDBLAST.DRV
STD.DRV
TANDY3V.DRV
TANDY3VD.DRV
TANDYKBD.DRV
VERSION.TXT
VGA320.DRV
VGA320BW.DRV

I've also attached an md5 file. I hope this is the format you wanted.

To get the game to work again, I once again ran DOSBox, which created the MEMORY.DRV file, quit, and the re-ran the game in ScummVM. Every works fine. I don't claim to understand how ScummVM works internally, but it really looks like it's somehow using the MEMORY.DRV file instead of its own lsl5-memory.drv

Thank you for looking into this. I will try to be more timely in the future.

Changed 8 years ago by digitall

Attachment: LSL5-diff.txt added

Differences between Bug and No Bug LSL5 versions...

comment:8 Changed 8 years ago by digitall

captainjei: I have compared my version of LSL5 from the LSL Collection, with which I can't replicate the issue with yours.

There are a number of differences in the datafiles, but the main difference is that your version seems to be missing the v1.0 i.e. it is missing all the LSL5 patches <nnn>.SCR etc.

But even if I remove the patches, I can't seem to replicate the issue you are seeing.

Could you try backing up your configuration file (scummvm.ini) and starting with a blank configuration file and having no LSL5 savegame files in the savegame path, and no MEMORY.DRV in the datafiles directory, and then reporting if the bug still occurs here?
If so, try removing the files (CMS.DRV TANDY3V.DRV, TANDY3VD.DRV, TANDYKBD.DRV) which are only in your version...

comment:9 Changed 8 years ago by digitall

Oh, I have attached a diff file showing the differences between mine and your versions...

comment:10 Changed 8 years ago by wjp

Could you run scummvm from the command line with "scummvm --debugflags=file", and report what you get when this bug happens? For reference, this is what I get when I have no memory.drv file:

User picked target 'lsl5-1' (gameid 'sci')...
Looking for a plugin supporting this gameid... SCI [SCI0, SCI01, SCI10, SCI11, SCI32]
Starting 'Sierra SCI Game'
kGetCWD() -> /
kFileIO(open): version, 0x1
-> opened file 'version' with handle 1
kFileIO(readString): 1, 11
-> FGets'ed "1.000"
kFileIO(readString): 1, 20
-> FGets'ed "09/11/91"
kFileIO(readString): 1, 20
-> FGets'ed "800 326-6654"
kFileIO(readString): 1, 20
-> FGets'ed "800 683-4468"
kFileIO(close): 1
kFileIO(open): MEMORY.DRV, 0x1
-> file_open(_K_FILE_MODE_OPEN_OR_FAIL): failed to open file 'MEMORY.DRV'
-> file_open() failed
kFileIO(open): MEMORY.DRV, 0x2
-> opened file 'MEMORY.DRV' with handle 1
kFileIO(writeString): 1
kFileIO(writeString): 1
kFileIO(writeString): 1
kFileIO(close): 1

comment:11 Changed 8 years ago by digitall

Owner: digitall deleted

comment:12 Changed 8 years ago by digitall

Resolution: invalid

comment:13 Changed 8 years ago by digitall

captainjei: Could you please try the course of action suggested by wjp?

I am going to set this bug to pending as the user has not responded. If not further information is provided to investigate this bug, it will be automatically closed in 14 days.

comment:14 Changed 8 years ago by digitall

Resolution: worksforme
Status: newpending

comment:15 Changed 7 years ago by fuzzie

Is http://forums.scummvm.org/viewtopic.php?t=11211 related (specifically the later posts about lsl5)?

comment:16 Changed 7 years ago by wjp

Re-opening in light of the forum thread fuzzie linked to.

comment:17 Changed 7 years ago by wjp

Resolution: worksforme
Status: pendingnew

comment:18 Changed 7 years ago by fuzzie

The virtualizing filter driver which implements VirtualStore does indeed block attempted writes to .drv files, and so the cause of this bug is that we're still saving to Program Files by default, presumably.

comment:19 Changed 7 years ago by wjp

Priority: normalblocker

comment:20 Changed 7 years ago by bluegr

I see, so the problem is caused by the filtering of *.drv files.

Only LSL3 and LSL5 write in such fake *.drv files, so we could change the output name to something else (e.g. memory.drv.fake and ll3.drv.fake) to bypass the VirtualStore file protection. This won't make any real difference for the game itself, and this way we could also skip reading the original fake driver files (which may be inside the game data files and thus not writeable).

Opinions?

comment:21 Changed 7 years ago by fuzzie

I think trying to work around the VirtualStore issues with per-engine hacks is a dangerous approach, if nothing else then because it's hiding issues which could pop up elsewhere in the future. Not enough of an SCI expert to comment otherwise.

comment:22 Changed 7 years ago by wjp

I say we just fix the save path.

comment:23 Changed 7 years ago by bluegr

Well, there is already a per-engine hack for some versions of LSL5. Some versions have issues when memory.drv is missing, and the file won't be recreated. Thus, extending this handling to also change the output name is trivial... As I said, these fake files are only created by these two games, and the hack needed to change the output name should be trivial. I'll have a look tonight for a proof of concept.

comment:24 Changed 7 years ago by wjp

Why? I see no reason for doing that.

comment:25 Changed 7 years ago by bluegr

Because this is a "feature" of an operating system which blocks a functionality needed by a game. I see no other way to work around this other than modifying the feature that the game wants, so that it works with this case.

Do you have any alternative suggestions, which won't confuse users?

comment:26 Changed 7 years ago by wjp

Not store the save games in a system directory?

comment:27 Changed 7 years ago by fuzzie

Kirben just fixed the save path on master in 8701e0a but presumably we'll need a migration solution for that to go onto the branch. (Note that this bug report is for 1.5.x anyway, though.)

comment:28 Changed 7 years ago by bluegr

It seems that this bug can be closed now, after kirben's change... right?

comment:29 Changed 7 years ago by bluegr

Closing this and assigning to kirben, since the bug should be fixed with his changes.

If for any reason you feel that the issue is not addressed sufficiently, feel free to reopen this

comment:30 Changed 7 years ago by bluegr

Keywords: script removed
Owner: set to Kirben
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.