This is a long-standing bug in UQM's build system:

http://forum.uqm.stack.nl/index.php?topic=5853.0

You will also find a simple (ugly) patch to work around the issue in my Debian source packages.

(It would appear that my build environment a year ago had the old libmikmod present, and shouldn't have. I've just put corrected jessie binaries on the server. Incidentally, I only saw this because someone other than you happened to mention it on IRC. I'm happy to help you with my packages, and of course I want to fix any issues people find, but you have to ask.)

...I like the Thrad, they've got one of the best fighting ships...

As long as you're not in a hurry!

Twice in a month!

http://well-of-souls.com/outsider/outsider108.html

My understanding is that the .deb maintainer for UQM is still AWOL and there's no news about acquiring the managership for these packages.

As of now, the maintainer has failed to react to a failure to build from source, and the package avoided removal only because of a non-maintainer upload. I'm not sure exactly what a non-DD can do about the situation, but I'm starting to seriously consider beginning the process of declaring the uqm packages orphaned.

Man, we're moving at a breakneck pace here. Wonder how long it can last...

http://well-of-souls.com/outsider/outsider107.html

One of your programmers exported it to git already, all that's left is the hard part.

I love the silly grins on those Spemin near the bottom. "Slime pit ahead, captain!"

If DOSBox can be built on a given OS, UQM almost certainly can as well (very similar in terms of external dependencies). You're going to have to figure out how to build from source on your system anyway, if you want to modify the code. You can find source on the download page (http://sc2.sourceforge.net/downloads.php) and the current git tree on sourceforge (http://sourceforge.net/p/sc2/uqm/ci/master/tree/). I have a nasty feeling you'll find it a *lot* easier to use something other than ChromeOS as your platform for experimentation, though.

Or there's some form of solid oxidizer/fuel mixture formed as a combustion product in the afterburner! (Like soot, only flammable in the vacuum of space.) Easy to imagine those little puffs as clouds of flaming dust, isn't it?

Elvish Pillager's last release was based on UQM 0.6.2; you would need a working installation of that to start from.

Some time ago, however, I made a port of the Crazy Mod to current UQM git; if you can run the official Git snapshots (or if you can build UQM from source), you should be able to run it. Unfortunately, I never ported EP's changes to AI behavior; if the AI was wonky before, it's completely broken in my port.

I have been more or less maintaining some unofficial UQM packages for Debian for years now, you can find them
here, thread on this forum here. The Debian 8 amd64 binaries will most likely work for without issue, though you must also install at least the "base content" package (and I recommend installing all of the content packages). Unfortunately the maintainer of the "official" UQM packages in Debian seems to be missing; he did not respond to my mails when I first packaged the latest version four years or so ago, and a separate update has been sitting in the Debian bug tracker for years as well.

Note that (due to a bug in UQM's build system) UQM will not build cleanly from source on Debian 8 without modification; a patch is included in my source package. Details here.

You need these packages installed:

libsdl1.2-dev
libsdl-image1.2-dev
libsdl-mixer1.2-dev

This is wrong; please see the canonical list of dependencies in UQM's compiling documentation.

SC2 was huge as well, wasn't made by a big team either, buildt from scratch yet didn't take 10+ years to make it.

Building SC2 was the Creator's *day job* for a few years though. Furthermore, SC2 wasn't built from scratch either, there is at least some SC1 stuff in the UQM code to this day (besides obvious remnants, my personal suspicion is that most of melee dates back to SC1).

I actually have one more question:

I think UQM uses precise collision detection, so if the images are replaced with slightly different images, collisions will be slightly different.

So, if a netgame is attempted between two copies of UQM that use a different image for a ship, for example, does the host take control of the collision detection, or does this just result in an error?

It will pretend to work fine, until the two sides can't agree on a collision (at which time the game will be aborted with an OOS error).

Very interesting. I can reproduce this here (current testing/amd64) with current git, but not with v0.7.0, and not in my Ubuntu utopic VM. At first glance the error comes from the included liblua, but when working around that by using Debian's system liblua it hits a similar linker error elsewhere:

Code:

/usr/bin/ld.bfd.real: obj/release/src/uqm/setupmenu.c.o: undefined reference to symbol 'exp@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile.build:88: recipe for target 'uqm' failed
make: *** [uqm] Error 1

It trips over a different (yet very similar...) linker error somewhere *else* on a debug build. Very perplexing indeed.

[EDIT] McMartin helpfully pointed out in IRC that the linker probably wanted to see libm added to its command line. For now, you can do that by setting LDFLAGS to "-lm" like so:

Code:

LDFLAGS="-lm" ./build.sh uqm

Two weeks and no comments about the actual speech file?

*All* UQM data, including voice files, are under CC-BY-NC-SA - better?