Opened 15 years ago

Closed 14 years ago

Last modified 12 months ago

#1850 closed defect (fixed)

SCUMM: HE games create files in wrong location (Regression)

Reported by: Kirben Owned by: Kirben
Priority: normal Component: Engine: SCUMM
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 eriktorbjorn, 15 years ago

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.

comment:2 by Kirben, 15 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 eriktorbjorn, 15 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 fingolfin, 15 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 sev-, 15 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 fingolfin, 15 years ago

Owner: changed from fingolfin to Kirben

comment:7 by fingolfin, 15 years ago

Some solutions have been proposed now... so HE folks, what's your
plans? :-)

comment:8 by Kirben, 15 years ago

Priority: highnormal

comment:9 by Kirben, 15 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 Kirben, 14 years ago

Resolution: fixed
Status: newclosed

comment:11 by digitall, 12 months ago

Component: --Unset--Engine: SCUMM
Note: See TracTickets for help on using tickets.