Oolite Bulletins

As a long time Windows user, I have found that one thing that annoys me a lot is when a program installs files outside of its own directory. I don't want to be looking for files of every application I have installed in two or three different places on my hard disk. When I use an application, I want to know that everything that this application does remains confined in its own folder. This is also one of the reasons I happen to hate the Windows registry and am all up for .ini files usage instead (again, in the same folder as the application). As for USB stick installs, with the approach we currently have things are even better (as in simpler), because the user does not have to tweak anything anymore. Also the game can now be moved around locations by simply moving its root folder, while earlier the batch file had to be edited to make it work from a different location.

As for the C:\Oolite vs C:\Program Files\Oolite it is done as you say to avoid virtualization. I honestly prefer having a "hack" in place, rather than having users not being able to use or edit OXPs because Vista decides to save user files at some obscure place deep inside the Windows tree structure.

Personal opinion here, always open for discussion.

another_commander wrote:

As a long time Windows user, I have found that one thing that annoys me a lot is when a program installs files outside of its own directory. I don't want to be looking for files of every application I have installed in two or three different places on my hard disk.

And especially when they create folders in 'My Documents' without asking or even mentioning that they're about to do so.. which is rather like Problem's problem, actually...

Regarding the Linux issues:

• It is apparently possible to install GNUStep in such a way that it follows Linux conventions regarding its folders. I assume Oolite would work fine that way. You’d probably need to build GNUStep yourself rather than use a package.
• I strongly oppose putting saved games in hidden locations. They are a form of document, not game internal data. However, Oolite ought to be remembering where you last saved and using that rather than recreating the default location each time. I’ll check and implement that if it isn’t the case.

I have no idea what would be good behaviour under Windows. :-)

...what would be good behaviour under Windows.

Now there's an oxymoron!

I never said the Windows way (Program Files for binaries, Registry / My Documents for settings, My Documents for docs) was a good way - but that's the way Windows is set up, that's the way modern Windows users expect apps to work. Anything else is confusing (for a bog-standard Windows user) and/or causes problems - especially with Vista.
I would need to check whether or not the current trunk build accepts environment-variable overrides for the GNUstep paths (I think it does). If it does, a neat solution might be for the installer to prompt for a 'system install' or a 'relocatable install'. The former would add suitable GNUstep path declarations to the system environment, keeping the binary in the ProgFiles and looking for Saves/Addons in MyDocs (but not creating these directories unless specifically asked to). This wouldn't fall foul of Vista either then.

OS X apps don't keep everything in one place either - they use the NEXT layout which places all sorts of files in all sorts of places, depending on what the App does, caching, and whatnot.

Building a customised GNUstep implementation - no thanks. Who knows how that would break other GNUstep apps in the system. Besides which I'd no longer get automated updates/fixes for a system infrastructure component. I'd rather tweak the one App with which I have a (personal) problem.

Save-games (as documents) and needing to be visible I more or less agree with. But what I do mind is Oolite having BOTH a hidden .Oolite folder AND a visible oolite-saves folder, both of which are in my homedir. I'd vote for having one as a sub-folder of the other.

