Bugzilla Bug 42836

I previously had drod-bin-1.6.3 emerged.  I played the game a lot, and I really
enjoyed it.  I guess it got upgraded to 1.6.5 in an system-wide upgrade (emerge
world), and it appears that my save game files were lost.

Drod saves its games in /opt/drod/bin/Data/, which is somewhat unorthodox. 
Still, I wouldn't expect upgrading to destroy my saved games.  Maybe I'm not
clear on the gentoo concept of an "upgrade", or maybe this ebuild needs to be
tweaked.

Reproducible: Always
Steps to Reproduce:
1. emerge drod-bin-1.6.3, play for awhile to build a save game.
2. emerge drod-bin-1.6.5.
3. Start drod, and you will be prompted for your name, because your savegames
have been overwritten.

Actual Results:  
See step 3.

Expected Results:  
I believe that the ebuild should check for existing save games, and at the VERY
least warn me that they'll be overwritten.  I did not expect this at all, so my
last backup was a ways back.

Portage 2.0.50 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.22)
=================================================================
System uname: 2.4.22 i686 Mobile Intel(R) Pentium(R) III CPU - M   900MHz
Gentoo Base System version 1.4.3.13
Autoconf: sys-devel/autoconf-2.58
Automake: sys-devel/automake-1.7.7
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=pentium3 -funroll-loops -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
CXXFLAGS="-O3 -march=pentium3 -funroll-loops -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://128.213.5.34/gentoo/
http://mirror.clarkson.edu/pub/distributions/gentoo/
http://gentoo.seren.com/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acpi alsa arts avi berkdb cdr crypt cups dga doc dvd encode esd
foomaticdb gdbm gif gphoto2 gpm gtk gtk2 gtkhtml guile imlib java jpeg libg++
libwww mad mikmod mmx motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss
pam pdflib perl png ppds python qt quicktime readline ruby sdl slang sse ssl
svga tcltk tcpd tetex truetype usb x86 xml2 xmms xv zlib"

we'll see what we can do about making sure save files arent nuked ...

but we dont have too much control over /opt/drod/bin/Data/ considering this is a binary-only game ...

Good point.  This also might be complicated by the fact that
/opt/drod/bin/Data/drod1_6.dat might contain game data as well as save data. 
Might want to talk to the developers on that.

If you can't just omit emerging these files, then I think a big fat warning and
a chance to cancel would be fine.

BTW, in a bizarre twist, I think we were in the same class at WPI.

ok, we might be a little screwd with drod saved games unless we talk to
upstream and have them fix the way they work ...

i did this:
emerge drod-bin
<play the game for a few hours and get to level 5>
qpkg -cm drod-bin -v
<shows only files in /opt/drod/bin/Data/ being modified>
mv /opt/drod/bin/Data/ /opt/drod/bin/Data.backup/
emerge drod-bin
<run drod and see my saved games are gone>

so now, if we look in Data/, we find these files we modified:
drod1_6.dat player.dat text.dat
from what i can tell by copying the backed up files over brand new ones in
different combinations, in order to rully restore a saved game you have to have
drod1_6.dat and player.dat from the old install ... only one or the other is
not enough to restore the saved game

this presents a problem since all the level data is contained in drod1_6.dat
...

for now i've added this to the ebuild:
[ -e /opt/drod/bin/Data ] && cp -r /opt/drod/bin/Data{,.backup}
and then it'll output a warning saying that the saved games have been copied to
Data.backup ... for a proper fix, i think we're gonna have to bug upstream to
do 'the right thing' and save in the users home directory (like ~/.drod/)

as for your saved game, it looks like your plain outta luck, sorry :/

and yes, we've been in a few classes together ... ive given up on most of the
students at WPI so i dont bother being active in class/mailing lists very often
unless it's a friend or someone personally asks me

alrighty, i've e-mailed upstream describing the issue and requesting some
enhancements (saved games in ${HOME}/.drod/) ...

i guess now we wait and see if they get back to us

Yeah, I already figured I was out of luck.  I've asked on the drod forum for
someone to pity me and throw me a save file :)  Fortunately at the very least
I've saved future people like me from losing their games entirely.  From what I
can tell, not many updates actually change the level files, so it's often fine
for the user to just manually move their backed up data files back.

This is fixed in DROD 1.6.6 (Sorry about the delay!).  The full setup will be
out sometime today, maybe tomorrow -- I'll make an updated ebuild request when
it's done (got some questions about the behavior of the current ebuild, but
I'll ask them there).

The DROD 1.6.6 installer won't overwrite existing dat files (because there's
not any need to do that -- the db format didn't change between any 1.6
versions).  Also, if any of the data (or the ini file) is read-only, local
copies of all data files (and the ini) will be made in the user's home
directory, under $HOME/.caravel/drod-1_6.  If all data and the ini are
writable, it behaves the same as 1.6.5.  That should make everyone happy, right
? =)

Any questions or comments, feel free to email me at gerryj (at) caravelgames
(dot) net.