The Ur-Quan Masters Discussion Forum

I want to move my saved game onto another computer but I don't know where the saved game files are located.  Could someone tell me where they are located?

Also from manual.txt


Though this is talking about keys.cfg, the save directory will be located here as well.

i cant find it in the Application Data folder

Which one did you check? Windows has a nasty habit of creating lots of different folders with the same name, and you're probably looking at the wrong one. Also make sure that you have hidden folders set to be visible in whatever tool you're using to browse the filesystem.

Press <WIN>+F, and enter 'keys.cfg' as the file to search.

Sage: did you copy that text manually? It says "key.cfg" while the manual.txt file that I have says "keys.cfg" (which is the correct one).

Storing Savegames in some Windows folders is something I hate about lots of commercial games.
That is a VERY annoying feature. Some people even made a patch to fix the savegame location of GTA: San Andreas. So I'm probably not the only one offended by this.
Please make an option to store all files in the games main folder. I don't see the sense in storing it anywhere else it just clutters your harddrive. For multiple users just create profiles in the game.
For Linux it might make sense to store stuff in the user's home directory. But please don't do so on Windows.

You do realise that some people actually like it the way it is? There are several very good reasons for saving to the user's home directory:

• Easier backups and transfers: if all of a user's files are in one place, you don't have to hunt all over the hard drive for them.
• Less security problems: each user's directory is private to them by default and they always have write access to it. This means that:

• You can have a game installed as Administrator/root and have it accessible to all users without them being able to interfere with each other or the game installation. Allowing users to create new files inside the game directory makes it harder to enforce disk quotas effectively and complicates separation of user data. You've obviously never had a evil co-user (e.g. a malicious sibling) overwrite or delete your save game files.
• This neatly fixes one of my pet peeves: having to run almost every major Windows game under the Sun as Administrator or equivalent (especially under XP Home).
• If you do things this way, chances of failing to save due to access restrictions are much smaller.

[li]This also fits in nicely with Microsoft's policy of hiding system directories such as Program Files (although this is admittedly done quite badly in Windows).[/li]
[li]Easier access to user data on networked machines with shared profiles: OK, this probably makes more sense on a university network (where you use whatever machine is available) than at home (which is where I assume most of you run UQM).[/li]
[li]Easier uninstall/installation change/upgrade/maintenance: if everything in the game directory belongs to the game, you can uninstall the game and reinstall it later or elsewhere without ever having to touch your saves.[/li]
[/list]

That said, the user's Application Data folder is just a little bit too hard to access in Windows (I don't see why it doesn't get a nice desktop shortcut). Perhaps My Documents would be a better place for save games; it has most of the advantages and no disadvantages I can perceive.

Saving to \WINDOWS\Application Data on a single-user system is just plain silly, I'll give you that. Consistent, but silly.


Making the save game directory user-selectable is not a big hassle. Changing the default directory would, however, create problems with upgrading users (which I suppose you could work around by checking for previous installations, but this is going to make things even messier). If you only care about where the saves are stored, you could add a setting to the existing configuration data that tells UQM where to find the saves.

By the way, I don't quite understand why you consider a normal separation of user and application files to be "clutter". I suppose this is mostly a result of being used to putting user files for a program in the program directory. The reasons I outlined above may help you understand why UQM is set up to behave as it does.

Well said. I'd like to add that this is the way Windows is moving to. The user's Application Data folder is meant exactly for this. Expect a lot more software to do it this way in the future.
You may also want to read this thread (http://uqm.stack.nl/forum/index.php?topic=1882.0).
And if you really want another location for the save games (and config files), you can supply '--configdir=C:\bla' to uqm.exe. The option is there. I just advice you not to use it.

"--configdir" yes, that's it :)
Thanks...

Perhaps I explain a bit further:
Have you ever installed Dragon Naturally Speaking? It is consistent with Microsoft's recommendations and does the following:
Install about 550 MB of dictionaries and to "All Users" profile
Create all User's files under a All Users\Application Data\...\...\Myuser Directory -> Stupid
My WinXP Partition is a 1.7 GB NTFS Volume... There's no space for that...
The Installer is so stupid that I can't even specifiy the path where I want my files. I have to edit my registry to get the app to install.

I like to play my games on different OSes. I played Freelancer in Win98, when I want to load a game in WinXP there are no savegames until I copy them over from the "my documents" folder... copying them back: NTFS and Win98 -> no go! annoying.
You're right it might be easier to back up your savegames (if more developers did that). But might also cause confusion (like these forum topics here)

All stuff should be in one place. no installer, no uninstaller. Just unzip and be happy. non administrators won't have trouble with the installer. and if you don't want anyone touching your files, unzip/unrar/unpack to your home directory.

The way Linux handles multiple users makes a lot more sense. In windows it still is like Win3.11 having your INI files all over the Windows directory. At least with 98/XP you can set the folders in the registry.
Just my two cents :)

I haven't. But just because one program does silly things, doesn't mean the concept itself is flawed.

