Pages: 1 [2] 3
|
 |
|
Author
|
Topic: Where are the save files? (Read 9778 times)
|
Culture20
Enlightened
    
Offline
Posts: 917

Thraddash Flower Child
|
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).
|
|
« Last Edit: September 06, 2005, 05:25:29 am by Culture20 »
|
Logged
|
|
|
|
|
|
|
|
Novus
Enlightened
    
Offline
Gender: 
Posts: 1938

Fot or not?
|
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.
SHGetFolderPath is in a redistributable DLL, according to this and is compatible with any Windows 95 compatible system and recommended according to this. I'm not quite sure why you find it problematic, and using it ought to have prevented Arael's problem.
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.
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.
|
|
« Last Edit: September 07, 2005, 07:20:11 pm by Novus »
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
    
Offline
Posts: 2847
|
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.
SHGetFolderPath is in a redistributable DLL, according to this and is compatible with any Windows 95 compatible system and recommended according to this. I'm not quite sure why you find it problematic, and using it ought to have prevented Arael's problem. 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:
03:06 < fOSSiL> hmm, why was the SHGetFolderPath call removed? 03:07 <@Meep-Eep> VC6 users couldn't compile it. 03:08 < fOSSiL> bah, they prolly need platform sdk ;P 03:08 <@Meep-Eep> Some .lib file that they didn't have. It was more trouble then it was worth. It should work pretty well without it now though 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.
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. Sorry for not providing references to peer-reviewed journals!  I wasn't aware that POSIX mandated this; some old Unix systems apparently don't have $HOME set properly by default. I just remembered reading somewhere a few weeks ago about that, but I don't remember where. I should have checked this before posting. 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.
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. Indeed, thanks. It's fixed in CVS now. I'm not surprised noone ever run into this though.
|
|
|
Logged
|
“When Juffo-Wup is complete when at last there is no Void, no Non when the Creators return then we can finally rest.”
|
|
|
Novus
Enlightened
    
Offline
Gender: 
Posts: 1938

Fot or not?
|
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.
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.
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: 03:06 < fOSSiL> hmm, why was the SHGetFolderPath call removed? 03:07 <@Meep-Eep> VC6 users couldn't compile it. 03:08 < fOSSiL> bah, they prolly need platform sdk ;P 03:08 <@Meep-Eep> Some .lib file that they didn't have. It was more trouble then it was worth. It should work pretty well without it now though 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. 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.
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
    
Offline
Posts: 2847
|
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.
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. 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.
|
|
|
Logged
|
“When Juffo-Wup is complete when at last there is no Void, no Non when the Creators return then we can finally rest.”
|
|
|
Novus
Enlightened
    
Offline
Gender: 
Posts: 1938

Fot or not?
|
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.
|
|
|
Logged
|
|
|
|
|
|
pcalvin76
Guest
|
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
|
|
|
Logged
|
|
|
|
|
|
Pages: 1 [2] 3
|
|
|
|
|