Oolite Bulletins

Getting textured-planets with libnoise into the trunk would be tricky. I gave up trying to merge the trunk code into the textured-planets branch (which is effectively the same operation) because the trunk's planet texturing code and the libnoise texturing code obviously hit exactly the same parts of...

I don't understand the question - do you mean how to check out the branch, or how to use the textured-planets exe? If you're trying to build textured planets you're in for an exciting ride. You need to build a very recent version of GCC and use that in preference to the GNUstep one, because it can't...

FYI there is a script in the tools directory called mkwinsnapshotinst.sh that will build a Windows installer using the NullSoft installation system.

This is what I use for making my installers.

You're welcome to do that - I was putting it off, concentrating on other things.

My mods to Oolite - fast, cheap, good, choose any one of them.

I've just built the JS branch and it is working fine. I have a couple of files modified locally, which would be to do with the equipment refactoring I warned you about. The JS scripts are loaded the same time other OXP scripts are, in ResourceManager.loadScripts. The main loop in that method looks f...

First thing to do is read the "Building Oolite from source" information on the wiki - http://wiki.alioth.net/index.php/Running_Oolite-Windows#Building_Oolite_from_source . This is slightly out of date, but I think the only thing missing to get the trunk going is libxml2. The DLL is in the ...

All Win32 related downloads are available at the Berlios Oolite-PC site.

Callas, I think your ideas are pretty interesting and the simplistic trading model in Oolite bugs me a bit too. Perhaps a better way to drive this conversation is to say you're going to use the Oolite code as base for YOUR space trading game that allows players to play in a universe where the tradin...

The JS integration is pretty simple and doesn't require too many changes to the code - it is mostly an "add-on" rather than a "replacement". It mostly consists of a couple of new files, plus some minor changes where OXPs are loaded and scripts are called. And a JavaScript interpr...

Well, I brought the JS branch up to date a couple of months ago to try and avoid too much divergence, but I didn't expect Ahruman to get all fired up and start making Big Changes to the trunk... So yes, this is an issue because I found out that Big Changes in the trunk don't port easily to a branch....

That was one of the problems that made me lose interest in this feature a bit. It became clear to me that the design of the game didn't suit this idea, and NP ships is a good example of that. Another is the salvage fee - why would you trade when you can make heaps of money for just disabling a pirat...

Textured planets is dead - apparently there are better ways to get the same, or better, results. I know you want the same planets and moons to appear in a system each time. The galaxy_number and planet_number values will always be the same in a given system so if you munge them somehow you'll always...

You have defined system_info to be local to the Initialise function. You need to move its declaration outside of that so the whole script can see it: var system_info = new Array(0x01, 0x03, 0x00, 0x07, 0x00, 0x02, 0x01, 0x03, 0x02, 0x00...); this.Initialise = function () { // anything else you need ...

Well, the JavaScript branch allows OXPs to listen for keystrokes to trigger behaviour so it is covered there. My original thought last year was that binding scripts to keys would allow OXPs to create new equipment too, but in the standard game engine there isn't enough of the internals exposed to do...

I actually implemented scripts bound to keys last year, but couldn't find a use for it so never checked it in! Oh important one: Key binding Probably needs to be hardcoded and defined in a plist. eg. in equipment.plist or such:: <key>Boundkey</key> <integer>keyvalue</integer> <key>PlusShift</key> </...