It looks like you're not quite a standard user. Anyhow, I'm only willing to take backwards compatibility so far. Requiring that the game runs on Win98, OK. Binary compatibility between saved games on platforms, OK. But requiring the file structure layout of an old system so that people who use multiple versions at once have can run without copying goes too far.
Btw, aren't shortcuts usable for this? I know they're not quite like symbolic links.

Two topics since the start of the project. Not a big deal if you ask me. And the other one was because someone deleted his Windows folder and didn't check if there was anything worth keeping.

Even unzip is too difficult for some people. Anyhow, the game is runnable like that. But the saved games will be stored elsewhere. Anyhow, "All stuff should be in one place", I got it that you would like that. But I don't get why exactly.

And in XP you actually have some privilege seperation. They're getting there. Slowly, but they'll get there.

Apparently we like to organize our stuff differently...
That's fine, life would be boring if everyone liked the same thing :D

I'm afraid shotcuts (you mean lnk files?) won't do that since they need to be opened differently than normal files if a programmer wants to use them like symbolic lnks (for the Win explorer they work fine)

Actually I play games in Win98 (much faster for games on my Athlon 800, even runs GTA San Andreas although not supported) and do work in WinXP (a little more stable for networking) or Linux (have yet to try UQM there)

It's a shame that many people don't even know what the C before the ":" stands for... Too high dosages of usability seem to affect people's intellects ;) I would prescribe the use of C64 BASIC...  ;D

I'm happy that I can specify the path where I want my stuff. And other people might be happy when they have their's in their user profile. Perhaps I'm just a bit nostalgic when thinking about the 9MB of StarCon 2 still on the 1.6GB Harddrive of my P200 Deskpro and it's SAVEGAME.0x files (each taking about 2KB).

XP allows you to choose where user profiles are stored, doesn't it? I'd check this right now, but my work machine only has Linux.

If you have multiple PCs networked together, having savegames in the programs directory is just the best thing to do, IMHO... And in fact, I don't like the user directory either. It just feels too cluttered, and since I run a lot of my applications over the network....... You get the idea, I hope.. :)

Yes, but AFAIK only by modifying your registry, or maybe with TweakUI...

Editing registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ProfilesDirectory should do the trick, but it certainly isn't user friendly. Under Unix and related systems, moving a user's home directory is almost as easy as changing his password.

There seems to be some UI related to moving profiles in XP in Control Panel\System\Advanced\User Profiles, but this only appears to produce copies of the profile without affecting which profile is used. XP Pro probably has something in its management tools, but I don't have a copy of that.

Generally saved games for new MS games go into the "My Documents" directory.  I've got a Thief 3 folder in mydocs.  Halo goes a step further and creates a "My Games" directory under "My Documents".   'Application Data" is often used for program settings (so if the eventual UQM settings menu stores changes, that's where they'd be looked for first [or second for any good ol' days hold outs like myself; *sigh* multiuser system security ruins everything]). 

Granted, it's messy to have things this split up, but all the settings and saves would be in the profile, which is backed up by even the weakest of GUI backup programs (most just a front-end for xcopy).  GIMP and a few other GNU programs have started following linux standards in the windows world, and are putting .gimp (or .whatever) directories in the root of the user's profile (not the best solution due to those aforementioned stupid GUI backup progs that sometimes just backup mydocs, favorites & appdata... sometimes not even appdata and favorites).

I found my saves. Instead of the default(?)

C:\Tools\!!Win\Dane aplikacji\    (as I expected from this thread)

the savegames and configs were found in

E:\userdata\
(the game installed at E:\The Ur-Quan Masters\)

I'm running UQM 0.4.0 at Win98 PL.

Sounds like you have %APPDATA% set to E:\userdata\ for some reason.

Either that or neither %APPDATA% nor %USERPROFILE% is set. sc2code/libs/file/dirs.c clearly includes fallback code for this situation that uses ..\userdata as a fallback home directory.

I'm not entirely sure whether reading these environment variables is a recommended or reliable way to determine the application data and user profile directories. Reading $HOME on Unix is not a good idea, at least.

Hmm... the "..\userdata\" fallback was set that way because the game would chdir() to the content directory when I created the expandPath() function originally. I've removed that chdir() since, but didn't remember this fallback.
It should go to "userdata" in the current working dir now. (I'll fix this in CVS).
A lot of thought and discussion has gone into the decision to use %APPDATA% and %USERPROFILE% as fallbacks. It's the best we can do as it is the most portable way (within Windows versions) to get to these locations.
On *nix systems, it's much easier. Reading $HOME to determine the home dir definately the right way to go. It's guaranteed by POSIX to be set on login, while it can be overridden by users who know what they're doing (think live cds, usb sticks, etc). The only reason there is a fallback for getpwuid() at all is for some support of buggy programs (such as the MacOS launcher apparently, though I think that may be fixed by now).
Why did you say it is not a good idea in the first place? It may help if you argument claims in the future so your readers don't have to explicitely ask for them btw.

SHGetFolderPath is in a redistributable DLL, according to this (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch11b.asp) and is compatible with any Windows 95 compatible system and recommended according to this (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/apcompat/apcompat/locate_directories_using_the_application_programming_interface_not_hard_coded_paths.asp). I'm not quite sure why you find it problematic, and using it ought to have prevented Arael's problem.

Sorry for not providing references to peer-reviewed journals! ;) At the time of posting, I couldn't remember where I'd read that, but I figured it was common knowledge (big mistake). Two reasons: some old Unix systems apparently don't have $HOME set properly by default, so some people still seem to believe it is unreliable. And in some contexts (e.g. suid binaries), allowing the user to change his home directory is a security risk, not a feature. Although this doesn't seem to apply to UQM at first glance, some SDL drivers (e.g. svgalib, DGA) require root privileges and are often run as root. In UQM you could easily exploit this to, for example, read and write other users' save games and configuration (although --configdir already allows this).

