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.