Being a GNUstep app, the 'proper' spot for per-user addons/settings/etc, would be inside the ~/GNUStep/Applications/Oolite folder.. (http://www.gnustep.org/resources/docume ... tem_5.html) but that wouldn't be very user friendly for bog-standard Linux users. Besides which I seem to remember there being a problem with that approach anyway.


How about this as a suggestion for Linux:
~/Oolite or ~/.Oolite (searched for in that order - that way, people with preference for a 'clean' homedir can use the hidden version, but default is the visible one).

Inside that, have AddOns, Saves, whatever.

This way both the save-games and Addons are easily accessed, these being the 2 folders which are highly likely to need mucking about in by players.

Also, if Oolite 'remembers' the last-used save directory, (I wasn't aware of this.. ) then it shouldn't create the default directory unless a save-game is actually saved there. Ie, only create it if it's actually going to be used. From what I remember of the path-handling code, this may not be trivial to implement though.

Also, if Oolite 'remembers' the last-used save directory, (I wasn't aware of this.. ) then it shouldn't create the default directory unless a save-game is actually saved there. Ie, only create it if it's actually going to be used. From what I remember of the path-handling code, this may not be trivial to implement though.

In which case it's going to have to specifically ask where to make the first game-save, too...

Micha wrote:

Building a customised GNUstep implementation - no thanks. Who knows how that would break other GNUstep apps in the system.

It’s not really a matter of customization, it’s more of an install option. Any GNUStep app which doesn’t work with either layout is seriously broken. Not that I suggest doing the extra work anyway…

Micha wrote:

Save-games (as documents) and needing to be visible I more or less agree with. But what I do mind is Oolite having BOTH a hidden .Oolite folder AND a visible oolite-saves folder, both of which are in my homedir. I'd vote for having one as a sub-folder of the other.

That’s understandable. On the other hand, ~/.Oolite/AddOns is optional (you can put addons in oolite.app/../AddOns) and oolite-saves should be; maybe there’s a better place for logs than ~/.Oolite/Logs?

Micha wrote:

Also, if Oolite 'remembers' the last-used save directory, (I wasn't aware of this.. :oops:)

I’m not sure if it does, but it should.

Micha wrote:

…then it shouldn't create the default directory unless a save-game is actually saved there. Ie, only create it if it's actually going to be used. From what I remember of the path-handling code, this may not be trivial to implement though.

Yeah, that could be tricky. Not a priority, at any rate.

Micha wrote:

I never said the Windows way (Program Files for binaries, Registry / My Documents for settings, My Documents for docs) was a good way - but that's the way Windows is set up, that's the way modern Windows users expect apps to work. Anything else is confusing (for a bog-standard Windows user) and/or causes problems - especially with Vista.

Maybe this is how the current Windows way is, but I have not seen any users reporting problems locating their saved games or OXP files in a standard WinXP Oolite installation, where everything is put under a folder called Oolite. What I have seen though is users asking these questions when on Vista (ask Screet for more information, I'm sure he will be happy to share his experiences). This is because Vista is trying to force the user to the modern way of doing things and this ends up being indeed confusing. The players of Oolite do not expect Oolite to store files in My Documents or other places, for the simple reason that the documentation in place (wiki or readme or forum posts etc) has always pointed them to the locations we use today.

One other thing to consider is that the documentation we have that describes files locations will have to be changed. If we go the way of the "Relocatable" and "System" installs, not only we will add more confusion in the mix, we will also need to maintain double the documentation. The question here is: Why? We have it working fine already, we are consistent with previous releases and users can do their OXP editing without worries. And let's face it, a large part of the fun in Oolite is fiddling with its program files, so that immediately sets it apart from other styles of applications, where the user is not supposed to touch the program.

Ahruman wrote:

Micha wrote:

Also, if Oolite 'remembers' the last-used save directory, (I wasn't aware of this.. :oops:)

I’m not sure if it does, but it should.

…and now it does.

Ahruman wrote:

Micha wrote:

Save-games (as documents) and needing to be visible I more or less agree with. But what I do mind is Oolite having BOTH a hidden .Oolite folder AND a visible oolite-saves folder, both of which are in my homedir. I'd vote for having one as a sub-folder of the other.

That’s understandable. On the other hand, ~/.Oolite/AddOns is optional (you can put addons in oolite.app/../AddOns) and oolite-saves should be; maybe there’s a better place for logs than ~/.Oolite/Logs?

The installers for Linux puts oolite.app into a system directory though, which users shouldn't muck about in - so oolite.app/../AddOns -should- be off-limits.

The 'standard' place for logs in Linux is /var/log - but this is a system directory which users shouldn't be aware of, never mind touch, either. From a multiuser perspective (ok, being pedantic, ignore me now - I mean how many people really run the linux machine they game on multi-user? Close to zero I'd wager..) the log should be per-user anyway.

And as another_commander pointed out, a lot of Oolite players fiddle with the program (either directly or via OXPs) and we actively encourage looking through the log files to detect/report problems, hence it should be easily accessible.

So I do think the log files should probably stay where they are on Linux.

I've had a poke round the Ubuntu package and the Debian upstream package, and I have emailed the guy with his name all over the packages to see if he's still around, given that everything seems to be from 2006!

Meanwhile I am going to checkout the version from Debian SVN. I think my cunning plan for a trunk nightly package IS going to work because there is very little in the Debian SVN repos itself and there is an OrigURL tag.

Meanwhile part II the /home/ze/GNUstep/Library/Caches/Oolite-cache.plist file is one of the biggest files on my root now (only the kernel is comparable) which means I'm going to need a cunning plan to get it moved to whereever Ubuntu is supposed to put big game-related files. Not home, that's for sure, probably /usr/games...

I'll start a Linux packaging thread when I begin to get somewhere, because it now looks like this has all been in suspended animation since 2006 which is probably before Giles handed over?

Considering the Cache.plist file is a per-user generated file, putting it somewhere like /usr/games is completely against the spirit of Linux. It's a persistent temporary file to speed up loading of Oolite (with your particular set of installed OXPs etc). So if anywhere, it should probably go into /var which is the place for these sorts of files (although you'd have to generate a user-unique name for it with the related code changes).

I'd keep it where it is, in the GNUStep Users Domain (which is rooted at ~/GNUStep by default). If you don't like it being there on your machine, you can move the parent directory to whereever you want and symlink to it.. that ought to fix it.

Oh, the Debian packaging has also been completely overhauled since whatever is in the official Debian repositories. You can easily build a Debian package by grabbing the trunk sources, installing the various dependencies (if you haven't already), then "make -f Makefile pkg-deb".

zevans wrote:

Meanwhile part II the /home/ze/GNUstep/Library/Caches/Oolite-cache.plist file is one of the biggest files on my root now

How big, out of interest?

Micha wrote:

So if anywhere, it should probably go into /var which is the place for these sorts of files (although you'd have to generate a user-unique name for it with the related code changes).

Just concluded same thing here, after looking at the Debian FHS - there is a /var/games hierarchy. Would have to do something with sticky permissions as well as generating a unique name. So symlink it is for now.

Oh, the Debian packaging has also been completely overhauled

So I see now - cool! Some bloke called Micha seems to have done all the work already.

I'll have a look how big the cache gets when I run the game again... I've gone right back to fresh SVN checkout (and deleted the cache file) so I can try out the package build stuff you wrote. It's building now.