However, you still seem to be using getpwuid wrong; getHomeDir in dirs.c is returning the user name, not the home directory, as far as I can tell. Of course, since SDL seems to break when I unset $HOME, I'm not sure it matters.

It's been a long while since I looked at this, so I don't remember all the details. However, the #sc2 channel logs provided this bit:
There's been a lot more discussion before and after this, but this fragment pretty much summarises it.
The idea was that for those systems that don't have %APPDATA% or %USERPROFILE% it was acceptable to store the user data in the UQM program directory.

Well, after saying that <something> is a bad idea, the response 'why?' should be expected. Without an argumentation, the statement is worthless. I don't see any reason why a writer shouldn't add that argumentation in the first place, unless there's a reason to stall.

Indeed, thanks. It's fixed in CVS now. I'm not surprised noone ever run into this though.

For crying out loud, Meepy, I'm just trying to help! :( I'm aware that criticising someone's work without an explanation is unhelpful (and likely to be incorrect, too). I just don't always have time to write out well-thought-out essays and justifications for every single point I make, you know. I admit an explanation would have been justified here. To avoid any further unproductive discussion on this subject, I'll just state that you're right about this, my mistake, sorry.

OK, so the only real problem here was that the fallback to the UQM program directory was writing to "..\userdata" instead of "userdata", and the reason for using the environment variables is that it removes a non-standard library dependency. I read the explanation in dirs.c to mean that SHGetFolderPath doesn't work on some Windows versions.

It's OK. Just let me explain my response. I don't mind being told I'm wrong. In fact I encourage criticism. But when you tell me I am wrong without telling me why, not only are you suggesting that it it obvious that I am wrong, but you also put me in the position of having to ask why it is obvious that I am wrong. And if I have to that deep in the defensive, I'd rather do it in such a way in which I end up on top. Hence my sharp response, for which I apologise.

Right... Trying to get this discussion back on track, may I suggest that the installation program would allow the user to choose where the configuration files are saved. The default could be ~/.uqm or %APPDATA%/uqm as before, but the user could easily override this while installing and get shortcuts that override the default without manually setting UQM command line arguments. I think that would make the "put everything in my UQM directory" brigade happy without even adding anything to UQM itself.

Brigade? I actually suspect this will help a handful of people, while making live more difficult for those of us who answer questions like "Where are my saved games". And the people who won't be able to find out about the command line switch (which could be in the setup menu in the future) are exactly the people whom you shouldn't ask during install where they want to have their config data put.

OK, more like a squad, then. :) Maybe changing the default directory to one that is easier to find (e.g. "My Documents\uqm") would be the best solution, then. Of course, that would mean that "Where are my saved games?" would invariably lead to the counter-question "Which version of UQM do you have?".

Another option is to have the installer put a shortcut to the UQM configuration directory somewhere easy to find (if we have a Start menu subfolder, I'd put it there), and leave the configuration where it is.

I read through the thread and no files were found on the C drive, even with hidden folders included. keys.cfg, application datd with any Rockstar files/folders...etc.
Any other place the saved games could be?

Paul

What version of Windows do you run?

(And UQM has nothing to do with Rockstar)

Grand Theft Starship! A group of inmates locked up for life on Vela Penitentiary, led by a man known only as Zelnick, bust out and grab a Precursor service vessel. Warping back to his 'hood, Zelnick finds the Ur-Quan gang has trashed the place and locked up all but a few of his homies. This is the start of a tale of crime of intergalactic proportions as Zelnick has to steal, murder and intimidate for his gang to regain its freedom and respect.

Nah... Zelnick would never do that. He's the hero. He doesn't steal. He was just... teaching the Thraddash about not being too trusting. Yeah, that's it. And the Mycon... well, they had it coming. And he doesn't murder either. The Evil  Ones are just in suspended animation.

LOL, great one :)

I haven't gotten it to work with the --configdir parameter, it just kept creating directories at random in the program directory and exited with an error like "could not change dir" or "unable to create". I think there is a "\" too much or missing in some part of the code, but I was too lazy to take a look at it.
I tried relative and absolute paths.
Without --configdir it also created the savegames in e:\userdata on my win98se. (I understand that was fixed in CVS)
I solved the "problem" by hex editing the EXE file and replacing "%appdata%\uqm" with ".\savegames" works like I want it to ever since :D

See bug 738 (http://uqm.stack.nl/cgi-bin/bugs/show_bug.cgi?id=738). The handling of -C/--configdir is broken, but you can work around it and I've written a patch that does the workaround inside the UQM code.