> Dear Maintainer, > > z_code.py looks at whichever engine is available at build-time and > hard-codes that into the resulting .desktop file. Ideally the package > should use the zcode-interpreter alternative, although that isn't > supported by all packages Z-Machine emulators currently, and doesn't > work well with X- v. terminal-based interpreters. > > Regards, > > Stephen
Hi, I also thik z_code module is not optimal the way it's implemented. It would be better to have an updatable runtime shipped in a game-data-packager .deb or a runtime-only spun-out deb than to have z_code generate a 2-line shell script that can't be updated without requesting user to recreate the .deb with GDP. We then would always use entry['Terminal'] = 'false' and have our runtime launch an xterm / konsole / ... if the engine needs it (which means it's not gargoyle-free) The .desktop file would call our runtime with a --gui option telling it the console / xterm is needed. Otherwise (=when called from the command-line), the runtime would launch the game in the current tty. We could have symlinks like /usr/games/zork1 -> /usr /game/zgame and zgame would know which game to run from it's arg[0]. Alexandre I've played around something similar for DOSbox. (and Skyroads in DOSbox works lovely on a ARM Chromebook, so even if this was originaly i86 code, this can now be considered "all" data !) http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/game_data_packager/games/dosbox.py With the second half in 'runtime': http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/runtime /dosgame.py
