[twilight-devel] data file location

[Forest 'LordHavoc' Hale]

Joseph Carter wrote:
> On Sun, Feb 09, 2003 at 03:13:51AM -0800, Forest 'LordHavoc' Hale wrote:
> 
>>My thoughts on the matter:
>>Win32 - Use the working directory (all games I play do this, everyone 
>>knows their shortcuts have to be right, and everyone places executables 
>>in the game directory, so the shortcuts are by default created 
>>correctly, it's up to the user to mess them up manually, I've never 
>>known anyone to complain about this fact, it's the standard behavior of 
>>almost every windows application and game in existence), and preferably 
>>post an error window saying it can't find the quake data instead of the 
>>vague 'gfx.wad' one.
> 
> 
> While this will work in win32, it is different from Linux where the
> working directory is NEVER going to be suitable.  The goal was to make
> them do the same thing so that we don't need:

I see absolutely no sane reason to make them the same.

> Setting up Twilight
> -------------------
> 
>  For Windows
>  -----------
>  
>   1. 
>   2. 
>   3. 
>   4.
> 
>  For Linux
>  ---------
> 
>   1. 
>   2. 
>   3. 
>   4. 
>   5. 
>   6. 
>   7. 
>   8. 
>   9. 
>   10. 
>   11. 
>   12. 
>   13. 
>   14. 
>   15. 
> 
>  For MacOS X
>  -----------
> 
>   1.
>   2. 
>   3. 
>   4. 
>   5. 
>   6. 
> 

Nothing that complicated.  Also realize that packaged Linux versions 
won't ask anything (because their etc config already points to the right 
thing and thus it just starts up fine).

> I do not buy that Linux must be inherently more complex just because.  And
> in case the user's shortcut is screwy, it is still necessary for the thing
> to work sanely.  Again, I propose a cascade of tests beginning with an
> environment variable and ending with asking the OS where the data files
> should be.  I do not have the pseudocode in front of me now, but I can
> provide it upon request.

It is totally unreasonable to work with a broken shortcut, VERY few 
commercial games do!

It is completely expected behavior by ALL windows users that a broken 
shortcut will NOT work!  Trying to work with a broken shortcut is 
COMPLETE INSANITY!

Environment variable??  Why would someone have an environment variable 
set in the first place?  Many 'Linux gamers' don't even know what script 
to edit to make a permanent environment variable.  I don't even 
understand what you're proposing, it makes no sense.

I don't see asking the user ONE question *IF* they installed it manually 
(not using a package) AND are not running it from the data directory, to 
be in any way unreasonable.

>>Linux - Create a ~/.twilightconf or whatever.  If we can't find gfx.wad, 
>>check if the current directory works, if not ask the user where the data 
>>files are, store that path into the config if it is verified as working, 
>>if this ever stops working, it will ask again.
> 
> 
> Again, totally ignores reality.
> 
> 1. We have such a file already - 50/50 split between users who get it and
>    users who don't.
> 2. Currently we provide binaries only for win32.  It's clear that we need
>    to provide them for other systems.  What's clear to me is that when we
>    give instructions for the installation of these binary packages, they
>    need to be laid out exactly the same.  That means name of config files,
>    name of binaries, etc.  Currently Linux and Win32 are treated totally
>    differently.

Extract tarball to ~/, it makes a ~/twilight, place data into that 
directory (optionally by running an installer program that extracts it 
from the quake CD - we should probably have such a program on win32 as 
well).

How is that inconsistent?

> 3. The need to put all of Twilight in one place.  Darkplaces is done this
>    way currently, though would no longer be the moment autoconf were done.
>    We are not an OS vendor and we are not a typical local build.  We are a
>    third-party platform-insepecific package.  The canonical place to put
>    such a package in UNIX varies by platform, but the cardinal rule is
>    that you put it in one place and point binary symlinks in to it.
>    Debian would whine about this, so we have to allow them to do it
>    wrongly.  ;)
> 4. My proposal creates for the first time a solution that works the same
>    way on EVERY platform, without really defying any standard conventions
>    on any platform

My proposal works almost the same on every platform as well, the only 
exception is that on win32 it would not prompt the user for the quake 
directory when it fails to find the files, instead it would simply 
display a notice that it needs to be run in a quake directory.

> Interactively asking about config files would kinda suck for the server,
> which as soon as practical we have something to control it with reliably,
> will detach itself from the console like any standard daemon should.  In
> Win32, it will need to locate itself in the tray and be able to call up
> the control interface, but that's platform-specific.  MacOS X should do
> something similar, though that's less critical on a UNIX-based Mac.  ;)

Think about this for a moment, server is typically also in the data 
directory.  (Admins often have a whole set of games installed, and each 
is quite self contained, not scattered across the system)

