Opened 12 years ago

Closed 12 years ago

Last modified 12 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
Version: Keywords:
Cc: Game: Leisure Suit Larry 5


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 12 years ago.
LSL5 MD5 Sum
LSL5-diff.txt (1.7 KB ) - added by digitall 12 years ago.
Differences between Bug and No Bug LSL5 versions…

Download all attachments as: .zip

Change History (32)

comment:1 by digitall, 12 years ago

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 would be optimal, so we can look at whether this is a problem with scripts in one of the LSL5 variants.

comment:2 by digitall, 12 years ago

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

comment:3 by digitall, 12 years ago

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 by digitall, 12 years ago

Owner: set to digitall
Resolution: invalid
Status: newpending

comment:5 by digitall, 12 years ago

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

by SF/captainjei, 12 years ago

Attachment: LSL5 Test.md5 added

LSL5 MD5 Sum

comment:6 by SF/captainjei, 12 years ago

Status: pendingnew

comment:7 by SF/captainjei, 12 years ago

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:


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.

by digitall, 12 years ago

Attachment: LSL5-diff.txt added

Differences between Bug and No Bug LSL5 versions...

comment:8 by digitall, 12 years ago

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 by digitall, 12 years ago

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

comment:10 by wjp, 12 years ago

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 by digitall, 12 years ago

Owner: digitall removed

comment:12 by digitall, 12 years ago

Resolution: invalid

comment:13 by digitall, 12 years ago

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 by digitall, 12 years ago

Resolution: worksforme
Status: newpending

comment:15 by fuzzie, 12 years ago

Is related (specifically the later posts about lsl5)?

comment:16 by wjp, 12 years ago

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

comment:17 by wjp, 12 years ago

Resolution: worksforme
Status: pendingnew

comment:18 by fuzzie, 12 years ago

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 by wjp, 12 years ago

Priority: normalblocker

comment:20 by bluegr, 12 years ago

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).


comment:21 by fuzzie, 12 years ago

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 by wjp, 12 years ago

I say we just fix the save path.

comment:23 by bluegr, 12 years ago

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 by wjp, 12 years ago

Why? I see no reason for doing that.

comment:25 by bluegr, 12 years ago

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 by wjp, 12 years ago

Not store the save games in a system directory?

comment:27 by fuzzie, 12 years ago

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 by bluegr, 12 years ago

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

comment:29 by bluegr, 12 years ago

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 by bluegr, 12 years ago

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