Re: quake I for woody
On Mon, Dec 31, 2001 at 11:51:44AM -0500, Jeff Teunissen wrote: > > The stuff outside I have done. Back in March or so I designed a nice, > > complex, and complete system for handling gamedata. It would work as > > long as an engine using it had fs_* Cvars and config files. Unless of > > course you did something unexpected in your config file, in which case > > it puked. Too fancy, and it broke. > > Solution without a problem. Game data must keep its name, and both registered > and unregistered Quake game data always has to be in id1. Since the shareware data does not traditionally work in QW at all and NQ does not keep track of the game directory, I've continued putting it into idsw. I suppose this discussion could move to debian-devel-games at this point though, which I might actually still be subscribed to. Seems that the only traffic that list gets anymore is spam. I'm not actually on debian-devel anymore. > > I can actually do the necessary work to get the shareware thing done > > next weekend (I'm going on holiday for a few days and won't have much > > time for code..) As for the registered game installer, I've got > > something written in perl for that already, but it's not much and it > > comes with a big warning that perl is not a language I actually grok. > > I have had a quake-shareware package ready for upload since I needed one to > finish the QF packages, about 3 months ago as I remember it. It's at my apt > repo, alongside the (~1 month old) QF packages that depend on it. I'll look at these. Thanks to the flu - er, I mean ANTHRAX(!) - the only holiday I'm taking is a trip to the store for Theraflu and chicken soup, so I'll probably look tonight. -- Joseph Carter <[EMAIL PROTECTED]>No conceit in my family * wichert_ imagines master without a MTA wichert: ehm? that might hinder peformance of the BTS :p pgp80enk38v0B.pgp Description: PGP signature
Re: quake I for woody
Joseph Carter wrote: > > On Mon, Dec 31, 2001 at 07:02:43AM -0500, Jeff Teunissen wrote: > > > Jeff, unless I'm mistaken you've taken over maintainence of the > > > debian packaging of quakeforge and you have fairly current packaging > > > in the quakeforge-current tree in their cvs. I remember that when > > > knghtbrd decided to remove quakeforge packages from debian, it was > > > because of technical problems with the state of the quakeforge > > > codebase, and, it seemed to me, because of political type problems > > > as well. > > > > Yeah, I'm doing the Debian stuff, at least within QuakeForge. > > The stuff outside I have done. Back in March or so I designed a nice, > complex, and complete system for handling gamedata. It would work as > long as an engine using it had fs_* Cvars and config files. Unless of > course you did something unexpected in your config file, in which case > it puked. Too fancy, and it broke. Solution without a problem. Game data must keep its name, and both registered and unregistered Quake game data always has to be in id1. [snip] > I can actually do the necessary work to get the shareware thing done > next weekend (I'm going on holiday for a few days and won't have much > time for code..) As for the registered game installer, I've got > something written in perl for that already, but it's not much and it > comes with a big warning that perl is not a language I actually grok. I have had a quake-shareware package ready for upload since I needed one to finish the QF packages, about 3 months ago as I remember it. It's at my apt repo, alongside the (~1 month old) QF packages that depend on it. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: quake I for woody
On Mon, Dec 31, 2001 at 07:02:43AM -0500, Jeff Teunissen wrote: > > Jeff, unless I'm mistaken you've taken over maintainence of the debian > > packaging of quakeforge and you have fairly current packaging in the > > quakeforge-current tree in their cvs. I remember that when knghtbrd > > decided to remove quakeforge packages from debian, it was because of > > technical problems with the state of the quakeforge codebase, and, it > > seemed to me, because of political type problems as well. > > Yeah, I'm doing the Debian stuff, at least within QuakeForge. The stuff outside I have done. Back in March or so I designed a nice, complex, and complete system for handling gamedata. It would work as long as an engine using it had fs_* Cvars and config files. Unless of course you did something unexpected in your config file, in which case it puked. Too fancy, and it broke. Since most engines don't have all that, I've just written /etc/quake.conf which gets sourced into a shell script. Contains GAMENAME and SHAREDIR. My wrapper script also assumes BASEDIR exists, though for obvious reasons it's kinda a bad idea for either file to contain that. Twilight and QF would just +set the appropriate fs_thing. Another engine such as DarkPlaces or something similar would use -sharedir, -basedir, and -gamename. As I said before, this requires a five-minute patch job. As for putting the mess in main, someone commented recently that OpenQuartz was almost usable now and has gone through the effort to make sure they've actually got license to use everything they're using. I still wonder about that, so I'll take a look for myself before trying to package it, but if it actually is worth packaging it'd put the engines in main. I can actually do the necessary work to get the shareware thing done next weekend (I'm going on holiday for a few days and won't have much time for code..) As for the registered game installer, I've got something written in perl for that already, but it's not much and it comes with a big warning that perl is not a language I actually grok. -- Joseph Carter <[EMAIL PROTECTED]>Certified free software nut "Hey, I'm from this project called Debian... have you heard of it? Your name seems to be on a bunch of our stuff." pgpijUjiDLlIO.pgp Description: PGP signature
Re: quake I for woody
Joey Hess wrote: > > Jeff, unless I'm mistaken you've taken over maintainence of the debian > packaging of quakeforge and you have fairly current packaging in the > quakeforge-current tree in their cvs. I remember that when knghtbrd > decided to remove quakeforge packages from debian, it was because of > technical problems with the state of the quakeforge codebase, and, it > seemed to me, because of political type problems as well. Yeah, I'm doing the Debian stuff, at least within QuakeForge. There are two problems with the packages; the lack of menus, and the problems with handling default sound output. I could make the default null, but then most people will think that QuakeForge doesn't have sound. Last thing I did was use alternatives to provide a "default" sound plugin, which worked nicely, but then we did some nasty things to plugin symbols which allowed people to statically link all of them into the main executables. Runs faster, but you can't load a plugin with a different name any more. Looks like it's time for debconf, I suppose. > Years ago, I used to maintain those non-free, binary-only packages, and > I didn't pass on maintainence with the expectation that quake would be > removed from the archive entirely later down the line. I would rather > see those nasty old packages copied from hamm (or was it rexx) woody bo, I think. [snip] > [1] Which don't seem fully resolved to me; they're still merging > code and have not produced an easily usable game with nicities > like menus). But maybe it's usable and just hard to use, which > documentation can solve well enough. Not unusable, but arcane to someone who is new to Quake or isn't used to dealing without menus. e.g. new game: map start invert mouse: m_pitch "-0.022" normal mouse: m_pitch "0.022" > [2] Or main, if Ben insists. And yeah, if necessary, I'm volenteering, > though I'd not be able to give it the time it probably requires. I don't really think it could be in main at this point. -- | Jeff Teunissen -=- Pres., Dusk To Dawn Computing -=- deek @ d2dc.net | GPG: 1024D/9840105A 7102 808A 7733 C2F3 097B 161B 9222 DAB8 9840 105A | Core developer, The QuakeForge Projecthttp://www.quakeforge.net/ | Specializing in Debian GNU/Linux http://www.d2dc.net/~deek/
Re: quake I for woody
On Mon, Dec 31, 2001 at 01:12:25AM -0500, Joey Hess wrote: > Jeff, unless I'm mistaken you've taken over maintainence of the debian > packaging of quakeforge and you have fairly current packaging in the > quakeforge-current tree in their cvs. I remember that when knghtbrd > decided to remove quakeforge packages from debian, it was because of > technical problems with the state of the quakeforge codebase, and, it > seemed to me, because of political type problems as well. Somewhat. The old QuakeForge packages were genuinely broken and segfaulted on start for a number of people. I could have tried to track down the problem, but was not willing to do that given the work involved to patch up a dead codebase. If QuakeForge still has no menus nor dependencies/fallbacks for the dozens of libraries it uses, I maintain my opinion that it's not ready to package yet. Still, whether and what to package is not my call and I'll defer to Jeff's judgement of the state of readiness of the project. The library problem could be mitigated somewhat by using debconf to write out a global default config. The menus were removed ages ago under the pretense that they would be replaced soon - that mistake was mine, but the code should still contain comments containing "MENU" or similar. Putting that back the way it was should be a simple task. The existing packages were an odd mishmash of two seperate yet equally broken and incompatible ways to mate the engine with its data. Since then, both have become obsolete. All new versions of QuakeForge support a set of Cvars for defining the locations of gamedata and which game to use by default (which allows for shareware and full gamedata to be installed at the same time without hacks, along with any other full TC you like..) It's also worthwhile to point out that this system can be applied to any and every Quake engine in a matter of ten minutes. I've written a sort of annotated diff which passes for a "tutorial" in the Quake community on how to implement similar features in all engines. > I don't care about the politics, I just think that it is crazy that > several old releases of debian shipped with non-free quake, potato > released with a working set of quakeforge packages, and woody looks like > it's going to release without quake at all. Unless you have plans to > slip quakeforge debs into it RSN, that is. There are a few other engines for Linux in various stages of stability including the one Zephaniah Hull and I have been working on, but none of them have the combination of Linux, NetQuake and QuakeWorld, and software rendering in the same project. For that reason if for none other, I would like to see working QuakeForge packages in Debian. That's the point though, working packages. I've been asked about Project Twilight packages a few times, but I don't even want to consider that until 0.2 is released. We're close to that, but there's a couple of bug reports still and rushing to get packages in before freeze is why the old Debian QuakeForge packages were so bad in the first places. If it's not done in time for freeze, it's not. We are very close though, I can count the number of things to do before release on one hand. > Years ago, I used to maintain those non-free, binary-only packages, and > I didn't pass on maintainence with the expectation that quake would be > removed from the archive entirely later down the line. I would rather > see those nasty old packages copied from hamm (or was it rexx) woody > than see a woody release with no quake at all. I'd much rather see > quakeforge or some other quake code base in contrib[2]. > > Can we do something about this? Those nasty old packages (libc5) are not necessary as I had permission to distribute the glibc2 binaries which were made for Quake: The Offering for Linux. I could also fix up SDLQuake for SDL 1.2, OpenGL, and QW support if need be. That at least I can apply -sharedir and -gamename switches to so that nasty symlink trees are not needed. -- Joseph Carter <[EMAIL PROTECTED]> <-- That boy needs therapy "What is striking, however, is the general layout and integration of the system. Debian is a truly elegant Linux distribution; great care has been taken in the preparation of packages and their placement within the system. The sheer number of packages available is also impressive" pgpe4hdeWQP4x.pgp Description: PGP signature
quake I for woody
Jeff, unless I'm mistaken you've taken over maintainence of the debian packaging of quakeforge and you have fairly current packaging in the quakeforge-current tree in their cvs. I remember that when knghtbrd decided to remove quakeforge packages from debian, it was because of technical problems with the state of the quakeforge codebase, and, it seemed to me, because of political type problems as well. I don't care about the politics, I just think that it is crazy that several old releases of debian shipped with non-free quake, potato released with a working set of quakeforge packages, and woody looks like it's going to release without quake at all. Unless you have plans to slip quakeforge debs into it RSN, that is. Years ago, I used to maintain those non-free, binary-only packages, and I didn't pass on maintainence with the expectation that quake would be removed from the archive entirely later down the line. I would rather see those nasty old packages copied from hamm (or was it rexx) woody than see a woody release with no quake at all. I'd much rather see quakeforge or some other quake code base in contrib[2]. Can we do something about this? -- see shy jo, who hasn't played quake or doom in years [1] Which don't seem fully resolved to me; they're still merging code and have not produced an easily usable game with nicities like menus). But maybe it's usable and just hard to use, which documentation can solve well enough. [2] Or main, if Ben insists. And yeah, if necessary, I'm volenteering, though I'd not be able to give it the time it probably requires.
