Skip to main content
Welcome guest. | Register | Login | Post

Looking for utility to install and run gamefest demo files on Nix systems

22 replies [Last post]
Joined: 2007-09-10

I have what I think may be a useful project but which I many not find time to work on now. Even if I do, many can contribute to the project without putting in too much work. Anyway, maybe someone really likes this idea and will jump on it.

Build a download utility (a shell/perl/etc script most likely) that comes in various flavors to be used with the more popular distros.

The purpose will be to install or upgrade one or more of the gamefest games on the user's PC. With this task completed and/or verified, the utility procedes to download user specified demo files, if these are supported, into the proper folders so that they will be accessible to the user through the games' demo facilities. [This only applies to some games naturally.]

Along with the utility, documentation should explain the steps that the utility will take so that the user can make a judgement if to procede. The documentation would also explain how to access the demos.

If the demos can be run automatically by passing CLI parameters or environment variables along with an invocation of the game or if it can be done after modifying a configuration file (or through some other automated fashion) than a small script to accomplish this should also be provided.

This utility can ultimately become very polished and packaged (and maintained), but a crude version should not be too difficult to build and may be useful to current gamefest participants and visitors. Here is a bit of the logic I would try to code if I were doing a second draft of it. [**A first draft would be much cruder (and probably only work on my system).**]


Figure out what games are needed to be installed. The clues should come from the urls provided on the command line (or through some other means). Currently I know of .dem files for Nexuiz, but other games (like OA and others) may use similar facilities.

Query the platform. Try to find out if it looks like the games are installed. If not, what kind of (preferrably native) package management system is installed and are certain packages available. If this doesn't provide a way forward, test to see if various utilities exist with the aim to download source for a needed game (and/or game dependency) and then build the source.

To help with the above tasks, we can try to determine if we are using a known distro. Likely we'll then know what the package names necessary will be and how to get them installed. In this process, the script may find the need and may be able to fairly confidently ask the user to consider an update so that the proper packages would be accessible. If affirmative, then it can procede hopefully to the end without a hitch.

We could take advantage of internal lookup tables (eg, some arrays) so that once we know the system (eg, distro version X) we can guess at the best package management to attempt to find. Once there we may test for availability of packages (by name and version) and maybe even test for specific known good repos.

To test for a specific game (or for any other file really), we might query the package manager or else check the filesystem for specific files (name, size, and maybe hash or some other type of fingerprint). Some games may have a method to query for it without any obstructive side effects (eg, start with "dirpath/gameX --help | grep ...." assuming a suitable shell and proper grep exist).

If we could not confidently find and use a packaging application, access key packages, verify an installation worked, etc, then we try to go the tarball route. We make checks for a proper environment to build the game. We check for download utilities (we may check for the ability to download but this may be assumed unless it fails and ends the script). We try to get the needed utilities or dependencies and the game package. If all of this succeeds, we try and build and install. Along the way, we should let the user know what is going on and prompt before attempting some of the more intrusive options or to find out desired installation paths (defaulting to local dir).

At some point (either at the end or right before attempting build from source) we should provide the option to install platform neutral binaries (if these exist). Some people would prefer a binary before a source build. Others would prefer the exact opposite. Most that have a packaging system, however, would probably prefer to use that before either of the other cases.

The reason to document the steps clearly are so that the power user that may not be fluent with scripting can figure out if the script might damage the system or, should it fail, if it might be fixed through very simple minor changes. Damage" to the system can occur if you hack your system a lot. Maybe you move files around or have a very unorthodoxed setup for you package management or you think an installation from source may fail somehow or use the wrong libraries. A "simple fix" might be that you do have the game but have it under a different name, and rather than build from source, you can just create a symlink and re-run the utility.

A polished script would try to take as many odd scenarious into account. It would be very careful about creating any files. It would test for many files and do sanity checks on them. ETC. A polished utility would also provide a more elaborate and robust command line interface.


While the above is somewhat complex (unless you have experience doing it), a crude version can boil down to a few simple commands. And we can do a separate crude version for various popular distros. We can also have a crude version that installs pre-built platform neutral binaries.

Joined: 2006-03-28
I have to admit I haven't

I have to admit I haven't read the whole post (you always write so much, man) I have to say that it sounds interesting.

