I used the fix described in the link that superbutcherx provided, and that fixed the problem, but another one arose: During the first battle scenario, the game crashes when the enemy ship gets close to mine.

Good to hear the fix helped!
Does the crash occur every time you get close to the Ilwrath ship? Does it happen in every resolution or just 320x240? Or just 1280x960?

In the issues list (http://code.google.com/p/uqm-hd/issues/list), only open = non-solved issues&bugs are shown by default.

You can see also the already-fixed ones by selecting "all issues" from the search drop-box, and then clicking "search".

Good thing you spotted the strange Ur-Quan AI behavior. AI bugs have proved to be quite hard to track down and even harder to fix  .

Are you playing in 320x240 mode?
If so, then you are facing a known (and annoying) bug, which prevents you from entering planet orbit.

Switching to 1280x960 works. If you're unable to play in that high a resolution, you can try the fix described here:
http://code.google.com/p/uqm-hd/issues/detail?id=173&can=1&start=100

Hi!
I'm the UQM-HD lead programmer and I'm here to assure you: your savegames will be fine.

There might be a warning message stating that your old savegames are unnamed and might be corrupted. You don't have to worry about it.

showing the value of biologicals when picking them up. Or partially scavenged minerals' remainders staying on the planet surface. Or the monochrome white lightnings and earthquakes now having a proper fading to grey. Or nameable savegames. Or logging the QS-HS hole coordinates into the QS starmap. Or when exiting a system on autopilot, automatically exit facing in the correct direction in HS. Or asking the player's name when starting the game.
And I see nothing wrong in throwing in some extras like SC1-style ship info screens available in the supermelee menu.

I like all of these changes...in fact, I already have a couple of them (biodata values and autopilot direction correction) implemented in my own mod (ref http://forum.uqm.stack.nl/index.php?topic=5233.msg69264).

I actually got the idea for many of those changes from that very post of yours. Hope you don't mind!

Some of them we already had (the better mineral collection handling), some were inspired by UQM EE (the biodata value showing), but some were totally borrowed from your brilliant ideas (like the ship heading to the correct direction when leaving IP to HS, I think that's a great - and logical improvement).

Well, when I talk about taking it into your own hands, I don't mean to not accept volunteers. I mean to not expect volunteers, so that even if it takes longer, you'll still manage in that scenario. If you decide that you personally can't do it and it will never get done unless someone else volunteers, time might be wasted if you ever find yourself with time to take a stab at it.

Yep, that's perfectly reasonable line of thinking. It would be lovely to get volunteers, but we are not stopping to work waiting for someone to knock on the door.

Right now, for me, it''s pretty much either implement the working 640x480 mode (and fix bugs as they're discovered), or start the merging/branching work. I opt for the former.

when you guys do bug fixes, do you not test the update by building against the updated source? just curious.

Of course we do.
The problem is that I'm working on OSX and don't have a Windows computer handy at all, so I am unable to test my fixes against Windows-specific problems... the looks of which at least that pastebin output of yours seems to be. I recall that someone had similar problems when compiling on a certain version of MSVC, but I don't remember which version was the one that was giving problems.

What I don't do though, is test compiling the fixes against every possible config option every time (e.g. network on/off, joystick/on/off, opengl on/off, zip support on/off etc.), so sometimes bugs like the  'resFactorWasChanged' not being recognized slip through the cracks. Good catch, by the way.

That particular variable should have nothing to do with network support, but with the network support disabled, the library 'options.h' didn't make its way into restart.c, which causes this error. I've now added the library into restart.c in revision 972. Try again, but be warned - the supermelee stars look pretty darn ugly now - work in progress

No problem

How do you mean it doesn't work? Does the game run at all with the external monitor attached or does it just not go into fullscreen?

If it's just not running fullscreen, but starts, there are a couple of options you could do:
- The simplest way is to play in windowed mode and drag the window to the HD monitor. You can select the windowed mode from the game's start menu ->setup->graphics options->display.

-Another way is to make your laptop use only the external monitor. On OSX (which I'm using) one way to do it is: connecting the monitor to the laptop while it's running, then closing the laptop lid, then starting the game in fullscreen mode. Now, because you of course need keyboard for the game, you should open the lid. Now, on OSX, the game stays on the external monitor and doesn't switch back to the laptop monitor. But it might be different for Windows PCs though, dunno!

The original, non-HD version is there in the game! No need to revert to piracy. You just go to startmenu->setup->graphics options and select the 320x240 resolution.

Hi, Canter!

I'm the lead programmer of the Ur-Quan Masters HD mod (which I assume you're playing),
Unfortunately the current release is just an alpha version of the game, and thus it still works a bit wonkily.

Your monitor probably cannot display 960 pixels vertically (I assume your max resolution is 1366x768 or 1280x800). In that case there is currently no way to squeeze the game's 1280x960 resolution into your screen. You see, we haven't yet had time to add a proper downscaling algorithm into the game, which would allow the 1280x960 shrink to, say, 1024x768 without making it look like a horrible mess. So, the best option for now is to use an external monitor that supports e.g. 1920x1080 - or play the game in its original 320x240 mode (which admittedly defeats the purpose of playing the HD mod).

We are currently making a Beta release, which should be out in March or so. For Beta, we are gonna have a proper and working 640x480 version, so that might already be a small consolation. We're also looking for a way to implement a downscaling algorithm for the graphics so the players could fit the 1280x960 into any screen. But I'm not sure if we can get that working.

src/uqm/misc.c: In function `do_damage':
src/uqm/misc.c:211: error: `invincibility' undeclared (first use in this function)
src/uqm/misc.c:211: error: (Each undeclared identifier is reported only once
src/uqm/misc.c:211: error: for each function it appears in.)
make: *** [obj/release/src/uqm/misc.c.o] Error 1

doing it myself...not doing it well.

edit of frustration....
F@#%! Can I get a windows build of the latest code.

Dang! We added an "invincibility button" for debug builds to make it easier to playtest.

It seems I forgot to make the build work also when doing a release build, not just for debug builds. I made a fix for that just now (in SVN r969). See if it works now!

To be frank, relying on volunteers to come along is not very reliable. It's perfectly normal for projects to mostly be one-man shows; even entire operating systems remain like this in some cases. If you take the attitude that someone will need to volunteer for the UQM HD code to get merged with mainline UQM, either you'll get lucky, or it will never get done. The only way to be sure it will happen is to take it into your own hands somehow; either go past your comfort zone and do it yourself, or raise some funds to pay someone to do it.

Well, you could also look at it this way: Both Damon and I came aboard Cedric's P6014 as volunteers. As did Benjamin, Themistercat, Kwayne, Ariel and Chris to name a few. The whole UQM-HD project was spawned by P6014 in turn.

Cedric could have taken the attitude that he and his brother take the whole project into their own hands, doing everything on their own. Or then, they could have asked for talented people to come aboard to lend them a hand. I am fairly confident that by doing it on their own, we wouldn't have P6014 at all. Nor UQM-HD for that matter.

2) I am getting very proficient in tweaking the UQM code. However, I am not at all proficient in pulling code from a different tree, say vanilla UQM, and trying to match it with ours without breaking anything.
So it saddens me to see that there are a lot of people even in these forums who most probably would be by far more capable than me in managing a source code project - merging and branching changes between two source code trees... and yet very few of those people are willing to put in even an hour or two into something that would take me weeks to accomplish, and probably only hours for them to do. Talk is cheap, labor is priceless.
So until someone actually steps up to actually offer us some help, a fork this is.

I've been meaning to try and do some of this kind of thing sooner or later, in particular creating a branch of uqm-hd without all the extra added features which make merging with vanilla UQM problematic. One problem is that uqm-hd code is in SVN, which I'm not really all that familiar with (and is fairly bad at handling branching/merging in the first place). Sourceforge should make it quite easy to set up a DVCS mirror though.

Thanks, oldlaptop. I would really appreciate it. The problem seems to be that none of the active UQM-HD programmers (read: more or less the two of us) are SVN wizards :-p

If moving to Sourceforge will make the merging easier, I'm all for moving into it!

1) As the lead programmer, I've opted to go for Extended. There are several small annoyances in the vanilla game that I'm very happy to have fixed in UQM-HD.
Like:
showing the value of biologicals when picking them up. Or partially scavenged minerals' remainders staying on the planet surface. Or the monochrome white lightnings and earthquakes now having a proper fading to grey. Or nameable savegames. Or logging the QS-HS hole coordinates into the QS starmap. Or when exiting a system on autopilot, automatically exit facing in the correct direction in HS. Or asking the player's name when starting the game.
And I see nothing wrong in throwing in some extras like SC1-style ship info screens available in the supermelee menu.

2) I am getting very proficient in tweaking the UQM code. However, I am not at all proficient in pulling code from a different tree, say vanilla UQM, and trying to match it with ours without breaking anything.
So it saddens me to see that there are a lot of people even in these forums who most probably would be by far more capable than me in managing a source code project - merging and branching changes between two source code trees... and yet very few of those people are willing to put in even an hour or two into something that would take me weeks to accomplish, and probably only hours for them to do. Talk is cheap, labor is priceless.
So until someone actually steps up to actually offer us some help, a fork this is.

I too would also like to see this as an option in the main build. I don't see that it would be that difficult, once the bugs are ironed out and the non-HD-specific changes are removed. One additional graphics menu option I guess, plus the same commandline option. But far be it from me to judge - I think you've done great, and it's worthy of applause.

Me too. Trust me, I'd love to see my artwork in as many people's hands as possible.  But, it's a volunteer army.  If somebody doesn't feel like spending all those hours doing it, I can't make them.

So, if any other programmer would like to volunteer their time, I'd love it.

I'll make an alternative suggestion.  Even if you guys don't have the time/manpower to prep patches to the main tree, it would be a really good idea to branch the UQM-HD repository, so that you've got a vanilla version (where new changes related to the HD resolution would go) and a strawberry version (where any new changes unrelated to the HD resolution would go).  You could set up the strawberry version to always pull the vanilla changes, so it gets them all.  I suggest this because otherwise, the UQM-HD code base will probably continue to diverge from the core line, and we risk it turning into a full fork, which I don't think is in the best interests of the UQM community.

Hi, Elestan!

You are more than welcome to come aboard and help us implement either making the "strawberry" changes a new option tree into the setup menu - or branching the repository.

We are seriously understaffed on the programming side. Without additional workforce improvements like these are sadly pushed to "some time in the future".

Hi, Celyn.
This comes in quite-a-late, but hopefully it'll still help you.

The reason UQM builder can't find rez is that Apple in its wisdom shifts the developing tools and all the other important shit around in every damn UI update they make.

If you're running Xcode 4.5.x (maybe applicable to all Xcode 4 releases, dunno), the command line tools are not on your HD in /Developer/Tools/ folder anymore. They are now inside the Xcode .app, in /Applications/Xcode.app/Contents/Developer/usr/bin .

The UQM builder tries to locate Rez in /Developer/, so it needs to be told where the Rez resides nowadays.

To do this:
1.open /build/unix/config_proginfo_build and find the following line:
PROG_Rez_FILE="/Developer/Tools/Rez"

2. Change the line to PROG_Rez_FILE="/Applications/Xcode.app/Contents/Developer/usr/bin/Rez"

Try building again. It should find Rez now!