Oolite Bulletins

Today, I decided to follow the directions on the Wiki at http://wiki.alioth.net/index.php/Runnin ... rom_source to make my own trunk build, mostly because I've been hanging to see normalmapping in action... (not to mention Griff's new Thargoid ship) I decided against using another_commander's easy method because my drive is already partitioned up the way I like it, (1 for XP and 5 for Kubuntu) and I didn't want to mess with things just to have a D: drive.

It went quite smoothly, all things considered. My first compilation attempt failed with a huge list of errors, however. Poking around, it occurred to me that the windows dependencies file (Local_20080124.zip) was the likely culprit. I had followed the directions literally, unzipping the file into C:\GNUstep\Local, with the result that the C:\GNUstep\Local folder only had two folders in it, named oolite and Local_20080124. I moved the folders inside Local_20080124 up one level and deleted the now empty folder before trying again.

The second attempt went smoothly, and just 5 minutes later, I had my first trunk-build!

Playing around with it, I learned about a few differences between this and my 1.72.2 installation. To begin with, the build expects the oolite-saves folder not to be in oolite.app, as I had expected, but up one level (in the trunk folder).

The other thing I noticed was that it was far from clear where I should place the AddOns folder. I tried several times (and locations) but had no success in getting the game to load some oxps. A careful reading of the log seemed to indicate that the game was searching up one level from C:\GNUstep\Local\oolite\trunk, and sure enough, when I moved the AddOns folder to C:\GNUstep\Local\oolite, lo and behold, everything was working correctly at last! The Wiki entry needs to make these details a little clearer, I think.

Oh yes, re the note about adding /Local/include to the include search path... everything worked fine without me following this step...


Now all I need to do is figure out how to replace my Cobby with the normalmapped Griff Cobra 3 in my test save-file...

Diziet Sma wrote:

Now all I need to do is figure out how to replace my Cobby with the normalmapped Griff Cobra 3 in my test save-file...

Open the shipdata.plist from Griffs version, copy the name of the player ship (if it exists, I'm not sure about that, but otherwise you've got a problem) and paste it into your save file where it currently references the original CM3.

Screet

Maybe the "complex" build instructions should be either revised or obsoleted altogether. The new build does not expect any changes in folder structure and if this happens then either something is wrong with the instructions or something was not done in the correct matter. 1.73 will not be requiring any alterations as to where files go.

Screet wrote:

Diziet Sma wrote:

Now all I need to do is figure out how to replace my Cobby with the normalmapped Griff Cobra 3 in my test save-file...

Open the shipdata.plist from Griffs version, copy the name of the player ship (if it exists, I'm not sure about that, but otherwise you've got a problem) and paste it into your save file where it currently references the original CM3.

Screet

Once I had my oxp's working, that was a cinch.. I'd already done as you suggested, but because the oxps weren't being read, it wasn't working..

Now.. well.. let's just say I have some great screenshots already.

another_commander wrote:

Maybe the "complex" build instructions should be either revised or obsoleted altogether. The new build does not expect any changes in folder structure and if this happens then either something is wrong with the instructions or something was not done in the correct matter. 1.73 will not be requiring any alterations as to where files go.

Perhaps a little revision is in order, but I wouldn't suggest they be obseleted.. I followed the directions to the letter, and everything did work as advertised.. I suspect the unusual folder locations were more to do with running the game from the GNUstep shell, as the directions say, rather than launching the game in the usual way. I'm thinking that by launching in this manner, it may be operating in something akin to a chrooted environment under Linux, and the game is a little confused as to what constitutes 'root'.

Edit: I don't believe this is the actual reason now, see my next post for reasons why...

2nd Edit: I was right after all.. see further down for the gory details...

You have a good point there. I was referring to the game as created by the installer, which is what people end up getting and did not consider about running it from the shell.

Edit: What I posted below is an interesting theory, but turns out to be wrong.. Launching the game by clicking on the oolite.exe icon results in the game expecting everything to be in the standard locations... so the problem as originally described WAS due to being launched by the GNUstep shell... <sigh> ah well.. I've left everything intact in my posts so that others can learn from all this...

Original post starts here...
Having given this topic some more thought today, I suspect the actual reason for the strange folder locations is not so much due to running the game from the shell per se, but rather due to the following....

The standard installed Oolite directory tree, (ignoring directories not relevant to this discussion) looks like this: Whereas the directory tree created when the Wiki instructions have been completed looks like this: It seems that the program executable regards the Oolite directory as the program root, and expects Addons to exist one level below root, and oolite-saves to exist two levels below root, so, even though the executable itself is nested one level deeper than usual, it looks for (or creates, respectively) the Addons and oolite-saves directories in what it regards as the correct locations with respect to program root, rather than with respect to the location of oolite.exe itself. The Logs and GNUstep (game-GNUstep, not the top-level GNUstep build-environment) directories are similarly relocated one level higher than we might normally expect, for the same reason.

Clear as mud?

another_commander wrote:

You have a good point there. I was referring to the game as created by the installer, which is what people end up getting and did not consider about running it from the shell.

Just an observation, but (unlike your method, a_c) the Wiki instructions do not result in an installer being made, and no directions are given for creating one...

Diziet Sma wrote:

Clear as mud?

Not really, because on my build installation, the Addon folder was within the trunk folder!?!

Screet

Screet wrote:

Diziet Sma wrote:

Clear as mud?

Not really, because on my build installation, the Addon folder was within the trunk folder!?!

Screet

It all depends on how you launch the game, I think.. see updates to my earlier posts.. this thing has had me going in circles.. but I think I'm on top of it now...

another_commander wrote:

Maybe the "complex" build instructions should be either revised or obsoleted altogether. The new build does not expect any changes in folder structure and if this happens then either something is wrong with the instructions or something was not done in the correct matter. 1.73 will not be requiring any alterations as to where files go.

Please don't obsolete. I don't want to create a D: drive just to compile Ooolite. I've just followed the Wiki instructions and had just two problems: I had to add the location of cc1 to $PATH and I had to create an Addons folder. This could be added to the make process.
The Addons folder has to be at the same level as the executable ie in Oolite for the installer version where you execute oolite.exe in oolite.app and in Oolite for the Wiki version where you execute openapp which calls oolite.exe located a level down in oolite.app. If you wish to execute oolite.exe directly move the folder in trunk, alongside oolite.app.