[twilight-devel] data file location
Joseph Carter
knghtbrd at efn.org
Mon Feb 10 12:47:39 EST 2003
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:
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.
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.
> 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.
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
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. ;)
> 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.
> (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.
- 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.
- 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.)
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.
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.
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.
--
Joseph Carter <knghtbrd at efn.org> If this sig were funny...
<frogbert> its hard being a lesbian withoutn breasts...people dont take
you seriously
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 253 bytes
Desc: not available
URL: <http://icculus.org/pipermail/twilight-devel/attachments/20030210/0e58c480/attachment.pgp>
More information about the twilight-devel
mailing list