#1850 closed defect (fixed)
SCUMM: HE games create files in wrong location (Regression)
| Reported by: | Kirben | Owned by: | Kirben |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Latest ScummVM CVS (Either branch) Compiled with GCC 3.4.2 under mingw. All HE games.
ScummVM currently creates files in the directory ScummVM was started from. While before ScummVM would create files in the game's data files directory. This is caused by changes in common/file.cpp revision 1.173. This causes regressions, for example: Changes to the colors of paintings in fbpack are no longer saved, since the 'fbpack.pal' file is created in wrong location. The original versions of HE games always created files in the game's data files directory. HE games usually create/delete a 'test' file to check if directory is writiable on startup and handle any file errors via scripts. This could
Ticket imported from: #1088136. Ticket imported from: bugs/1850.
Change History (11)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
Let me give another example, for fbear this time: The game includes a 'fbear.sng' file. The file is loaded when using the piano mini game. The file is updated with added songs, when exiting the mini game. So the file must be saved to the same location, or the original unchanged file would always be reloaded when mini game is used.
HE games (Like example above ^) often create a temporary file, delete original file and rename temporary file. We still need to add true file delete/rename support to ScummVM sometime too.
comment:3 by , 20 years ago
The behaviour I'd like to see in that case would be to store the modified version in the savegame directory and keep the original, unmodified, version in the game directory. When reading the file, it would first check in the savegame directory and only use the original if that fails.
Would that be possible/practical? Assuming that the user has write permission in the game directory seems overly optimistic to me. I know I don't have that on my Linux box, and I doubt I'm the only one.
comment:4 by , 20 years ago
I agree with erik. Directly modifying data supplied with the game files? Ugh. What if ScummVM crashes at the wrong moment, is your HE game then rendered useless because fbear.sng misses? Baad. In addition, there are systems (like the dreamcast) where you *never* will have write access to the game data dir
But you can always do this: first try to use the savefile manager to open the data file. If it is missing/empty, load the corresponding file from the game data dir, and copy its content into the savefile (i.e. file->read() and then savefile->write()).
As for moving/renaming/deleting files? That's problematic, too, for portabillity reasons.
comment:5 by , 20 years ago
Yes, the problem is that original "Installed" game, i.e. it created a directory where it kept all such files which could be changed. That let it run from the CD. With current approach (modifying file in game data directory) this is not possible, and user should copy all files to HDD. For some games this could be over 400 megs :)
comment:6 by , 20 years ago
| Owner: | changed from to |
|---|
comment:7 by , 20 years ago
Some solutions have been proposed now... so HE folks, what's your plans? :-)
comment:8 by , 20 years ago
| Priority: | high → normal |
|---|
comment:9 by , 20 years ago
The first series of HE games (HE60) were bad in the aspect, since they always altered the orignal data files directly. All later HE games (HE70+) saved changes to data files to a separate location (Usually set by SaveGamePath entry in INI).
I added the suggested changes to HE60/72 versions of the openfile opcode: File writes are always made to saved game path. File reads check saved game path first, and data files path second.
The file delete/rename function could be left as stubs in ports which are unable to support them. They are only required for using the original games load/save system (Which is script based) and for saving mini game changes in just fbear I think.
comment:10 by , 20 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:11 by , 6 years ago
| Component: | --Unset-- → Engine: SCUMM |
|---|
Both ways sound wrong to me. Shouldn't it be using the savefile manager to store files in the save directory where it's more-or-less guaranteed to have write access? I believe that's how we handle FOA's "IQ" file.