#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 |
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)
Change History (32)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
| Summary: | LSL5 password lock-out on first run (without memory.drv) → SCI: LSL5 memory.drv (Password) file issues |
|---|
comment:3 by , 13 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 , 13 years ago
| Owner: | set to |
|---|---|
| Resolution: | → invalid |
| Status: | new → pending |
comment:5 by , 13 years ago
| Component: | → Engine: SCI |
|---|---|
| Game: | → Leisure Suit Larry 5 |
| Keywords: | script added |
comment:6 by , 13 years ago
| Status: | pending → new |
|---|
comment:7 by , 13 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:
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.
by , 13 years ago
| Attachment: | LSL5-diff.txt added |
|---|
Differences between Bug and No Bug LSL5 versions...
comment:8 by , 13 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 , 13 years ago
Oh, I have attached a diff file showing the differences between mine and your versions...
comment:10 by , 13 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 , 13 years ago
| Owner: | removed |
|---|
comment:12 by , 13 years ago
| Resolution: | invalid |
|---|
comment:13 by , 13 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 , 13 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → pending |
comment:15 by , 13 years ago
Is http://forums.scummvm.org/viewtopic.php?t=11211 related (specifically the later posts about lsl5)?
comment:17 by , 13 years ago
| Resolution: | worksforme |
|---|---|
| Status: | pending → new |
comment:18 by , 13 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 , 13 years ago
| Priority: | normal → blocker |
|---|
comment:20 by , 13 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).
Opinions?
comment:21 by , 13 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:23 by , 13 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:25 by , 13 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:27 by , 13 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 , 13 years ago
It seems that this bug can be closed now, after kirben's change... right?
comment:29 by , 13 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 , 13 years ago
| Keywords: | script removed |
|---|---|
| Owner: | set to |
| Resolution: | → fixed |
| Status: | new → closed |
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.