[twilight-devel] data file location

[Joseph Carter]

On Wed, Feb 12, 2003 at 10:00:50AM -0800, Peter Jay Salzman wrote:
> > >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.
>  
> i whole heartedly agree.   it's aesthetically pleasing to have the same
> behavior, but from a practical standpoint, there's really no sane reason
> to do so.

I'll give you one: TECH SUPPORT.

The whole reason I even brought any of this up is the overwhelming group
of people who can't figure out how to run Twilight once they compile it
under Linux.  Granted, if these people looked at the output of ./configure
after running it, they'd probably know where to put things (since it says
"these things go here           /path/to/foo"

The solution?  Self-containment of the binary.  Less Linux-friendly
engines do this already simply because Quake itself did it.  The reason we
ever changed that was because the Quake way doesn't work for Linux very
well:  Shared installation, symlinks, UNIX filesystem standards...


I am proposing we return to something more like the way every other Quake
engine save QuakeForge works, but with the condition that the result will
support for the first time actually living in a Linux environment,
including a shared installation, while still being able to be run from the
build directory (something that eg, DarkPlaces and Twilight can do, but
QuakeForge cannot..)


> > 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).
>  
> again, i'm completely in agreement.

You gonna write the installer?  Or build the packages?  Packaging Quake is
NOT trivial: dependency on Quake data.  Extraction of Quake data can be
made from one of six differently formatted CDs, one of which I don't even
have to tell you how.  At least two of these CDs require code to extract
LHA archives.  Another requires that you be able to extract old-style RPM
files.  

Oh, did you intend to support the official mission packs?  Once again,
there are three differently formatted CDs which would give you this.  You
will need that RPM extractor again, but fortunately the others are
uncompressed.

There's also the possibility of getting the configs from a Windows install
(may or may not need to rename the files since Linux is case-sensitive),
and just downloading the shareware data (zip is needed for this, and if
you opt to use the Id archive, LHA as well.  We have a version that works
with just zip though..)

And even if you want to copy files over...  The player may have unpacked
his pak files for whatever reason!  I have had complaints that such things
are not supported, and I don't expect to start supporting that any time
soon.


> > 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!
> 
> once again, i agree.

Right, Windows users are used to things crashing.  We should simply crash
in this case and give the user an error message and hope he's smart enough
to fix it.

Although we don't have to, we CAN.  It's not even hard, and it results in
a more robust program.  It also means we are more prepared for platforms
where the concept of running things from the working directory is unknown
and offensive.  We target three such platforms.  In fact, Windows is the
only platform we target which does not universally oppose the concept of
running things from a particular directory.


> > 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.
>  
> agree somewhat.  it's nice to specify things via an environment
> variable, but dot files are good too.
> 
> sometimes i feel like i have too many dot files, so an environment
> variable is sometimes appreciated.

Environment variable is a concession to classic UNIX practice of taking a
package, putting it somewhere, and telling the program where that is
exactly.  It's what you do when you can't or won't realpath the binary and
having lots of config files is considered not an option (as I consider it
here..)

The clients don't actually run on any such platforms, but the servers
should.


Once again, my proposal:

if cmdline specifies path:
  return cmdline spec

if environment variable is set:
  return its value

if windows:
  # Working directory is canonically supposed to work,
  # but ONLY on windows...
  if working directory ... works:
     return working directory
  ask Windows for exe path (one line of code!)
  return a dirname of that path

if linux:
  if /proc/self/exe is there:
    readlink it
    return a dirname of that path

if we have realpath (ie, Linux, Solaris, BSD, MacOS X):
  if realpath(argv[0] ..) returns non-error:
    return a dirname of that path

output that we couldn't find the thing and offer a clue as to what to
change to fix it.



You can't ask for a path because you couldn't write it anywhere except on
Windows where it doesn't matter since you'll never have a broken shortcut
right?

I have no desire to have a config file which must be placed into /etc
since I intend not to provide a system global config (or have one be
necessary..)  Users might have one, specifying their preferred resolution
and the like, but these things are intended at some point to be changed in
game, so I would expect that the user's global (ie, not mod-specific)
config will be able to be changed at will sooner or later, so the contents
of it should be written out just as config.cfg is today.


The point was that the binary would no longer be in an arbitrary location,
unless someone explicitly does something to cause it to be.  In the case
that they do so, they can still - but they're responsible for making it
work.  On UNIX systems, this is easy, and in fact Debian will need this
done for sure.  For Debian, I propose:

#! /bin/sh
TWILIGHT_DIR=/usr/share/games/twilight
/usr/games/$0.real "$@"

Then just make a symlink in /usr/share/games/twilight for the config file
if there's need to provide one.  Forest has decided to refuse this
outright, so it won't happen, and probably all of the stuff dependent on
it won't either since the status quo is fine.  I'm not happy about it, in
any case.

-- 
Joseph Carter <knghtbrd at efn.org>            I N33D MY G4M3Z, D00D!!!!111!!
                                                      (Just ... don't ask)
 
<Elric> no BSD fans ?
<EvilTypeGuy> Elric: it's hard to be a gamer and a bsd fan :p

-------------- 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/20030212/3365a003/attachment.pgp>