Created attachment 1001 [details]
win32 home path detection

Works for me.

(In reply to comment #0)
> I think this is going to be controversial since I know people are accustomed to
> having their config files in one place only, but here it is for debate.

I don't see a problem to be honest. They can still have their .cfg files in the base directories if they like, this just gives them a new option.

MSDN says: 

"Note  On older systems that require the redistributable SHFolder.dll, you must explicitly link to SHFolder.lib before you link to Shell32.lib."

Someone with Visual Studio will need to edit the msvc build system so that SHFolder.lib is explicitly  linked or this patch breaks pre-WinME compatability.  I've added -lshfolder to the mingw build and verified that it now works on win98se.

So, I just tried opening the ioq3 solution in VS 2005 at work. It wanted to convert the solution and projects to the latest version, which confuses me, since I thought whoever did the current MSVC support had used 2005.

Annnnyway. As a result I can't update it unless I also update the project files to this version too. I don't really care enough to maintain it or fend off the flames if this is the wrong thing to do, so I'm not really sure what action to take.

Some comments:

If I'm not mistaken, "Local Settings" is for things specific to the machine which you wouldn't move, like caches and temp files. "Application Data" is the place suitable for user data.

That said, there's another problem: that's not an easy to reach folder (either of them). Not at all. With the default XP settings, it won't even show. It would cause a lot of confusion to have a very hidden storage lost somewhere like that.

Some top-profile games (Prey comes to mind), including games piblished by Microsoft (Halo & Freelancer at least), use "My Documents\My Games", where "My Documents" is localized but "My Games" is not. They drop a folder there and store things inside. For example, Prey has it like this: "My Documents\My Games\PREY\base\savegames".

It's not a great way, but I believe it's better than hiding it deep in D&S.

(In reply to comment #6)
> Some comments:
> 
> If I'm not mistaken, "Local Settings" is for things specific to the machine
> which you wouldn't move, like caches and temp files. "Application Data" is the
> place suitable for user data.

I used CSIDL_LOCAL_APPDATA because it was specific to a machine.
 
My thought is that you would not want your auto-generated config file to be used on multiple machines.  This config has machine specific settings in it like graphics settings.  You would not want that to be used on every machine on your network if you were using Roaming Profiles.


> That said, there's another problem: that's not an easy to reach folder (either
> of them). Not at all. With the default XP settings, it won't even show. It
> would cause a lot of confusion to have a very hidden storage lost somewhere
> like that.

~/.q3a is "hidden" on UNIX platforms too.

 
> Some top-profile games (Prey comes to mind), including games piblished by
> Microsoft (Halo & Freelancer at least), use "My Documents\My Games", where "My
> Documents" is localized but "My Games" is not. They drop a folder there and
> store things inside. For example, Prey has it like this: "My Documents\My
> Games\PREY\base\savegames".
> 
> It's not a great way, but I believe it's better than hiding it deep in D&S.

It would make the directory more visible, but it would cause the same issue with roaming profiles.

Yes and no :)

1. q3config.cfg is "autogenerated", but it comes straight from default settings - it's not really that machine-specific unless the user changes the config
2. It stores meagninful user settings (key binds, player model & name)
3. There's this cvar called r_lastValidRenderer. If I'm not mistaken, if the graphic adapter doesn't match, the video-related cvars are reset (however, you don't want that to happen every time)

But you do have a point. The best way to handle this would be separating core renderer settings (r_mode, r_swapinterval, r_[depth|texture]bits, r_picmip...) from the rest of them.

I kinda liked how HL (pre-Steam) did it: the video driver and mode were stored in the regirtry and shared by all mods, and the .cfg files stored everything else.

*Perhaps* a cvar flag could be used for this. Flagged cvars go to CSIDL_LOCAL_APPDATA and aren't mod(fs_game)-specific, unflagged and binds go elsewhere.

Also, is there a toggle to disable all this behavior, in case you want it to behave like q3 1.32? I believe it's going to cause a lot of headaches otherwise - and you might want to have everything under one folder (for example, to have multiple, non-colliding installations)

I'm getting lots of complaints about this from my Tremulous backport builds.

There is no pretty way to turn toggle this behaviour at run time, but I could add a CVAR_ROM cvar like "win_singleUserMode".  The user could then start the game with the command line argument "+set win_singleUserMode 1" to disable adding the home dir to their search path.

Does this seem OK?

I vote you at least wait a while until people have had a chance to get used to it. (As you know) I'm not really a fan of adding blah_useOldBrokenStuff type cvars.

Who has been complaining anyway? Don't take Lava_Croft too seriously, in particular ;).

Timbo: Agreed. Windows users aren't used to a multi-user OS. That's why they complain. IMHO, we have an obligation to educate them, so no, I vote for keeping the homepath thing.

changeset 907 makes some changes to how this works.

CSIDL_APPDATA is used instead of CSIDL_LOCAL_APPDATA.  This allows the user dir
be part of a Roaming Profile.  The disadvantage is that it may cause trouble
since system specific settings will live there (e.g. r_mode, s_alDriver, etc).
However, the likelihood of this causing problems is outweighed by the advantages
of a Roaming config, plus the %APPDATA% env var provides easy access to this
directory.

Homepath detection is now disabled on single-user systems (win95, win98, winme)
since there is no user-specific directory.  The same directory 
("C:\Windows\Application Settings\") would be used no matter what the "login"
was.  IMO this would only cause unnecessary confusion with no real benefit. 
Plus the %APPDATA% env var does not work on these systems.

(In reply to comment #12)
> Homepath detection is now disabled on single-user systems (win95, win98, winme)
> since there is no user-specific directory.  The same directory 
> ("C:\Windows\Application Settings\") would be used no matter what the "login"
> was.  IMO this would only cause unnecessary confusion with no real benefit. 
> Plus the %APPDATA% env var does not work on these systems.

OK, it looks like this was a wrong assumption.  It does appear to be possible
to set up those systems to use user specific directories in:
  "C:\Windows\Profiles\%USERNAME%\Application Data\"

I'm reverting this one.

ChangeSet 909 uses dynmaic loading for improved win95/win98 compatability.

Fortunately this also removes the lame-o requirement of changing the build system to link shfolder.lib in at just the right place.  I'm not closing this bug since MSVC build system changes should not be required anymore.

I've tested this with the mingw32 build on winme, win98se, and win2k.

Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.

--ryan.