The Ur-Quan Masters Discussion Forum

Hi, ever since I found the Z.F.P I always wanted the ship a little bit better, speed and it's weapon range-wise, but I can't find the folder that determines the values. Can anyone tell me what folder it is, and what program I should use to edit it?

Edit src/sc2code/ships/zoqfot/zoqfot.c in the source code (with your favourite text editor) and recompile (with e.g. GCC). See INSTALL in source package for exact compilation requirements.

Right, I've edited the properties but I can't find the INSTALL file anywhere, also GCC looks to be extremely confusing to use, any more help with this?

What OS, GCC variant and version of UQM are you using, exactly? The compilation instructions are in INSTALL, right in the root of the UQM source tree (module sc2 in CVS, directory uqm-0.5.0 in the official v0.5 sources).

If you're on Windows, try using the following instructions for compiling UQM with MinGW (http://koti.mbnet.fi/lonnberg/MinGWUQM.txt).

All that went waaay over my head, too many programs to install and not enough simple prompts :( I'm wondering if anyone can do it for me :/

Hey! Ship settings were in an external text file in the PC version. I know because I used it to increase the rate of fire of Terran missle cruisers. :)

Text file? In my copy, at least, the .SHP files were binary blobs. See here (http://starcontrol.classicgaming.gamespy.com/sc2shp/) for editors.

The lack of decent package management (and the open-source attitude of treating Windows as a second-class platform, making it one) makes setting up a decent compilation environment a total pain under Windows. As long as you don't need to produce Windows binaries for other people, using Linux is actually much easier in most cases; the entire purpose of a Linux distribution is to combine different open-source projects into a coherent, easily installed, whole.

Another typical Windows problem is that everything is wrapped in those pesky graphical user interfaces, making it almost impossible to write scripts to automate stuff.

Why do you think most of the UQM devs are using Linux (or Mac)? In SuSE Linux, the corresponding installation instructions are more like "Open the software installation tool in YaST, check the devel versions of the libraries mentioned in the requirements and hit OK" or "As root, execute 'yast2 -i xorg-x11-Mesa-devel gcc make pkgconfig SDL-devel SDL_image-devel libmikmod Mesa libvorbis-devel libogg-devel zlib-devel'". Gentoo users probably can't install a game without getting everything they need to modify it. ;)

In any case, I might as well look into putting together some sort of snapshot of the installed MinGW system. That could be tough; like most Windows programs, MinGW uses registry entries that are a bit hard to find and transfer.

Actually, I'm the only core team member who uses Linux as his primary platform. The others do use it, but still do most of their development on Windows (using MSVC). And I compile all my libs manually. :P
But I think it's not very useful to look at what the devs use, as setting up the compile environment is a one time thing (until you upgrade libs), regardless of the platform. For devs that's less of a problem than for those who just want to compile UQM once.

Edit: apparently McMartin's primary platform isn't Windows anymore these days either.

Probably not, as he's been happily committing stuff that breaks badly on Windows (seeking to arbitrary positions in a text stream is fine on Unix, where text and binary is the same, but is not required by ANSI C as far as I can tell).

Sure, setting up the compiler and libs is just a small problem if you intend to use it a lot, but it's still several hours of work for something that should be a five-minute exercise, and you have to repeat it whenever you upgrade libraries, compilers or whatever or want to work on a different machine.

Also, an active contributor to one project is quite likely (in my experience) to do the occasional recompile of something else with different requirements. Being able to set up everything you need to recompile almost any program you have with a few clicks/commands is, IMHO, very useful.

Actually, he doesn't do any seeks. It's uio that does the seeks, which is my code. He's using a workaround now, but I'm going to recode the relevant part of uio.

As for the C standard (ISO C'99, not ANSI C), it allows fseek()ing on binary files, as long as you only seek with offset 0, or with an offset acquired through ftell() with SEEK_SET.

My point was merely that he obviously isn't doing any testing on Windows, which would be natural if he were working under Windows.

As I commented in Bugzilla, I feel the "workaround" of using binary mode and explicitly adding newlines on Windows systems is a perfectly adequate way of handling the situation. Of course, if the goal of uio is to be a more flexible substitute for the standard I/O routines, I can see why you'd prefer to rewrite that instead.