Re: Quake packaging
Sorry for my late reply, hopefully this is still relevant.
On 09/07/11 22:46, Simon McVittie wrote:
> Replies inline, but first a brief top-posted summary:
> I think quakespasm and darkplaces are about ready for upload, once I've
> fixed the quakespasm-dbg package.
Awesome, thanks for uploading Quakespasm. I've let upstream know that
it has entered Debian.
> Feel free to commit stuff to darkplaces.git (and in particular add yourself
> to the Uploaders), if you're interested - I suspect you know Quake better
> than I do!
You mentioned that I could try to upstream the Darkplaces patches, I
took a look at them today. I guess I should try all of them? I'll
probably submit the build system improvements as a single patch to make
it easier for upstream to review. And I'm not sure I understand the
libpng type safety stuff, could you quickly summarize it for me?
> To complete the set, I've vaguely started work on a quake2 package based on
> quake and quake3 (see quake2.git in the usual place) but I haven't yet
> researched which engine fork(s) we should be using or which files
> game-data-packager will need. If you like Quake II, you're welcome to
> help out - APRQ2, Quetoo or R1Q2 look like possibilities?
Hmm, interesting. I don't have Quake II at the moment (though I did
play through it a long time ago), maybe I'll see if I can get a copy.
> The Tango icon style guide recommends 1px outlines at all sizes <= 48px
> (so the icons don't just scale down proportionally - the outline gets,
> proportionally, thicker as you reduce the size). This makes the outlines
> nice and clear.
>>> If you launch a game of vanilla Quake, can you "upgrade" to a
>>> mission pack through the GUI
>> Definitely in the original engine and also in Quakespasm you have to
>> re-run the engine and change it on the command line.
> OK, so we probably want a separate .desktop for each mission pack. I have
> both mission packs on the way from eBay, so I'll try this out soon!
Today I found out that what I said was wrong - Quakespasm (but not the
original game) can switch between games mid-run. It's not clear whether
this works fully for rogue and hipnotic (which I don't have handy at the
moment), as those games involve tweaks hardcoded into the engine along
the lines of Nexuiz.
However having just checked it doesn't seem to work very well, as
loading without a -game parameter and then using "game drake" at the
console, I couldn't access any maps under drake/maps which are available
when starting with "-game drake". So this should probably be considered
experimental for now, I'll report upstream bug.
At a quick glance it seems like Darkplaces doesn't claim it can do this.
>> I can
>> definitely put the appropriate packages in 'quake' package, but I guess
>> the binaries and menus would always end up installed, even if the user
>> did not have those data packages installed?
> Unless we do a separate binary package per mission pack, or (as a compromise)
> one for the base game, and one for users with either or both of the mission
Actually a separate binary package per mission pack sounds totally fine.
Not sure what I meant above.
> Having thought about this some more I think the key word there is
> "mostly", unfortunately.
> If we make sure all alternatives are priority=0 like I said in the
> mini-policy, then we shouldn't "lose" any savegames, because automatic mode
> for update-alternatives will never replace quakespasm with darkplaces or
> vice versa. If someone uses manual mode, or installs a new engine and
> uninstalls the old one, then "you asked for it, you got it".
> To avoid collisions I'll add a note to the mini-policy that specifically
> says to use a dot-directory per engine.
I definitely agree with this, consistency and predictability take
Thanks again Simon.