I think one thing that would help wth these objections is if when a caster is used or you run out of fuel, the nearest Melnorme responds. That way you don't need to go all THAT close.

A good idea, but I already implemented something else in that situation.  :-)

And damnit, Groombridge was supposed to be so out of the way it would hide an easter egg that few players would find on their own. This idea practically requires you to go there. Like I said, just tagging the rainbow worlds is fetch-questy enough.

Groombridge is not a Supergiant.

Well, there's Alpha Vulpeculae (not reasonable to expect a new player to always ally with the Orz), Alpha Apodis () which are in the territory of potential enemies (although not necessarily scary in the case of the Thraddash), and several others which are very far flung (I sure hope nothing good is stuck off in Alpha Aquilae, for instance). It would be good to have some sort of option (preprocessor #define maybe?) to disable potentially controversial features somehow.

It's worth noting that this is my personal mod, not the base game.  If you prefer the way the base game does it, then by all means, play the base game.  :-)

What I did was give each Melnorme a different selection of technologies and information (with a dozen or so new techs added); you need to visit them all to get everything.

Eh, dunno if I like that approach...

It's worked out well in testing.  The differences meant that instead every Melnorme being cookie-cutter identical, the players began looking forward to reaching each new Supergiant system, to see what new goodies they might find there.  I also made it so each Melnorme only had the information on the Races and Current Events in their vicinity.  This actually helped some players, because it meant that they were more likely to get information at a time and place where they could act on it.

Is there an ETA on your mod? I'm looking to play again but was wondering if I should hold off if you were going to release soon?

Go ahead and play; I still need to make artwork for the new technologies, and then send the whole thing through my playtesters for QA.

Will you document those tweaks as possible to implement them as addons or how to replicate them in the source code. Sounds cool none the less.

When I release the mod, it'll be under the GPL, of course.  I'll see about trying to repackage some of the tweaks independently, but it might not be for a while; work has me busy right now, and they pay more than UQM does.  :-)

Ooh, sounds interesting! What kind of mod is it?

It's a source mod on the current Subversion head.  Adding 17 new techs and making each Melnorme different are probably the biggest changes in it. 

Some of the new techs include:

• Hyperspace Sensors
• Stealth Drives
• Ion Shotguns
• Minelayers
• Cargo Transporters
• ...and a couple of secret techs that are obtained by means other than the Melnorme.

There's about 50 little tweaks as well, either to fix annoyances in the original, or to adjust balance a bit.  A few examples:

• Minerals don't get picked up if it will cause you to lose some of them.
• Biodata quantity is displayed when it's picked up.
• Planet impact damage is capped at about 12.
• When exiting a system on autopilot, automatically exit facing in the correct direction, regardless of your facing when you left the in-system screen.
• Planetary hazard readouts are color-coded so that dangerous levels are more obvious.
• Planet temperature displays the equivalent hazard number next to the actual temperature.
• In the shipyard, sale prices are parenthesized, and unaffordable items are priced in red instead of green.

There are two changes I'd be interested in seeing with the Melnorme, though. One is a different way of purchasing technology, rather than forcing a specific order on you; the simplest would be allowing you to choose whether you get the next lander upgrade or the next module.

There is something like this in my (unreleased, in testing) mod.  What I did was give each Melnorme a different selection of technologies and information (with a dozen or so new techs added); you need to visit them all to get everything.

IIRC, threading issues require the dump to be delayed until your next hyperspace transition.  Try hitting the debug key, and then leaving the star system.

Say, does anyone know how I could get a Project 6014-version of the Planetary Database? I'm assuming that it's an automated process largely based off of the game code, but I'm not awesome enough with C to be able to pull it off myself without pulling my hairs out a few times. Can anyone (Elestan?) enlighten me on this subject? It could make p6014-development a lot easier.

I can point you in the right direction, but I've got a bit too much going on right now to take it on myself.  Take a look at the file uqmdebug.c.  It's already got code in it to output a lot of the planetary data; I generated the database on the wiki by modding those routines to output CSV, and adding code to do a few more calculations.  To trigger the data dump, you need to run a debug version of UQM, enable the magic debug key, and configure uqmdebug.c to do the dump when the debug key is pressed.

I've just made some updates that allow users to pan and zoom the starmap, like on Google Maps.

I would suggest that when zooming, the size of the stars should remain constant, and just the distance between them should change.  That way, you can zoom into tightly packed star clusters like Vulpeculae to see the individual stars more easily.

(Star Control III) was made by totally different dudes and lacked the spirit, style, and buglessness of Star Control.

To be fair, SC2 had its share of bugs, including one that let you sell back non-existent landers to get infinite RU.  But it was unquestionably a far better game.

The changes to the core code are minimal, and I did my best to work with the existing buildsystem. But there were places where I had to add ifdefs (such as this awful awful hack). The full diff from 0.7.0 is here if you want to see it. If

It would probably make it easier to merge if you branched from the current SVN head (see instructions at http://wiki.uqm.stack.nl/The_Ur-Quan_Masters_Technical_FAQ#Where_do_I_get_the_game.3F).  For one thing, I added C++ support to the build system a couple of months ago, so our changes there are going to collide where they aren't identical.

That's what I was thinking about when writing bulletpoint #1, but I think it'll still be a nightmare to do. Not only is it probably just a pain in general (the timing stuff needs to be integrated witch each other, as will the graphics/sound/resource stuff), but Ambulant is written in C++ whereas UQM is written in C. I don't know how hard it is to combine C and C++ (my knowledge and experience with both C and C++ is rather limited), but I wouldn't be surprised if it turns out that it's not easy at all.

Heh...funny you should mention that.  For the last six months, I've been submitting patches to the core to make it possible to link C++ code to UQM.  It's getting pretty close at this point.

Combining C and C++ is actually not that hard; it's kind of like mixing American English and British English.  Mostly things are the same; you just have to be careful not to ask to bum a fag.

That still doesn't mean it'll be easy to integrate the two, of course, but when the other option is writing your own SMIL engine (or other animation player) from scratch, I think it may be the easier choice.

I think we have several options here:
1) Implement SMIL in p6014, either the entire thing or a small subset of it. UQMAnimationTool is dropped in favor of Limsee, but it'll be used to convert most data once to a format understandable by Limsee.
2) Use a SMIL-like file specification to define animations, but don't implement a full SMIL-player. We could use the current rendering/timing code but make it load the configuration from disk rather than having all that embedded in code. UQMAnimationTool is used for most/all animation work.
3) Use our own custom specification to define animation-files. UQMAnimationTool is used for most/all animation work.

There's another option:  Ambulant is LGPL licensed, so we could take the relevant library components of it, link them into p6014, and use them to do the animations, fixing bugs where necessary.  That'll still be a chunk of work, but it might be less than the other options.