Bug under Linux/Unix

[Entropy]

The books and actors def files are incorectly placed in the /data_dir thingy.

Since they are static data, they should not be dependent on where the data dir points to.

Because if you install EL in your home directory, for example, the data path will incorectly point to /usr/share/blah and the client can't load the actor files.

[ttlanhil]

err. but isn't data_dir for everything except user/config?

as for the path, agreed, it can be wrong... maybe when it makes ~/.elc/el.ini it should check if the data_dir is right, if not, try using $PWD instead... though if they wanna install data later it'll be trouble (but if they're doing something odd like this, they can edit ~/.elc/el.ini )

[Vegar]

The problem is that when ~/.elc/el.ini is created, data_dir defaults to /usr/share/blah, IIRC.

data_dir should be commented (that is, without the #) when a new el.ini is created.

[Entropy]

Ok, maybe I do not understand how it is supposed to work for Linux, so correct me if I am wrong.

 

I downloaded the Linux client, unziped it in /home/radu/el

Then I run the static binary, which complained about how it can't open the race books and the actors def file. Not surpringly, they were in the wrong path.

It did however open all the other files (maps, objects, textures), so I was able to 'play' the game but without seeing any players and animals.

 

The way I understand it is that it creates a config directory, where it places the user specific data (logs, config, etc.). But it takes the other data (maps, 3d objects, etc.) from the directory where it was started. Is this correct?

[Vegar]

I believe that is correct. The config directory is ~/.elc/.

Can you check if data_dir is set in ~/.elc/el.ini?

[The_Piper]

<rant>

 

Maybe i may sound offtopic, but that behavour under Linux is total crap.

 

There is an el.ini in your EL folder, and one in the ~/.elc folder.

 

EL folder is the local one, ~/.elc the global one.

 

Usually the local config file should beat the global one, so you can create just another EL folder and have some local settings in el.ini.

 

Like now it is, we need to change the global one in ~/.elc and the one in your EL folder is ignored.

 

So, i cant have 2 different EL folder where one goes to the 2k server and the other one goes to the test server, i must always edit the global one in ~./elc and that sux.

 

I submitted a patch to change this month ago but it was never accepted and iirc it was deleted.

 

Sorry, to say this, but this behaviour under Linux sux and nobody cares. And that suxx0rs even a little bit more.

 

</rant>

 

 

Piper

[Entropy]

Yes, The Piper is right.

The way I see it it should be like this:

 

The client is started, it checks to see if there is an .elc settings directory in the home of that user. If so, load the data from there.

If not, create it with the data dir set so that it can load the data from where the game is installed. Having two el.ini is very confusing, and takes a lot of tweaking.

[The_Piper]

Erm..

 

~/.elc/el.ini is the global file for a single USER

 

the el.ini in #game_path is the one for ALL USERS on that machine

 

and the local one in your current EternalLands folder is the local one. Which i like to change to go to the 2k server or to the test server, and that doesnt work.

 

And IMO, the local one in your EternalLands folder should beat all other ones, b/c you cant have local settings in different EL folders, due to that.

 

That is my point.

 

First check el.ini in the local EternalLands folder. If there is none, check the one in ~/.elc(still in the $HOME directory of a single user), then the one in #game_path (global, for all users).

 

Where #game_path not really makes sense, or do you expect a community or a company to install and play EL, so that they need global settings for all users?

 

 

Ok, when im done with installing SuSE Linux 10.1 on my comp, (i'm now on my laptop), i can try to create another patch to use first the local el.ini and then the global one in ~/.elc, if you want.

 

IIRC it was nothing more than changing an if() from first using global el.ini to use the local one, shouldnt be such a big thing.

 

Shall i go and try to make that patch, when im done installing my comp, entropy?

 

(i would *really* love to see that patch in game)

 

Piper

[Learner]

In my mind the ~/.elc is the one that should be used, if it doesn't exists, create it from the instal directory copy. Nothing else, no checking in the current directory, etc.

[ttlanhil]

In my mind the ~/.elc is the one that should be used, if it doesn't exists, create it from the instal directory copy. Nothing else, no checking in the current directory, etc.

even if the install dir isn't what's set as data_dir? that's contrary to any it-just-works effort

[Torg]

Vegar is correct. The data_dir variable should exist for people packaging EL under various different distro's. The data should normally be under a seperate directory to the client bins etc (this is normal for lots of distro's).

 

However, intially, the data_dir of the Linux client hosted on the EL site should not be set so that it defaults to the local directory which you have installed into.

 

 

As for the client ini files...

 

Under windows you can have different el.ini files for different versions of the client. I usually run 2, sometimes 3. Under Linux this is a pain (as Piper points out) because you can only use a single el.ini file. I personally agree that el.ini should default to ~/.elc/el.ini, but there should be provision for a local copy (in the same dir as the bin) for different client setups like under windows.

Edited October 27, 2006 by Torg

[ttlanhil]

Under windows you can have different el.ini files for different versions of the client. I usually run 2, sometimes 3. Under Linux this is a pain (as Piper points out) because you can only use a single el.ini file. I personally agree that el.ini should default to ~/.elc/el.ini, but there should be provision for a local copy (in the same dir as the bin) for different client setups like under windows

no, not the data dir, because that shouldn't be writable (root install, non-root player, hence why ~/.elc is used)... instead, why not have a command line option for where to find el.ini? eg:

./el.x86.linux.bin --conf=~/.elc/el.alt7.ini

for minor changes you should be able to use the command line options anyway (put them in a shell script if need be)

[Placid]

Piper: Use the -sp command line switch, it allows you to specify the port before running (-sa for server address).

 

Ttlanhil: The data dir needs writable permissions for auto update.

 

If EL was packaged correctly such as .deb and .rpm (Debian, Red Hat), it may help. Right now EL doesn't work well with *NIX. The games group on most common distributions has writable permissions for various directories (for example /var/games); perhaps this could be used too.

[trollson]

no, not the data dir, because that shouldn't be writable (root install, non-root player, hence why ~/.elc is used)

This highlights another issue, with respect to auto-updates on UNIX.

And Placid got in just before me here

Currently we download updates straight into the data_dir hierarchy. This may be rooted under '/usr/share' [1,2], which should be read-only. So system security must be compromised to accomodate EL.

 

The '/usr' hierarchy is intended to be read-only and shareable (between machines with the same architecture). It may infact be mounted 'read-only'. The '/var' hierarchy is intended for variable persistent data, which would be ideal for game-controlled downloads ('/var/games/eternal-lands').

 

It would help to specify search paths rather than single directories, and stat [3] for the first matching file on the path.

 

As for locating 'data_dir' in the first place: If you haven't yet got a '~/.elc/el.ini', then how do you know where the default should be? You could compile in a default, but that would be inflexible. It may be preferable to install a default (read-only) in '/etc/el.ini' [4], which is at least a (UNIX) system independant location for boot-strap configuration files.

 

Since configuration files are typically collections of information, rather than single items, it is useful to be able to load multiple configuration files in sequences, to allow files to override values without having to repeat all entries.

 

 

See also:

• Filesystem Hierarchy Standard - describes how a UNIX filesystem should be laid out, and what the intended purpose of each area is; although few systems follow this scheme rigidly.
  

[1] On Gentoo this is /usr/share/games/eternal-lands.

[2] Another location is to treat EL as a seperate package and install under '/opt'; however this is really intended for far more complex packages.

[3] stat() is far cheaper test than trying to open candidate files.

[4] Although a more distinctive name may be necessary to avoid the chance of collision with another configuration file, '/etc/eternal-lands.ini' for instance.

Edited October 27, 2006 by trollson

[ttlanhil]

Ttlanhil: The data dir needs writable permissions for auto update.

plACID(well, you capitalised mine wrong ): except that users shouldn't be able to mess with shared data on a multiuser operating system... the right answer, IMO, is a quick shell script (or something more fancy if desired, but shell can do the trick) that can be run as root (stick it in cron, or maybe setuid/setgid(games group)/chroot and launched by ELC... as long as it's not compromised, which means it's coded right and root isn't stupid, it's not much of a security risk (esp if it's setuid/setgid to someone(s) that can update game data but nothing else)) to simulate AUTO_UPDATE