An interesting way to tackle this might be Kommander, that KDE Click'n'Play-tool to create "apps". Kommander, as far as I understand, actually just is a graphical wrapper for shell-scripts.
Detection could be done with which, for example. Paths for demos are something easy to find out and the download could be done by parsing the site.

Shouldn't be too hard to do. I never played with Kommander, except that once I made a mockup-GUI for a fake program we tried to convince somebody would exist (a complete collection of the Internet on 500 DVDs ;-) ).

But as said, Kommander might be an option.
Downside is that you also need it to run the "program", since it doesn't produce any stand-alone binaries.

Joined: 2007-09-10
>> An interesting way to

>> An interesting way to tackle this might be Kommander

I had heard of it and I believe I played with it some time ago but am otherwise not very familiar with it.

>> I have to admit I haven't read the whole post

That's alright. Most of it is sort of technical in the sense that if your mind is not on the subject it's not worth reading. I don't know if I went too low level or not.

>> a complete collection of the Internet on 500 DVDs


>> Downside is that you also need it to run the "program", since it doesn't produce any stand-alone binaries.

That may be a significant downside since it probably won't be installed on most machines (I'm guessing)


If I get motivated I may write up and post a script composed of simple CLI commands that may work on more than just my machine Smiling

If I get really motivated ....

Joined: 2006-03-28
I just started working on

I just started working on something.

I decided not to go for Kommander but instead I use KDevelop in order to build a nice, little KDE/QT-tool.
So far I can find the games Nexuiz, OpenArena and Tremulous (as long as their binaries are in /usr/bin, as is the case in Fedora, and probably other distros where the games are in the repositories) and I can find the local demos for Nexuiz (just implemented, the others follow quite soon).
Next thing I will do is how to connect to the website and get the necessary strings in order to display a list of demos avaiable online.

Edit: Now my tool can download the pages for the three games. Next step will be to find the links to the matches, the files and, if applicable, multiple pages.

So far it's going quite nicely, and I've really learned a few things today. I'm not that much of a C-guy anymore, and I have never programmed for KDE/QT. But now I know how to connect signals to slots, and how to use QHttp to retrieve a page. And since I have learned that signal-stuff I could even connect a progressbar to the download. :-)

Well, I think I'm gonna spend some more time on this tonight, and maybe then I'll upload a first version, in case anybody is interested.

Joined: 2007-09-10
Currently the website for

Currently the website for demos (at least for nexuiz) is broken. One can't access beyond page 1. Libervisco knows about it. If you need to test, just test on the first page only. [Hope you didn't pull all your hair out already.]

I'm working on a different sort of tool for the gamefest. Since it is javascript mostly (w/ a test html page), I'll try to post later on this week or next so people can test it out.

Don't be shy about posting if you want to discuss something or if you seek testers or someone to go over the code or extend it to other platforms or suggest more ideas, etc.

..and thanks for working a bit on this. I do hope someone comes up with something however simple, as I think it will help take the gamefest another (at least) little step forward.

Unless there is absolutely no need, I expect to work a bit on this later on (maybe I'll do something next week).

If you share code, maybe you'll want to consider making it GPLv3. [Personally, I would like to do something like "or later version" .. "that is published in the next 20 years" ... as a way to leave the licensing flexible but not completely open-ended.]

Joined: 2006-03-28
I could extend the

I could extend the functionality a bit last night. Now querying the first page works, and it can find the Nexuiz-demos that are listed there. "Downside" is that it doesn't support the demos in archives.

There's still some work to do, but so far it looks quite good. ;-)
I'll post something soon, so anybody who knows some C++ might look through the code. I'm sure it's far from good and secure, especially because my C-days are long behind me and I just go by what I know about coding in general and the documentation that comes with KDevelop.

But for now I think it's good that it works, at least the stuff that's implemented so far. Makes me quite happy.
As said before, this is my first real KDE-program. My first Linux-program was a virus-scanner for eMails based on LibClamAV, which also was quite an experience, but actually nothing compared to what I'm doing now.

Edit: Okay, here's a first version. It can detect the games, find local and remote demos and it can even download demos (but it doesn't store them yet).
Because things got messed up when downloads were done parallel I had to serialize the transfers. This means things will probably be a bit slower, but at least now all the files are shown.
The "Play Demo"-button so far doesn't do anything.
So far you still have to use the buttons "Scan for games" and "Scan for demos". I will try to have these run automatically. The game-scan should be done on startup, the game-scan when you select a game in the combobox.