>>I don't think profiles are necessary in light of the above.  It seems 
>>silly to have multiple profiles per Linux user. (I have seen games that 
>>do this of course, like Descent)
> 
> 
> Again, the point was to do one thing and do it always, regardless of
> whether or not the feature will be particularly useful on a given
> platform.  In theory, you probably have exactly one playing style for a
> given game, and you only need one profile.  In Linux you have it, stored
> probably in ~/.twilight, so what's the big deal?  Well, you don't have
> that in Win32.  Okay, maybe you do in WinXP, but we don't take advantage
> of that yet.  It's also possible that someone might want to back up a
> profile trivially while working on a new config setup.  Not our business
> why they'd want the feature, only that it's necessary in some situations
> on some platforms, and that we should necessarily ensure that if we take
> the time to write it once, everyone benefits.

Windows has profiles all the way back to win95.  Few games use them however.

I still want a config editor in the game. (and preferably the game 
should be able to launch with no data at all, just using an embedded 
font and some simplistic menus :)

I'm talking about a config editor able to edit 'profiles' as you might 
call them, but in the much broader sense.

Imagine if you could hit keys while playing TF to change roles, key 
binds, sensitivity, and even resolution, all this would involve is 
binding a key to "profile tf/sniper" or "profile tf/engineer".

These profiles would activate and deactivate other profiles when you 
switch, for example each tf profile would say it is in a 'set' called 
'tf', causing it to be the case that you could only have one active at a 
time, trying to activate another would automatically deactivate the old 
one. (note that you can have multiple groups active at once, so that you 
could switch movement config without switching weapon config, or whatever)

However 'tf' would also be a profile itself, common definitions shared 
by all the members of the group.

Those profiles would be available regardless of which mod you're 
playing, you could however associate profiles with mods so they would be 
automatically activated.

I also want things like screenshot naming and labeling options (so you 
could turn on an option to automatically label each screenshot you save 
with server name, map name, time, and date, and could also name them 
according to those things).

Realize also that this completely allows editing of binds and aliases, 
no funky 'fire button assigned to: mouse1' kind of config like all the 
other games have.

Can you tell I want complete configurability and I want it easy?

I'm not sure that anything should be automatically saved unless 
specifically set using the config editor.  This would get rid of all 
those pesky config.cfg files.

>>(Note: I have not read all of the original message, as I disagreed with 
>>it too early to do more than glancing over it)
> 
> 
> You missed:
> 
>  - moving id1 and friends to a subdirectory named data so that intelligent
>    OSes can make this a symlink without making a mess of the current dir.

This would confuse existing quake players and reminds me of quakeforge.

>  - a side effect of creating profiles, but a good idea regardless, a new
>    Cvar flag, perhaps CVAR_GLOBAL.  This flag indicates that a Cvar should
>    be archived, but not to config.cfg (which is game directory specific
>    and under my proposal also profile specific..)  Such settings are
>    things like resolution, locations of things (normally no longer
>    needed), the name of the OpenGL library to use, etc.

I covered that in config editing above.  Let the user decide if 
something is per mod, or global, or whatever else.

>  - the fact that twilight would suddenly care about whether a directory
>    existed or not or could be written to.  Non-existence is ignored for
>    read, but an attempt to create the directory (recursively) would be
>    made for write.  Failure to do this or lack of permission would cause a
>    test of the next path element, rather than just giving up immediately.
> 
> The order of initialisation:
> 
> 1. Determine defaults for things like user dirs based on OS (ie, this
>    system is Win32, but is it NT-based?  If not, do we have user-specific
>    settings (assuming we learn how to use them)?  If not, we have no user
>    dir by default.)

As I mentioned win95 onward has multiple user profiles.  And I don't 
think anyone on windows actually cares about multiple user profiles for 
purposes of a game.

> 2. Determine the binary's directory using one of several methods tried in
>    sequence.  The specifics may vary by platform, but the general sequence
>    and user-controllable aspects are as unsurprising as possible.

I DO NOT WANT US TO CHECK THE BINARY'S DIRECTORY, PERIOD.

> 3. Command line is applied exactly once.
> 4. Read the global config file, which might override the OS default for a
>    user directory, set the default resolution, etc.  At this point, since
>    the config is the only file read, the directory for data has not been
>    nailed down and you COULD change it if you felt you had to.  Not noted
>    before (by omission) is the need for for twilight.cfg to not override
>    the cmdline.  Not sure how yet.

Mark anything set by the commandline as being locked by the commandline, 
and clear that flag later?

> 5. If there is a user directory, its twilight.cfg is read as well.  Again
>    you COULD change paths here, but you shouldn't and the game would not
>    give you the option to do so.
> 6. Paths are locked, game loads.
> 
> 
> I'm thinking it might be useful to have a set-if-not-already type command
> available.  The equivalent of Cvar_Get for use in config files, where a
> normal set would create a Cvar that did not exist.  Those details haven't
> been fleshed out in my mind yet, obviously.

-- 
LordHavoc
Author of DarkPlaces Quake1 engine and mod
http://icculus.org/twilight/darkplaces/
"War does not prove who is right, it proves who is left." - Unknown