[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