As for locating 'data_dir' in the first place: If you haven't yet got a '~/.elc/el.ini', then how do you know where the default should be? You could compile in a default, but that would be inflexible. It may be preferable to install a default (read-only) in '/etc/el.ini' [4], which is at least a (UNIX) system independant location for boot-strap configuration files.

use $PWD or the location of the binary, because if you can launch ELC you have a (semi?) valid install... just record (or not) where you're executing from Edited October 27, 2006 by ttlanhil

[Troca]

why not have a command line option for where to find el.ini? eg:

./el.x86.linux.bin --conf=~/.elc/el.alt7.ini

May I humbly push for a patch I made to make the user config directory changable (both compile time and now also runtime through a command line switch). See berlios patch 959 and this forum thread.

[trollson]

As for locating 'data_dir' in the first place...

use $PWD or the location of the binary...

Neither $PWD or the binary's directory can tell you the location of the data directory; this depends on the system layout.

[ttlanhil]

Neither $PWD or the binary's directory can tell you the location of the data directory; this depends on the system layout.

I beg to differ. the normal case will be someone who downloaded the big zip, so the binary will be in data_dir... other cases are packages (in which case el.ini should have the right data_dir already) or cvs users, who should know how to fix it

[Entropy]

I don't really care how it's done, but it would be nice to have it so you won;t have to manually edit the ini in order to play the game properly.

[trollson]

other cases are packages (in which case el.ini should have the right data_dir already)

That doesn't help on first invokation, when the user doesn't have their own copy of el.ini and the default copy is in 'data_dir'; which is what we are trying to determine.

 

I see though that a default data_dir is hardcoded into the client through a DATA_DIR macro, which can be set on the compile line ('-DDATA_DIR=...'), which is adequate for integrators.

 

Still, I would only use PWD or executable location as a last resort.