Well, comments and suggestions are welcome.

Edit 2: I updated everything a bit. The result is that the code is a bit more confusing, but now it can also do more. ;-)
Nexuiz- and OpenArena-support should be complete now, except for scanning multiple pages of demos on the gamefest-website. DemoNizer (should sound like "demo nicer" ;-) ) can scan for local (Nexuiz and OpenArena) and remote (Nexuiz, OpenArena and Tremulous) demos, download and even play these demos (both for Nexuiz and OpenArena).

Edit 3: I did another update (but didn't upload this one). I cleaned up the code a bit, for example I resorted the functions, which really was necessary. Also I added a button to delete local demos.
Actually with this program we could do a lot of things. It would even be possible to use it to upload our demos to the gamefest-site. ;-) But that's something we might consider thinking about later. For now I think browsing, downloading, playing and deleting should be enough.
I have to admit that I'm a bit proud of myself, considering that, as mentioned, I'm neither a C-guy nor did KDE-/QT-stuff before. But I guess that if you've been programming in different languages for around 15 years it doesn't matter very much what you use, the basics are always the same, and with a good documentation it's easy to get where you want.

Edit 4: Okay, another update. This one includes the previous changes (the cleanup and the delete-function) and also offers the auto-scan when opening the program. Also now it checks if the game's demo-directory exists before downloading demos, and displays a nice warning if it's not there (and also doesn't download the file).

Edit 5 (the last one for now): And another update. This time it's mostly about Tremulous. It's also supported properly now, including playing the demo-files. Also I added the option to mark multiple files for download. These then will be downloaded one after another. That way the user saves the mouse-miles and some clicking. ;-)

Joined: 2007-09-10
I should have some more

I should have some more time to look at the code next week.

One thing I noticed (version .1 but .4 I think also) was that before instantiating the gui (and so far only) class, we run an initialization routine that tries to get information about the system. Then we instantiate the class with the proper parameters.. or rather (since this is C++), we instantiate the proper subclass.

The main things about the environment are to see if we can identify the exact distro and verify information about package management and the names of the packages. To this end, different classes (derived from base but with key differences adapted to particular checks) should manage testing for packages. The difference betwen all of these classes along the hierarchy boils down to overriding the methods that implement the functionality that is different within the routines that access and test for packages.

What I will try to do (if you don't beat me to it) is make your setup slightly more abstract in this and a few other ways so that I can readily test out on my system and add the classes that would work on my system. Probably the majority of the logic and the GUI should be the same.

I am trying to find time to work on some javascript now (a different project), but it's been a while since I use it. I am finding that it is taking just a little longer to move the code along than what I would like. On the other hand, I think I know what I want (the specification), so I should eventually be able to speed up.

Very nice by the way. You certainly got a lot done in a very short time. [I'll have to download X header files to finish the build process, so I haven't run it yet Sad ]


Joined: 2006-03-28
Feel free to tweak around

Feel free to tweak around as you like.
But maybe before you do I should upload the latest version of my code, which now also includes a button that just starts the game, without starting a demo. I thought this might also be a useful button.

Joined: 2007-09-10
>> which now also includes

>> which now also includes a button that just starts the game, without starting a demo. I thought this might also be a useful button.

You are building a Gamefest Control Center (TM) not a utility!

Maybe later we can build something to capture pieces of the demo into (eg) avi and store it or use it to make albums or wallpaper, etc. [I would like desktop "wallpaper" that was animated.] We might, for example, automatically have a small resolution avi made of the demo and have it start running. The user can stop it and move forw/back by frames to take a picture. The pic can automatically be placed in any of various places or incorporated as something else (eg, wallpaper). We start by supporting one distro (eg, a gamefest distro if we can agree what to base it on), and make a gamefest livecd while we are at it, but later we generalize this material so that it becomes a generic package that can be incorporated into many different types of distros.

Another interesting automation would be to allow for 1-click modifications to the games where the user's pics (3d models, sound files, text messages, hacks/mods/plugins, etc) are automatically placed into the game. [for reference: it's a thread with a few very long posts :zzz: (couldn't find an "embarrassed" smiley)]


Joined: 2007-09-10
>> Maybe later we can build

>> Maybe later we can build something to capture pieces of the demo into (eg) avi and store it or use it to make albums or wallpaper, etc. ...

What I would hope is that (eg) nexuiz would have an advanced cli interface/config files where we could programmatically have the app start up on a demo, perhaps from a certain point in time. Maybe even just specify the demo and time and have a high res snapshot be taken (instead of building the image by itself, it may require control over the screen to have the graphics card/mesa/etc, draw the image and then something else snapshot the x window). We'd get the demo and time from the little avi film run for the user. This way the user wouldn't have to change to the game app and then have to follow instructions that would vary depending on the game (eg, to take a snapshot).

If we can't do that, maybe we can eventually get some of these control center functions into nexuiz and other games (through a plugin perhaps). This way we might be able to have a command interface pop up during demo or game play where the user has extra features, eg, allow downloading demos from various "repos" like gamefest2007; and perform other interesting functions. It would also be nice to have more control over the demo (like moving to an earlier point). This would depend on the actual game having support and that is why I even suggested making a low quality avi clip to run for the user (it would be something that I think we could pull off with what currently exists).

Maybe kino/kdenlive/etc have libraries for processing that would be useful. Also, I think we should be able to automate the gimp or at least access its libraries so as to have a set of standard effects that we could apply to demo clips. An "effect" could be elaborate like take the first 7 seconds of the vid and turn it into its negative whenever a lightning strikes (based on a randomizer) and add thunder sound and a scary fading title.

For the more interesting ideas I think someone will have to approach the game communities since they could modify the code without a high learning curve to go through first.


I should mention that the sort of games the gamefest is promoting allows people with ideas (even non developers) to think up and possibly achieve some of these things. Proprietary is a dead end in a lot of ways. This gamefest is only the beginning of getting out the message about "freedomware" games.

Joined: 2006-03-28
Jose wrote:

You are building a Gamefest Control Center (TM) not a utility!

Well, the name GCC is taken already. ;-)

Jose wrote:

Maybe later we can build something to capture pieces of the demo into (eg) avi and store it or use it to make albums or wallpaper, etc.

Maybe something could be done here by using RecordMyDesktop for this.

What I actually think would be something cool would be a tool that gets the server-list from the website for the selecte game, does a quick ping to see the times, and then you can just click and run to start the game and connect to the selected server.
That's something that could make our gaming-live a lot easier I think!

Or maybe it wouldn't get the list from the site, but have a configurable list.

Joined: 2007-09-10
>> What I actually think

>> What I actually think would be something cool would be a tool that gets the server-list from the website for the selecte game,

I am working to unify as much of the data that is scattered across many threads into a central location: as javascript state data. The idea is to be able to access all sorts of information from one place.

I'll try to upload an html/js page once I have something that works. The first significant tool I expect to have is to view availabilities of players in an easy to compare fashion (a time line, one for each player chosen plus a resulting timeline with the intersection of availability). And I am taking time zones and some other things into account.

I'd also like a way to update the data from the web. Since I don't have access to the servers or know about the details of them (nor drupal), I'll implement everything in javascript and then spit out for the person doing the "updating" the modified javascript arrays. What the person does is to copy/paste it onto that same webpage. Then when you refresh the page or open it some other day, the new data is ready to go. This is a portable solution but not ideal in all cases. It means that I don't have to know much about how drupal is working, but it means that there is an extra manual step. Also, to integrate it with other things or save it to the database, we would have to... well, there are various things that can be done, and none of this is that complex.. when we get to that step.

Other things I want to be able to do are to show updates of point totals and what not. We only manually update data that is independent and then everything that depends on it is calculated.

Basically, we have this data. We can update it. We then should have options for many types of views into the data. Not only might a single webpage allow the user to view anything they want (in theory), but we can take advantage of the views generated to quickly build static html pages. Whenever we come up with a new view we'd like, we implement the javascript for it and then we have the new view without having to do any data entry that was already in the javascript/html "database". Also, I'll eventually try to make the page css friendly so that even html that is generated during runtime can look according to some prechosen set of guidelines.

Which brings me to your comment. The server information is something to be centralized.

So, you may want to keep an eye out for whatever I post up (I'll try to get something working quickly ... though Saturday, which is just starting in my time zone, is my super busy day .. and I will have to leave very soon).

libervisco, when things are functional and compatible with the website, can determine where to place this page or the contents of this page if that would improve the site. It might them make accessing demos and server info and scores and schedules, etc, much easier.

Keep this in mind as you design and hash out a detailed implementation.


PS: This mechanism would allow users to update information and then upload the new page or probably just post the changes to the arrays. In this way, the community can do work that now libervisco is probably doing without help. AND the data would be contained into the webpage where it can be checked for correctness. Then libervisco or any admin can themselves move the data over to the databases. It would be like kernel development where a lot of the work is done by the community but Linus serves as gatekeeper. It's easier to review others' supposedly correct work than to do everything by oneself. [I'm not implying that organizing and developing schedules and other similar items is equivalent to kernel development!]

As a simple example, the updating of points would be automatically available. Users would contribute views that might later make themselves available on the website. The data for these views would not have to be re-entered. Where original data needs to be entered, users could volunteer this themselves. Occasionally, users would find new data to be harvested and do this themselves and contribute the work. In all cases, nothing could be put on to either nuxified or the gamefest site without an admin doing it. But the admin would have much of the work done and tested and cleaned out by the community.

Anyone that doesn't exactly see what I am talking about may get a better idea once I post something, hopefully next week.

Well, gotta go.

Joined: 2006-03-28
Wouldn't it be easier to

Wouldn't it be easier to have a PHP-site doing this? With PHP you can easily query the sites, parse them and display the information.

Joined: 2006-03-28
Since I somehow have fun

Since I somehow have fun doing some C++ again after a few years I started another project, QEmuMan, which is supposed to make handling QEmu/KVM a bit easier.
A third project, the one mentioned above, to start a game and directly connect to a selected server will be started today.

Since I wanted to put the files and info somewhere I thought my website might be a good place.
The latest files can be found in the download-section, and I also created categories in the forum, in case there's some need for discussion.

Anyway, we can continue the discussion here, I just wanted to offer other people the chance to give feedback and ask questions directly where they can get the files.

Edit: I started GameKicker, the little tool that helps us connect to the servers we play on. The first version has a static serverlist, but hey, it's just the first version. When you select a game it displays the server-list, and when you click on a server it will ping it and display the times. That way selecting a server might get a bit easier.
Finally there are two buttons, one to just start the game and the other to connect to the selected server.

I think this tool can be really helpful throughout the tournament because it makes it a lot easier to connect to a specific server.

Joined: 2007-09-10
>> I think this tool can be

>> I think this tool can be really helpful throughout the tournament because it makes it a lot easier to connect to a specific server.

I'll take a look later, but pre-built binaries instead of configure-make might be a better option for most users.

Joined: 2006-03-28
I'll look into it. I've

I'll look into it.
I've seen that KDevelop has an option to build RPMs from your project. If that, for some reason, doesn't work, I guess I'll use checkinstall.

Joined: 2006-03-28
Sorry, couldn't build any

Sorry, couldn't build any binary-packages since neither the RPM-build-function of KDevelop nor CheckInstall did their job.

So I decided to just attach the binaries here. They are for i686 (or maybe just i386) and need the QT- and KDE-libraries.
When I come home tonight I can also build and attach binaries for x86_64.

You just should remove the extension .odt, which I had to add in order to be able to upload the files.

Edit, okay, I also attached binaries for X86_64 now.

Joined: 2007-09-10
>> So I decided to just

>> So I decided to just attach the binaries here.

I'll look at this project (demonizer at least) closer later on in the week. I tried to run the binary and got floating point exception.

Not sure what practical actions (or package) to suggest right now without doing some testing on my system first

libervisco's picture
Joined: 2006-05-04
Wow, I finally got around

Wow, I finally got around to this thread and looks like you guys started a whole Freedomware Gamefest software suit! So there is now a gamekicker and demonizer by reptiler and an auto-scheduling tool by Jose.

Even if it doesn't necessarily get to be officially used for the current ongoing gamefest this is a great base for the one that may be held in 2008. Awesome! Smiling

Let me know if anyone needs hosting support or any sort of help I can provide for incubating these projects.

That said, I tried running the binaries reptiler provided and it looks impressive what it is supposed to do, but I must be missing something. Demonizer, when scanning for demos, just shows everything in the current directory and nothing online. Maybe I need to pass an URL to it when starting? Gamekicker also has an empty window and an empty drop down, not sure how to add any games to "kick" there.

Anyway, kudos to you guys for doing this!


Joined: 2006-03-28
Problem might be with my

Problem might be with my tools that paths are hardcoded, mirroring where files are on my box. Later on there will be the possibility to setup that kind of stuff so that it's more flexible.

As for the online-check, this doesn't seem to work 100% yet, though I had some success with this already.

I'll see that I do some more work on this, especially on GameKicker, because it let me down last night too, surprisingly enough.

Joined: 2007-09-10
Putting all paths (and

Putting all paths (and anything else that might be too specific to a single distro or user setup) in a text configuration file would allow the binary to be shipped and to work once the configuration file was fixed. There would be no need to configure/make the application (as an option to those that would not want to take the build route).

An alternative would be to clearly label the header file where those changes would be made.

The first solution is possibly best for the end user. The second would be easier on the developer as there would be no need to read and interpret a configuration file.

Anyway, when I have time, I might work on this part of the tool since I still need to get it to work on my system. An initialization routine would pull everything out of the file (one time) and place it somewhere for the rest of the program to reference as normal vars.

There are more solutions, btw, but I think these are two that cover most needs (user oriented or dev oriented) without being too advanced.


Some parameters might be configurable through the tool (eg, check a box here or there, pick from a list of paths, type in the url, etc), but others are basic if they are required to get any of the application to run. Try to avoid the latter situation as much as possible. Also, it might be useful to build a version of the binary with some libs included (static) as a "last resort" binary.

Joined: 2007-09-10
KIAaze seems to have posted

KIAaze seems to have posted to the wrong place instead of here Smiling. There's work here for a long time at the rate ideas are popping up.

***** Quoting...
An IRC bot notifying you when somebody is online. (I couldn't find anything in xchat doing this.)

Even better would be a bot capable of storing all the match ups and sending a notification to all concerned players if they are all on IRC at the same time.

Here is a bot that shouldn't be too hard to modify to do this:

I already played around with it once and it's quite easy to use. It's written in python.

The idea would be for a GCC Smiling.

Maybe for the gamekicker component.

Joined: 2007-09-10
>> I'll look at this

>> I'll look at this project (demonizer at least) closer later on in the week.

I'll get back to this project. It is very useful to have a client to manage the games and tap into the tournament (data).

Currently, I am working on a javascript tool (works through the browser) to aid scheduling by showing availabilities.

Later we can work from that common data store (within javascript) by adding match results and any other data on a player or the tournament. The data will be maintained in a text file much as the one currently being designed to capture availability data .

Looking further into the future, all of this data will be captured into an xml file format. That file could be designed to hold any and all data related to this gamefest (even as much as the demos and forums if desired.. though probably (?) through references and not inlined). The file could then easily be integrated with ODF and plugins could be added to OO.o and other apps to manage this.

However, a client command center (the project of this forum) would likely exist and serve a very key role to augment anything not doable through other means (maybe the plugins would be derived from libraries from this project, eg, from demonizer). Really, I expect over time for this client to take over the role of the javascript pages. C++ is more efficient and this client has more that it will be able to do than a js on a webpage.

Looking further into the future, a liveDVD can include the games and demos. A command center can manage all of this.

For a liveCD, the command center would play the crucial role of installing everything necessary in a simple fashion (to bring on the functionality of a liveDVD and more).

I even see how with enough tools and interest, this gamefest2007 may never end but just go on and on with new tournaments (w/ fresh organizers of course Smiling ). In this case, the 2007 would represent the year it all began (vs the year it took place): The Neverending Gamefest [good movie ..the NE Story].

OK, this last dream is far fetched and not necessarily desirable, but crazier things have happened. At least in this case, it would be something different (to stand out) and sort of be in the spirit of FOSS of never really being ready or finished.. literally.

LOL, what a fun vision this was!

PS: The availability tool and maybe other tools can easily be abstracted to work for things besides gamefests and tournaments. This is one nice consequence of using a text file to "boot it up," ie, configure it. The current discussion on that project is at

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.