<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Source code</TITLE>
</HEAD>
<BODY>
<CENTER>
<A HREF="index.html">Home</A> |
<A HREF="rules.html">Rules</A> |
<A HREF="authors.html">Authors</A> |
<A HREF="mailinglists.html">Mailing lists</A> |
<A HREF="fanfic.html">Fanfic</A> |
<A HREF="options.html">Menus and hot keys</A> |
<A HREF="network.html">Network game</A> |
<A HREF="parameters.html">Command line parameters</A> |
<A HREF="platforms.html">Platform specific issues</A> |
<A HREF="userlevels.html">User levels</A> |
<A HREF="algorithm.html">Core algorithm</A> |
<A HREF="source.html">Source code</A> |
<A HREF="bugs.html">Bugs</A> |
<A HREF="todo.html">To do</A> |
<A HREF="wip.html">WIP</A> |
<A HREF="copying.html">Copying</A>
</CENTER>
<HR>
<CENTER><H1>Source code</H1></CENTER>
<HR>
<H2>General remarks</H2>
<H3>Modularity</H3>
<P>Liquid War 5 is basically a big C program. I've splitted
the source code in many small files for I do not like to
have to handle big monolithic sources, but this does not
mean Liquid War is very modular. In fact Liquid War 5
is quite bloated with global variables and other ugly
stuff 8-(</P>
<H3>Coding style</H3>
<P>To be honest, it's a big mess. You won't find 2 files
coded in the same maner... OK, I'm exagerating a bit.
From now I try to make an effort and
stick to basic rules such as:</P>
<UL><LI>use the GNUish-style indentation - the default Emacs mode in fact</LI>
<LI>prefix global functions / variables / constants / types with
lw_<NAME_OF_THE_file>_. For instance, a "do_it" function
in myfile.c will be called lw_myfile_do_it</LI>
<LI>use capitals for constants, globals and types only. All functions
are in lowercase with "_" to separate words</LI>
<LI>keep on using 8.3 filenames for .c source files. This is for
better DOS integration. DOS version of Liquid War is still
maintained, you know 8-)</LI>
<LI>use English only for code and comments</LI>
</UL>
<P>I might decide to rename and cleanup everything some day, for
it would help other coders to understand what I wrote, but well,
this is certainly not a thrilling task 8-/</P>
<HR>
<H2>Source files organization</H2>
<H3>Main game code</H3>
<P>Here you'll find the main() function, the main game
loop, application-wide constants and other global stuff.</P>
<P>It might be a good start if you want to hack the code.</P>
<UL><LI>base.h:
contains global constants used in many different files.</LI>
<LI>game.c / game.h:
contains the main game loop.</LI>
<LI>main.c / main.h:
the file where the main C function is declared.
Doesn't contain much except calling init functions and
running the GUI.</LI>
</UL>
<H3>Menus</H3>
<P>The menus are coded using the Allegro GUI system.
While this system is very powerfull, it's IMHO not adapted to
very complex GUIs, and one of its drawbacks is that it's not
so easy to redesign something once you've coded it.</P>
<P>Besides, when I started coding the GUI in 1998, I did it
in a rather ugly way, and now I'm paying for my being lazy
at that time, since I spent hours coding when I want to
change something 8-/</P>
<UL><LI>about.c / about.h:
contains the code for the about menu.</LI>
<LI>advanced.c / advanced.h:
contains the GUI advanced options menu.</LI>
<LI>connect.c / connect.h:
contains code for the "connect" menu which displays which players
are connected to the server, before the game actually starts.</LI>
<LI>controls.c / controls.h:
contains the code for the controls menu.</LI>
<LI>graphics.c / graphics.h:
code for the graphic options menu.</LI>
<LI>internet.c / internet.h:
contains the code for the "Search for Internet games" menu, where one
can pick up a running server automatically with the help of the meta-server.</LI>
<LI>language.c / language.h:
contains the code for the "Language" menu.</LI>
<LI>level.c / level.h:
contains code for the menu where the player
can select a level and its options (texture or color).</LI>
<LI>menu.c / menu.h:
contains the code for the main menu.</LI>
<LI>netgame.c / netgame.h:
contains the code for the net game menu.</LI>
<LI>options.c / options.h:
contains the code for the options menu.</LI>
<LI>play.c / play.h:
contains the code which ties the menu to the main gameloop.</LI>
<LI>rules.c / rules.h:
code for the rules menu.</LI>
<LI>score.c / score.h:
functions to display the scores at the end of the game.</LI>
<LI>speeds.c / speeds.h:
contains the code for the speeds menu.</LI>
<LI>team.c / team.h:
code for the team menu, where one choses which teams will play.</LI>
<LI>volume.c / volume.h:
code for the sound menu.</LI>
<LI>wave.c / wave.h:
code for the wave menu.</LI>
</UL>
<H3>GUI tools</H3>
<P>These files contain various utilities which are used
in the menus.</P>
<UL><LI>alleg2.c / alleg2.h:
contains some tweaked allegro functions. I wanted to use
bitmaps with sevral colors for my fonts, and change some
of the allegro default behavior. So rather than modifying
the allegro source code right in the library I copied
it in this file and then modified it.</LI>
<LI>back.c / back.h:
this modules displays the background image.</LI>
<LI>dialog.c / dialog.h:
contains code for standard dialog boxes.</LI>
<LI>error.c / error.h:
contains functions to display error messages once the game
is in graphical mode.</LI>
<LI>help.c / help.h:
generic functions to display the various help pages.</LI>
</UL>
<H3>Core algorithm</H3>
<P>Here's *the* interesting part.
All the rest of the code is just sugar coat to display stuff,
receive players commands, communicate with other computers,
handle errors, etc... But the real thing is here!</P>
<P>It's funny to note that these files have almost not been
modified since Liquid War 5.0.</P>
<P>It's also interesting to note that they represent a small
percentage of the total amount of code in the game.
This tends to prove - and I'm convinced of it - that game
programming does not only consists in having great ideas,
but also requires a lot of "dirty" and boring work.
Honestly, coding an option menu is as boring as
coding Liquid War algorithm is fun.</P>
<UL><LI>fighter.c / fighter.h:
contains code to move the armies, once the gradient has been calculated.</LI>
<LI>grad.c / grad.h:
this module calculates the gradient for each team.
One could say it's the "kernel" of the game,
since most of the CPU time is spent in this module
(except if you have a slow display...).</LI>
<LI>mesh.c / mesh.h:
contains code to set up a usable mesh with a map.
Mesh are re-calculated at each time a new game is started,
the reason for this being that meshes are *very* big so
it would not be reasonnable to save them directly on the HD.</LI>
<LI>monster.s / monster.h:
assembly functions to speed-up the game.
It's a replacement for some fighter.c functions.</LI>
<LI>spread.s / spread.h:
contains assembly replacements for some functions of grad.c.
These replacements do the same than the original ones from grad.c,
but faster. Could still be optimized.</LI>
</UL>
<H3>Moving cursors</H3>
<P>It looks like nothing, but moving a cursor and deciding where
it should go if there's a wall in front of it is not that easy,
especially if you want things to work nicely.</P>
<UL><LI>autoplay.c / autoplay.h:
contains the code for the computer AI.
This module simulates keypresses from the computer,
then the computer is handled as any other player.</LI>
<LI>move.c / move.h:
provides an API to move the cursors.</LI>
</UL>
<H3>User input</H3>
<P>Until 5.4.0, Liquid War did not have network support.
As it is designed to be multiplayer, one needed to have
several players on the same computer. The mouse also
needed to be handled in a special way since cursors
can *not* pass walls in Liquid War. Additionnally,
I wanted all input channels (keyboard mouse and joystick)
to be handled in a unified way.</P>
<P>This explains why there's so much code for user input,
when one would think at first sight that
"polling the keyboard is enough".</P>
<UL><LI>joystick.c / joystick.h:
contains code to support joystick input. It wraps joystick buttons
to virtual keyboard keys, so that joystick and keyboard behave
exactly the same.</LI>
<LI>keyboard.c / keyboard.h:
contains code to handle key presses.</LI>
<LI>mouse.c / mouse.h:
wraps the mouse movements to virtual keyboard keys.
This way the mouse can be used to control the players.</LI>
</UL>
<H3>Initialisations</H3>
<P>These files contain functions to intialize various game
components. 100% boring code.</P>
<UL><LI>area.c / area.h:
contains functions to create the game area.
Basically it contains functions to create
the data structures in which the level is
stored during the game.</LI>
<LI>army.c / army.h:
functions to create the armies, and place them on the
battlefield.</LI>
<LI>asm.c / asm.h:
various constants, macros and utilities to
ensure that asembly code works correctly.</LI>
<LI>bigdata.c / bigdata.h:
I had a really hard time with the malloc function with DJGPP
under Win95 dos box. I tried to have it working for hours and
hours but my program kept being buggy. So I decided to allocate
the memory myself, in a memory zone I create at startup.
This is what this module does: create a huge memory zone
and then give parts of it to the rest of the program.</LI>
<LI>config.c / config.h:
contains everything that is related to the game configuration.
This module contains in global variables all the parameters
that are stored in the config file.</LI>
<LI>cursor.c / cursor.h:
contains the code to init the cursors and place them
on the battlefield at the beginning of the game.</LI>
<LI>decal.c / decal.h:
This module makes the link between teams and players.
Its coding is quite ugly, for some modules in LW assume
that when 2 teams are playing they are always teams 0 and 1.
So when 3 teams are playing are playing and the second team loses,
one has to make team 2 become team 1.
That's what this module is for.</LI>
<LI>exit.c / exit.h:
contains code that is executed when the game ends,
it shuts down Allegro and displays messages on the console.</LI>
<LI>gfxmode.c / gfxmode.h:
contains code to set up the various video modes,
and defines which modes are available for each platform.</LI>
<LI>init.c / init.h:
contains code to initialize Allegro with proper options and analyze failures.</LI>
<LI>palette.c / palette.h:
contains function to set up the current color palette.
Liquid War uses different palettes, depending on what
colors are chosen for teams.</LI>
</UL>
<H3>Graphics</H3>
<P>Here lies most of the graphic functions in Liquid War.
There's not that much code since Liquid War's strength
is not its visual effects, but rather its gameplay.</P>
<P>The only "funny" thing is the wave effect. I'm quite
happy with it, and honestly, I do think it is rather fast,
given the fact that it uses no 3D hardware at all.</P>
<UL><LI>disp.c / disp.h:
contains functions to display the battlefield.</LI>
<LI>distor.c / distor.h:
this module contains code to create the "wave effect".
It uses a lot of data tables, and is quite complicated
to understand...</LI>
<LI>glouglou.s / glouglou.h:
assembly module, it is a replacement for some functions of distor.c.
It goes much faster but does the same.</LI>
<LI>info.c / info.h:
contains code to display the info bar.
The info bar is the bar which display the time left and the amount of players
for each team while the game is running.</LI>
<LI>message.c / message.h:
provides an API to display messages during the game.
Very useful if you want to debug the game: you can trace
and display anything.</LI>
<LI>pion.c / pion.h:
contains code to display the cursors.</LI>
<LI>viewport.c / vieport.h:
code to allocate and resize the zone where the map is
displayed, also called "viewport".</LI>
</UL>
<H3>Sound and music</H3>
<P>Sound and music routines required some encapsulation,
since the game must be able to run even if the sound and/or
music did not load correctly.</P>
<UL><LI>music.c / music.h:
contains the code to control MIDI playback.</LI>
<LI>sound.c / sound.h:
functions to play sound.</LI>
</UL>
<H3>Data management</H3>
<P>These functions handle the datafile contents and
also the custom data.</P>
<P>Note that the various utilities such as liquidwarcol,
liquidwarmap and liquidwartex do not share code with
the main executable. This is obviously a design error,
for liquidwarmap will handle maps in a very poor
way and is unable to autodetect map errors, whereas
the game does it rather well. Blame the programmer.</P>
<UL><LI>disk.c / disk.h:
contains all the code to access data from the hard drive.
In fact, all the HD access is done at startup.</LI>
<LI>map.c / map.h:
contains code to load the maps from a datafile raw data
or a user defined bitmap
to a usable structure in RAM.</LI>
<LI>maptex.c / maptex.h:
contains code to handle the "use default texture"
option, and associate a map with a given texture
automatically.</LI>
<LI>texture.c / texture.h:
contains code to handle textures.
Textures are stored in a special format which uses
5 bits per pixel.</LI>
</UL>
<H3>Random map generator</H3>
<P>Liquid War has a "generate random map" feature which is
available within the game and also as an external program.
The source code for the external program is in ./utils/lwmapgen
in Liquid War source distribution. This program has been
coded by David Redick, is also available on
<A HREF="http://www.cs.clemson.edu/~dredick/lwmapgen/">www.cs.clemson.edu/~dredick/lwmapgen/</A>
and works on GNU/Linux. Compiling this program under DOS
and/or Windows is untested and unsupported.</P>
<P>The random map generator within Liquid War - which of course
works on any platform support by LW - uses for its greater
part the same source code as the external lwmapgen program.</P>
<UL><LI>random.c / random.h:
wrapper for the map generator written by David Redick.
It basically does the same as ./utils/lwmapgen/main.c
except that it does it within Liquid War as it is running
and not in an external independant program.</LI>
</UL>
<H3>Time handling</H3>
<P>Time handling is fundamental in a game. Time is used for
visual effects (waves...) during the game, it's used to generate
some pseudo random stuff, well, it's used everywhere!</P>
<P>Note that on the client, I use 2 "different" clocks. The first
counts the "real" time, in seconds. The second one is counts "rounds"
and is incremented by 1 at each game round.</P>
<UL><LI>srvtime.c / srvtime.h:
code used to handle time on the server, where Allegro's functions
are not available.</LI>
<LI>ticker.c / ticker.h:
sets up a timer callback.</LI>
<LI>time.c / time.h:
functions to know how long the game has been running,
knowing that it can be interrupted.</LI>
</UL>
<H3>In-game utilities</H3>
<P>These are various utilities use to monitor and control
the game while one's playing.</P>
<UL><LI>capture.c / capture.h:
code used to capture the video output of the game and store it
in .bmp files while playing.</LI>
<LI>checksum.c / checksum.h:
utilities to generate a checksum from a given game state.
Used in network code to make sure all the clients stay
synchronized.</LI>
<LI>code.c / code.h:
This file contains the code to handle key presses during
the game. That's to say the pause key for instance.</LI>
<LI>profile.c / profile.h:
provides tools to calculate how fast the game is runnning
and what operations slow it down.</LI>
<LI>watchdog.c / watchdog.h:
this module waits for "secret codes" to be typed while
the game is running, and traps them.</LI>
</UL>
<H3>Command line handling</H3>
<P>OK, now to all the UNIX guys, I *know* there are many
ways to do things in a better and simple way than I did.
But keep in mind that in 1998, under DOS, I had a rotten command
line and even now I need everything to work on both UNIX and
Microsoft platforms.</P>
<P>These utilities are not perfect, but they work, that's all
I ask them.</P>
<UL><LI>basicopt.c / basicopt.h:
handles basic command line parameters such as "-v" or "-h".</LI>
<LI>parser.c / parser.h:
contains code to parse and analyze the command line parameters.</LI>
<LI>startup.c / startup.h:
analyzes the command line parameters and stores them
into global variables.</LI>
</UL>
<H3>Locale support</H3>
<P>Liquid War now has locale support. Basically, all the
labels and texts in the UI are stored in constants.
There's simply file per language.</P>
<P>Note to translators: if you decide to translate the
menus in another language, keep in mind that all the
translations must fit in the various buttons and textboxes.
The best resolution to test this
- the one where letters take most place - is 640x480.</P>
<UL><LI>lang.c / lang.h:
contains code to handle language dependant stuff.</LI>
<LI>langen.c / langen.h:
contains code to handle English specific stuff.</LI>
<LI>langfr.c / langfr.h:
contains code to handle French specific stuff.</LI>
</UL>
<H3>Log and various messages</H3>
<P>OK, the API of the log routines is a piece of crap.
Now I'm simply too lazy to change it. It works, that's
all I ask.</P>
<P>BTW, there's a clear advantage in using custom-made
log functions instead of plain calls to "fprintf(stderr,...".
It might not be obvious for UNIX users, but think about
Windows. Nothing like a "tail -f" there, nor a proper
output redirection system. When a user clicks on the
Liquid War icon, I want "console" information to be logged
in a file!</P>
<UL><LI>log.h:
common header for logcli.c and logsrv.c.</LI>
<LI>logcli.c:
contains code to display messages on the console.
It's usefull for console may have different behaviors
when the games is used on different platforms.
This file is used to compile the client.</LI>
<LI>logsrv.c:
contains code to display messages on the console.
This file is used to compile the server, which does not
use Allegro at all.</LI>
<LI>popupgen.h:
common header for popup functions.</LI>
<LI>popupw32.c:
code to handle popup on the Win32 platform. Popups are a must-have
under Windows for error diagnostics, since the average Windows user
never gives any look at any log file...</LI>
</UL>
<H3>Macros, utilities and string support</H3>
<P>As usual, I needed to prepare a small set of usefull macros.</P>
<UL><LI>macro.h:
contains basic wrappers/macros for
snprintf like functions. This mostly to ease up string
manipulation which is - as always - a nightmare in standard C.</LI>
<LI>path.c / path.h:
code used to handle filenames and paths, for instance remove
path and file extension from a filename.</LI>
</UL>
<P>It's also important to note that Liquid War uses snprintf instead
of sprintf, for using the latter is very likely to cause buffer
overflows. Under Linux glibc provides this function but Microsoft
does not provide it natively on Windows. Therefore I used a
third party snprintf implementation by Mark Martinec:
<A HREF="http://www.ijs.si/software/snprintf/">www.ijs.si/software/snprintf/</A> and its source is available
in the ./utils directory of Liquid War source distribution.</P>
<H3>Byte order and endianess</H3>
<P>As you might know, PC Intel based computers are "little-endian"
while Sun Sparc stations and Mac computers are "big-endian".
This is an issue for LW since in network games maps are transmitted
in binary format. Therefore I needed to set up some
(un)serialization fonctions.</P>
<UL><LI>serial.c / serial.h:
code used to transform integers and map headers into an uniform
cross-platform byte stream which is readable by both little and
big endian machines.</LI>
</UL>
<H3>Thread support</H3>
<P>Liquid War does have thread support, but it is a "limited"
thread support. I mean that the game is generally monothreaded,
but a few functions use threads. For instance, calls to
the meta-server are done within threads.</P>
<P>Basically, I do not really enjoy programming in a multithreaded
environnement. So when possible, I chose the monothread path,
and used threads only where I simply would not be able to
find another acceptable solution.</P>
<P>I also needed to use some mutexes to prevent crashes in the
user interface.</P>
<UL><LI>mutxdos.c:
provides fake mutex support under DOS.
This module is here only to make compilation easier.</LI>
<LI>mutxgen.h:
header for mutxdos.c, mutxunix.c and mutxw32.c.</LI>
<LI>mutxunix.c:
provides mutex support on UNIX.</LI>
<LI>mutxw32.c:
provides mutex support on Win32.</LI>
<LI>thrddos.c:
provides fake thread support under DOS.
This module is here only to make compilation easier.</LI>
<LI>thrdgen.h:
header for thrddos.c, thrdunix.c and thrdw32.c.</LI>
<LI>thrdunix.c:
provides thread support on UNIX.</LI>
<LI>thrdw32.c:
provides thread support on Win32.</LI>
</UL>
<H3>Launching external programs</H3>
<P>Liquid War might sometimes launch external programs.
This is (for security reason) not a default behavior and has
to be activated and configured by yourself, using the "-callback"
command line option on the server for instance.</P>
<UL><LI>execgen.h:
header for execunix.c and execw32.c.</LI>
<LI>execunix.c:
code to launch external programs on UNIX.</LI>
<LI>execw32.c:
code to launch external programs on Win32.</LI>
<LI>exec2.c:
code to launch external programs within the client, without any
interaction with the user, ie no unwanted popping window for instance.</LI>
</UL>
<H3>Low-level network code</H3>
<P>There are network packages for Allegro, but I decided not to
use them. Socket support is not that hard to implement under UNIX
and Win32 and besides, I've done it for my job recently, so I just
knew how to do it.</P>
<P>Another reason which decided me to code my own toolbox is that
I did not want Liquid War to have external dependencies - except
Allegro of course. This way, UNIX gamers to not have to set up and/or
download a specific network library. It's also easier to integrate
the game in projects like Debian if it has few dependencies.</P>
<P>This network code is not a masterpiece, it's just a little set
of tools that have proven to work. That's all.</P>
<P>BTW, it's important to notice that when linking with Allegro,
most blocking UNIX calls ("sleep" or "recv" for instance) stop
working: they alwasys return immediately. This led me to
implement weird ugly hacks, like calling "recv" in a loop until
it gets what it wants... This is theorically and practically
a performance killer, but I found no other way to fix this.
And FYI, this is not an Allegro bug, it's a feature 8-)</P>
<UL><LI>dnsutil.c / dnsutil.h:
wrapper code to issue DNS requests, without having
to handle the hostent struct.</LI>
<LI>sock2cli.c:
sode used to wrap low-level network function on the client.</LI>
<LI>sock2gen.h:
header for sock2cli.c and sock2srv.c.</LI>
<LI>sock2srv.c:
code used to wrap low-level network function on the server.</LI>
<LI>sockdos.c:
network API for DOS.</LI>
<LI>sockex.c:
netowrk routines shared by sockunix and sockw32.</LI>
<LI>sockgen.h:
header for sockdos.c, sockunix.c and sockw32.c.</LI>
<LI>sockunix.c:
network API for UNIX.</LI>
<LI>sockw32.c:
network API for Win32.</LI>
</UL>
<H3>High-level network code</H3>
<P>These files contains network utilities
which are Liquid War specific.</P>
<UL><LI>chat.c / chat.h:
functions used to handle chat messages in network games.</LI>
<LI>keyexch.c / keyexch.h:
functions to send and receive keys to the server. Used on the
client.</LI>
<LI>netconf.c / netconf.h:
code to send and receive the config of the clients over the network.</LI>
<LI>netkey.c / netkey.h:
contains some tools to manipulate key strokes over the network.</LI>
<LI>netmap.c / netmap.h:
code to send and receive the maps over the network.</LI>
<LI>netmess.c / netmess.h:
contains a parser to interpret plain text messages. Used when
exhanging information over the network.</LI>
<LI>netplay.c / netplay.h:
contains the code to set up and start network games.</LI>
<LI>network.c / network.h:
contains some network related functions and constants used on
the client.</LI>
<LI>ping.c / ping.h:
code used on the client to estimate the average ping time
with a server.</LI>
<LI>protocol.c / protocol.h:
contains the sequence of messages send and recevied by the
client when connecting on the server.</LI>
<LI>startinf.c / startinf.h:
contains struct and tools to handle some network informations while
starting a network game.</LI>
</UL>
<H3>Communication with the meta-server</H3>
<P>The meta-server is called by both client and server.
Basically, the server registers itself, and the client
asks for a list of servers.</P>
<P>The meta-server itself is just a set of simple PHP scripts
with a simple MySQL database. I chose PHP because my
provider allows execution of PHP pages, that's all.</P>
<P>The protocol is *very* basic, and uses HTTP 1.0 for
requests. Answers are received in plain text, with
one information per line. There's no garantee that
this would work with any HTTP server, but experience
proved that it works with my provider 8-)</P>
<UL><LI>httputil.c / httputil.h:
low level functions to handle http requests.</LI>
<LI>wwwcli.c / wwwcli.h:
code used on the client to communicate with the meta-server.</LI>
<LI>wwwsrv.c / wwwsrv.h:
code used on the server to communicate with the meta-server.</LI>
</UL>
<H3>Server code</H3>
<P>The Liquid War server is a rather small program. The only
thing it does is accept new players, transmit map and
game parameters between them, and then "replicate keys".</P>
<P>By "replicate keys" I mean that the server asks each client
what keys have been pressed during the last round, and
then dispatches this informations to all clients.
This implies that the server has absolutely no idea of
who's loosing, who's winning, etc...</P>
<P>All the "logic" of the server is coded in these files,
the rest is only utilities and helper functions.</P>
<UL><LI>server.c / server.h:
main code for the server (equivalent of main.c for the client).</LI>
<LI>srvchan.c / srvchan.h:
code used to handles channels on the server. A channel is associated
to a given computer and may manage several teams.</LI>
<LI>srvcont.c / srvcont.h:
global network controler used on the server.</LI>
<LI>srvteam.c / srvteam.h:
code used to handle teams on the server.</LI>
</UL>
<HR>
<CENTER>
This documentation is also available on:
<A HREF="https://ufoot.org/liquidwar/v5">www.ufoot.org/liquidwar/v5</A>.
</CENTER>
</BODY>
</HTML>
distrib
>
Mageia
>
7
>
armv7hl
>
media
>
core-release
>
by-pkgid
>
71122bda0b4b260d19857d39144c7a22
>
files
>
26
