Re: Quake packaging
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.
quake is about ready for a first upload too, but it'll need a second trip
through the NEW queue for missionpack support (once my copies arrive from
eBay), or I might hold off on uploading anything until I've done the
mission packs if that goes as quickly as I hope. I'll probably add a
quake-server binary package at the same time.
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!
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?
On Sat, 09 Jul 2011 at 20:38:28 +0100, David Banks wrote:
> > In my branches I changed the target distribution to UNRELEASED, because if
> > I'm going to sponsor this, I'll upload directly from pkg-games git, and only
> > push the change from UNRELEASED to unstable when I have actually uploaded.
>
> Hmm, I don't really understand what it means to upload directly from
> pkg-games git, but if it works it's no problem for me.
For your reference: sponsoring normally starts from a downloaded source
package, but since I'm in pkg-games too, instead of getting your .dsc from
mentors.d.n, I generally prefer to update my git checkout and build from
there. In the historical (non-VCS) Debian workflow there's a big difference
between a sponsored upload and an upload by a co-maintainer, but collaborative
maintenance in a VCS blurs the distinction.
> Just out of interest, what's the benefit to shipping the multiple sizes
> of icon? I figured that most environments would just scale down the
> large one.
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.
(You can also do tricks analogous to font hinting - simplifying shapes
at smaller sizes, and aligning lines to pixel boundaries to avoid blurring -
but the Quake logo doesn't really need the former, and is too curved for the
latter to be very useful.)
> > 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!
> > If you need a command-line option, the packages produced by g-d-p should
> > probably be called quake-armagon-data and quake-dissolution-data, and the
> > quake source package should produce quake-armagon and quake-dissolution
> > binary packages (similar to quake) with a .desktop and .menu that use
> > the appropriate option.
>
> This would make it more consistent, although I think anyone who has the
> mission packs likely knows about -rogue, -hipnotic and such.
I was hoping we could have nice menu entries for the mission packs,
for non-command-line users :-)
(Hmm, I'll have to work out some sort of identifiable icon, though...)
> 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
packs?
> > I notice that quakespasm uses ~/.quakespasm, not ~/.quake. This means that
> > if we ever decide to make quake use a different engine, everyone doing an
> > upgrade will "lose" their settings and savegames, which would be
> > unfortunate.
>
> Yeah, that's a good point. I'm not sure if savegames would generally be
> cross engine compatible. (/me looks at the format) Actually since it's
> all text it might be OK.
When I tried it, DarkPlaces loaded a QuakeSpasm savegame, but QuakeSpasm
couldn't load a DarkPlaces savegame:
% quake --engine=darkplaces
(start single-player, don't bother choosing a skill level)
] save darkplaces
] quit
% mv ~/.darkplaces/id1/darkplaces.sav ~/.quakespasm/id1/
% quake --engine=quakespasm
] load darkplaces
Loading game from /home/smcv/.quakespasm/id1/darkplaces.sav...
ERROR-OUT BEGIN
Shutting down SDL sound
QUAKE ERROR: First token isn't a brace
There's some extra cruft at the end of the save which is probably the reason:
+// DarkPlaces extended savegame
+sv.lightstyles 0 m
[...]
> It's likely that config.cfg files would be mostly cross engine
> compatible
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 saw you added quakespasm-dbg package [...]
> it produces an empty binary package.
Sorry, I got halfway through implementing that. I'll finish it.
S
Reply to: