Oolite Bulletins

Posted: **Tue Aug 18, 2009 2:12 pm**

While I'm still getting familiar with the new familiar face of elite, and being the average mod-maniac that I am, I've noticed two vague areas regarding expansion packs: Load order and incompatibilities.

Also, with the idea of making a script that would decide if there is something wrong with OXP list, (other than min and max required oolite version and dependencies, which are more-or-less obvious) I would need you guys to shed me some light on that dim area that only experienced players and modders would know:

What goes where?

For example, Planetfall + oOHaul

Should it be
1. Planetfall
2. oOHaul
3. Planetfall + oOHaul link

.. or what?
Does it even matter?
What if the load order is wrong?
What if some dependent OXP is loaded before the OXP it depends on?
Does it make the game crash? And how come?

My comprehension on that subject can be summarized in one sentence. "OXPs are loaded in alphabetical order and last one counts"

The idea behind this thread is to gather some info that I would later use in my potential script.

By info, I mean what OXP must go in front or behind some other OXP and which two OXPs can't coexist.

.. and I might learn something along the way...

Any advices, input, opinions and criticisms regarding the topic is welcome, as long as it is in the "creative" category.

P.S. Let's take neolitic ships and realistic shipyards out of the context, for that is covered with docs.

Posted: **Tue Aug 18, 2009 2:52 pm**

Yes, scripts are loaded in alphabetical order. But in most cases it doesn't really matter, as it's only if you're trying to do something within this.startUp (and/or possibly this.reset, but that would be very rare) that you could possibly have dependencies if scripts are relying on one another (and not yet loaded). Doing that (except for setting up or resetting things) is not so common.

For example in the case you mentioned, it doesn't really matter which script is loaded first. The planetfall script only really actively starts doing things when the player launches, and the Oohaul one likewise. The linking script is just an expansion to PF, and if Oohaul or PF aren't installed then everything will run fine, but no extra functionality will be apparent to the player. Normally the start-up events are used to set/clear variables and that kind of thing, rather than actions and occurrences that may need other required scripts loaded.

It's a slightly different case when two scripts are trying to do incompatible things (e.g. both try to change the name of a particular system to something else), at which point the last-loaded one will win-out. This may or may not cause problems, log errors or strange events in the over-ridden OXP, depending on how it's written. But that kind of thing is quite rare, and is normally noted by the OXP authors as it tends to be quite obvious (e.g. between FarSun and Solar System OXPs), and where possible worked around.

Planetfall and Oohaul are quite independent of one another as OXPs. The link OXP simply defines a few extra "ship" roles, which by piggy-backign the code in Planetfall allows an extra location on the planet, which then mimics the same mission as in Oohaul. If Oohaul isn't actually installed then the mission is to the witchpoint, but if it is it goes to the constore (which Oohaul adds). The link OXP is self-contained that way and includes the mission ship for that particular set-up. But had I written it to rely on the Oohaul OXP, then both OXPs would have been required (although there are ways to detect OXP and ship entity presence at that point).

Posted: **Tue Aug 18, 2009 3:06 pm**

First of all: Yes, OXPs are loaded in alphabetical order. Therefore:

1. Planetfall
2. OoHaul

(Yes, I do know the alphabet.

And O comes before P. But the OXP is actually called Zz-Oo-Haul.oxp precisely for reasons of loading order: To make sure that it is loaded after other OXPs (I don't remember the reason of that in this case, but there certainly is a good reason.).)

Second: As far as scripting is concerned, you don't need to care about load order. All world-scripts and ship-scripts are present all the time. The engine loads all scripts first, and then starts the game. So whatever script you want to depend on, rest assured that it will be present, provided your user has installed the OXP containing the script in question, of course. In case of world-scripts you can even check for its presence in your own script.

Third: The matter is different for property lists. Their contents are merged. Thus internally Oolite has only one big shipdata.plist, shipyard.plist, planetinfo.plist, equipment.plist, commodities.plist etc. This means that entries with the same entry name (identifier) will overwrite each other. Read: the latter will overwrite the earlier. E.g. the shipdata-entry "cobra3-player" from an OXP will completely overwrite and thereby erase the entry "cobra3-player" in Oolite's own shipdata.plist. Or the planetinfo-entry "universal" in System Redux.oxp will overwrite and thereby erase the "universal" entry in Oolite's own planetinfo.plist.

As long as your plist contain entries with different names from existing entries, you're safe. Oolite's internal big plist will only be amended. E.g. the shipdata-entry "cobra31-player" from your OXP will exist alongside the "cobra3-player" from Oolite. For this reason you are highly advised to use unique names for all your entries. If you for instance want to add your own Cobra III variant to the Ooniverse, you should best call it "chaky-cobra3-player". And the same goes for models, textures, and shaders. Here it is the filenames which will overwrite each other.

There are two exceptions from the rule: shipdata-overwrites.plist and shipyard-overwrites.plist. These have been created specifically to allow you to overwrite only parts of an entry. E.g. if you create a "cobra3-player"-entry in the shipdata-overwrites.plist in your OXP, it will not erase the original "cobra3-player"-entry, but amend it. This has the advantage that you can change just a few of the Cobra's specs. Every key not (re-)defined in your plist will stay unchanged from the original entry. Note, however, that you are still changing the ship. There will be no "original" Cobra 3 alongside your changed version.

All these changes are affected by the alphabetical order. Oolite changes and amends its internal plists while loading the plists from all OXPs in alphabetical order. Therefore a plist-change from "A.oxp" can be reversed (or changed into a completely different direction) by "B.oxp".

Hope this answers your questions.

EDIT: And Thargoid beat me to it. Again!

Posted: **Tue Aug 18, 2009 3:10 pm**

Commander McLane wrote:
First of all: Yes, OXPs are loaded in alphabetical order. Therefore:

1. Planetfall
2. OoHaul

Just to nitpick, the scripts are loaded in alphabetical order, not necessarily the OXPs. Each OXP may have more than one script in it (or none at all), and each script has an individual name.

Look in the game logs for full examples, such as the one below (snipped from my most recent game log):

Code: Select all

(oolite.app/Resources, AddOns, AddOns/Galactic_Navy.oxp, AddOns/YOUR_AD_HERE_set_D.oxp, AddOns/YOUR_AD_HERE_set_B.oxp, AddOns/YOUR_AD_HERE.oxp, "AddOns/WIP - TCAT.oxp", "AddOns/Welcome Mat 1.05.oxp", AddOns/Vector1.1.oxp, "AddOns/BigShips 1.01.oxp", "AddOns/Trident Down v1.1.oxp", "AddOns/UPS-courier v1.5.4.oxp", "AddOns/Traffic Control 1.01.oxp", "AddOns/Thorgorn_Threat 1.2.oxp", "AddOns/thargoid_wars 4.3.oxp", AddOns/TestShips.oxp, "AddOns/Target Reticle 1.0.1.oxp", AddOns/System_Redux.oxp, "AddOns/SecondWave 1.1.oxp", AddOns/Rock_Hermit_Locator1.3.oxp, "AddOns/Fuel Station 1.12.oxp", "AddOns/Pods-UPS 1.02.oxp", "AddOns/Pods 1.03.oxp", "AddOns/PlanetFall Mission - Taxi 1.0.1.oxp", "AddOns/PlanetFall Mission - Oo-Haul 1.0.0.oxp", "AddOns/PlanetFall 1.12.oxp", AddOns/PAGroove_Stations_v1.2.1.oxp, AddOns/OXPConfig1.06.oxp, "AddOns/Oo-Haul.oxp", "AddOns/military Fiasco 2.3.oxp", "AddOns/Lave Academy 1.02.oxp", "AddOns/Hired Guns 1.00.oxp", "AddOns/Aquatics 2.02.oxp", AddOns/FuelCollectorV0.06.oxp, "AddOns/Energy Equipment 1.04.oxp", "AddOns/Dictators v1.3.oxp", AddOns/Deposed1.3.4.oxp, "AddOns/Debug 1.72.oxp", AddOns/Commies.oxp, "AddOns/Captured Thargons 1.00.oxp", AddOns/buoyRepair1.02.oxp, AddOns/BountyScanner.oxp, "AddOns/BehemothSpacewar 1.1.oxp", "AddOns/behemoth 2.5.oxp", AddOns/Anarchies2.1.oxp, "AddOns/Dredgers 2.2.2.oxp", "AddOns/WIP - Feudal States 0.2.oxp", AddOns/RandomHits1.3.5.oxp, "AddOns/A - Oolite Shipyards Extension WiP V0.4.oxp", "AddOns/Transports 2.50.oxp", "AddOns/Target Autolock 1.00.oxp")
[dataCache.upToDate]: Data cache is up to date.
[script.load.world.listAll]: Loaded 75 world scripts: "ams_system" 1.00, "Anarchies" 2.1, "aquatics_equipment" 1.1, "aquatics_populator" 1.0, "behemoth" 2.5, "behemoth-spacewar", "bigShips_populator" 1.0, "Bounty Scanner" 1.03, "buoyRepair" 1.02, "buzzer-wowbagger" 1.0, "clipperschedule", "communist_population", "CT_Script" 1.0, "deep_space_dredger" 2.2.2, "deposed", "dictatorship_population", "dredger_appearance", "Emergency Energy Unit" 1.2, "ExecutiveFlightSchedule", "feudal-challenge.js" 1.0, "feudal-escape-pod.js" 1.0, "feudal-mission.js" 1.0, "feudal-planetfall.js" 1.0, "feudal-promotion.js" 1.0, "frog_show", "Fuel Collector" 0.06, "FuelStation-Setup" 1.12, "GalNavy" Build 0133, "hiredGuns_system" 1.0, "hofd" GalNavy Build 118 / HOFD Build 55, "INRAPatrols1", "INRAPatrols2", "LaveAcademy" 1.0.2, "military_fiasco" 2.3, "missile_analyser" 1.1.1, "missionaries", "NavyPatrols1", "NavyPatrols2", "OO-Haul Escort" 1.60, "oolite-cloaking-device" 1.72.2, "oolite-constrictor-hunt" 1.72.2, "oolite-nova" 1.72.2, "oolite-thargoid-plans" 1.72.2, "oolite-trumbles" 1.72.2, "OSE Script" 0.1, "OSEhiredGuns_system" 1.0, "OXPConfig" 1.06, "Pi-Forty-Two Con stores" , "PlanetFall" 1.1.2, "PlanetFall_Oohaul" 1.0.0, "PlanetFall_Taxi" 1.0.1, "Random_Hits", "reticle_target_sensitive" 0.0, "rmb-chaff-setup-script.js" 1.0, "rockHermit_Locator" 1.3, "SalezaPatrol", "sell_equipment" 1.1, "SIRFYardStations1", "SIRFYardStations2", "supercobra_placement", "System Redux 1.0" 1.2, "targetAutolock" 1.0, "thargoid_wars", "Thargorn_Witchspace_Battle" 1.2, "TigersTurf" 0.52b, "TrafficControl" 0.1, "transportSchedule" 2.50, "trident_down", "ups_container" 1.5.3, "ups_docs" 1.5.3, "ups_parcel" 1.5.3, "ups_slaves" 1.5.3, "ups_sun" 1.5.3, "vector" 1.1, "Welcome Information Script" 0.6

[/color]

Posted: **Tue Aug 18, 2009 3:21 pm**

Thargoid wrote:
Just to nitpick, the scripts are loaded in alphabetical order, not necessarily the OXPs. Each OXP may have more than one script in it (or none at all), and each script has an individual name.

Yes, but as far as the plists are concerned, it's the OXP name that counts. And this is the case where order is really relevant.

Posted: **Tue Aug 18, 2009 3:38 pm**

The OXPs aren't loaded in alphabetical order though (the zzz_ naming doesn't do what people think it does), see my above snapshot.

Although you are of course entirely correct that later-loading ones overwrite ones that are loaded before where conflicts happen.

Posted: **Tue Aug 18, 2009 3:57 pm**

Commander McLane wrote:
(Yes, I do know the alphabet. And O comes before P. But the OXP is actually called Zz-Oo-Haul.oxp precisely for reasons of loading order: To make sure that it is loaded after other OXPs (I don't remember the reason of that in this case, but there certainly is a good reason.).)

The reason was that on jumping it wanted to check if something was added by another oxp. But while loading is alphabetical, script execution is more or less random. So the zz never worked for this oxp.

The current version does the check not on entering the system, but one update event later. At that moment all scripts that add something on entering a system have done their stuff and a check for certain ships will be correct. Independent of load order.

Posted: **Tue Aug 18, 2009 4:40 pm**

Thanks for the insights, guys.

I miiiiiiight led you on the wrong path a little, I'm afraid.. My plan is to make 3rd party utility that would "think" instead of the player about technicalities of installed OXPs. Not an OXP. Maybe... I haven't put any form to that idea yet.

OK.. from what I understand, OXPs (as resources) are loaded simultaneously and they, in general, can't clash. Same goes for scripts.

Yet, property lists are the only thing affected by alphabet.
I might even add a conflict-detection in there..

You'll have to excuse my confusion. I'm fresh from The Elder Scrolls 4 modding scene and there the load order is VERY important (set by modified date time-stamp)

Seems to me that Oolite has much better expansion-handling technique that doesn't require (much) user intervention.

Posted: **Wed Aug 19, 2009 5:33 am**

Chaky wrote:
Seems to me that Oolite has much better expansion-handling technique that doesn't require (much) user intervention.

The normal user shouldn't be required to do anything but drop his preferred OXPs into the correct folder, and usually that is exactly how Oolite works.

Of course it would be nice if he read the documentation (readMe's) first, in order to detect whether there might be a clash with another OXP. But we all know that people don't read readMe's.

Still, the chances for clashes are fairly low in Oolite. And most of them are quite obvious. If you install one OXP whose purpose it is to let's say colour all planets green, and another whose purpose it is it colour al planets red, the result will be sorf of your own fault.

I think for your application the only thing you have to do is basically to read the readMe's of all OXPs and program the clash-information you have found in them (oh, and in the respective threads here on the boards). And then update it whenever a new OXP (or a new version of an old OXP sees the light of the day--which practically means on a daily basis. And this is where my doubts about doability kick in.

Posted: **Wed Aug 19, 2009 5:44 am**

@ Thargoid: Hm, my gamelog looks distinctly different from yours. Notably in that all OXPs are browsed in alphabetical order by name:

[searchPaths.dumpAll]: ---> OXP search paths:
(
"/Applications/Spiele/Oolite 1.72.2/Oolite.app/Contents/Resources",
"/Applications/Spiele/Oolite 1.72.2/AddOns",
"/Applications/Spiele/Oolite 1.72.2/AddOns/aegidian-special.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Amen Bricks Megaships.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Anarchies2.2.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Aquatics 1.04.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Assassins.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/AsteroidStorm.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/att1.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/banks.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/behemoth 2.4.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/bigtrader.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/bioSphere.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/BountyScanner.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/buoyRepair1.02.1.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/caduceus.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Cargo_wrecks_teaser.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Cataclysm.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/cobra_courier.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Commies.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Debug.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/deutschesOolite.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Dictators v1.3.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/dwcobra3.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Energy Equipment 1.02.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/ettBeaconLauncher.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Executive Spaceways v2.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/flying_Dutchman.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Fuel Station 1.01a.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Fuel Tank v2.0.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/FuelCollectorV0.06.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/ghostsfromthepast.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/glow_alloy.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Hud.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/impcourier2.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/interstellar_help.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/jabberwocky.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/military Fiasco 2.4.1.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Missile Analyser 1.1.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Missiles and Bombs v2.0.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Missionaries.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/mycobra35.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/new 1.72 only AI.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/nuke.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/oldships.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Ore_processor.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/outrider.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/PAGroove_Stations_v1.2.1.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Pods 1.02.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/RandomHits.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/renegades.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/SecondWave 1.1.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/sell_equipment.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/Status_Quo_Q-bomb.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/sunskimmers.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/System_Redux.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/thargoid_carrier3.0.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/tiger.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/total_patrol.oxp",
"/Applications/Spiele/Oolite 1.72.2/AddOns/transports 2.46.oxp"
)
[dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.
[shipData.load.begin]: Loading ship data...
[script.load.world.listAll]: Loaded 38 world scripts: "Anarchies" 2.2, "assassins", "AsteroidStorm" 3.43, "Banks" 1.0, "behemoth" 2.4, "bigtrader" 1.0, "biosphere_appearance", "Bounty Scanner" 1.03, "buoyRepair" 1.02.1, "Cargo_test", "Cataclysm" 1.2, "communist_population", "dictatorship_population", "EE_EEU.js" 1.0, "ExecutiveFlightSchedule", "Flying Dutchman" 1.5, "Fuel Collector" 0.06, "FuelStation-Setup" 1.00, "ghosts_from_the_past", "hardpirates", "interstellar_help" 2.0, "JSversion" 0.9, "military_fiasco" 2.4, "missile_analyser" 1.1, "missionary_show", "newskim", "oolite-cloaking-device" 1.72.2, "oolite-constrictor-hunt" 1.72.2, "oolite-nova" 1.72.2, "oolite-thargoid-plans" 1.72.2, "oolite-trumbles" 1.72.2, "Random_Hits", "rmb-chaff-setup-script.js" 1.0, "sell_equipment" 1.3, "System Redux" 1.2, "thargoidcarrier" 3.0, "total_patrol" 1.1, "transportSchedule" 2.46

Posted: **Wed Aug 19, 2009 6:08 am**

Another Mac vs PC difference? And possibly a fairly important one for debugging?

Posted: **Wed Aug 19, 2009 6:13 am**

Well, for me OXPs have always been shown in alphabetical order, similar to something like this:

Code: Select all

[searchPaths.dumpAll] ResourceManager.m:212: ---> OXP search paths:
(Resources, ../AddOns, ../AddOns/Anarchies1.0.oxp, ../AddOns/arachnid.oxp, ../AddOns/behemoth.oxp, "../AddOns/BigShips 1.01.oxp", ../AddOns/BountyScanner.oxp, ../AddOns/caduceus.oxp, ../AddOns/Cataclysm.oxp, ../AddOns/Debug.oxp, ../AddOns/dodo_stations.oxp, ../AddOns/dreams01beta.oxp, ../AddOns/dwcobra3.oxp, ../AddOns/Falcon.oxp, "../AddOns/Fuel Station 1.11.oxp", ../AddOns/Galactic_Navy.oxp, ../AddOns/griff_adder_normalmapped.oxp, "../AddOns/griff_boa-normalmap-test.oxp", ../AddOns/griff_boa.oxp, ../AddOns/griff_cobra3.oxp, ../AddOns/griff_coriolis_normalMapped.oxp, ../AddOns/Griff_Debris_sets135_no_normal_map.oxp, ../AddOns/griff_normalmapped_cobra_1.oxp, ../AddOns/griff_normalmapped_ferdelance.oxp, ../AddOns/griff_normalmapped_newkrait.oxp, ../AddOns/griff_normalmapped_thargoid.oxp, ../AddOns/griff_normalmapped_worm.oxp, ../AddOns/griff_sidewinder_normalmapped.oxp, ../AddOns/griff_viper_normal_mapped.oxp, ../AddOns/Llama.oxp, "../AddOns/Missile Analyser.oxp", ../AddOns/missiles.oxp, "../AddOns/nukes(testversion).oxp", "../AddOns/Planetfall 1.09 Beta.oxp", ../AddOns/racers.oxp, ../AddOns/ramon_anaconda.oxp, ../AddOns/scripttest.oxp, ../AddOns/System_Redux.oxp)

I am not sure why your OXP list is not ordered alphabetically Thargoid, I have never seen it like this on my system, or any other system that I can remember, for that matter.

Posted: **Wed Aug 19, 2009 7:38 am**

another_commander wrote:
I am not sure why your OXP list is not ordered alphabetically Thargoid, I have never seen it like this on my system, or any other system that I can remember, for that matter.

I also have only seen the alphabetical order, but I can imagine that oolite is not sorting them but just uses the order in which the file manager offers the files. And that is mostly sorted.
On my old mac OS7 the file manager could use an external sort file. e.g. I had such an file that did not use the default ascii sort for numbers in filenames but value sorting. This custom sort was mainly because different languages uses different sorting for the special characters.

And on the mac you can use two different folders for your oxp's. Within a folder I see them sorted but a Z in the first folder still loads before the A in the second. So an oxp writer should never rely on the load order. And if it really wants to overwrite something he has to warn users that they should verify the load order for their system.

Posted: **Wed Aug 19, 2009 10:25 am**

another_commander wrote:
Well, for me OXPs have always been shown in alphabetical order, similar to something like this:
Code: Select all
[searchPaths.dumpAll] ResourceManager.m:212: ---> OXP search paths:
(Resources, ../AddOns, ../AddOns/Anarchies1.0.oxp, ...

Which now only leaves the question why on Earth you have such an outdated version installed?

The changelog since 1.0 goes almost from my place to yours (shameless exaggeration, but still:

version 2.2 (July 2009)
- fixed a bug with the Salvage Gang's shaders (thanks, another_commander and Griff!)

version 2.1 (January 2009)
- fixed a bug that would let Salvager Tuggers not appear in version 2.0
- fixed a bug with the Sentinel and Renegade Stations that would cause them to behave strangely when attacked

version 2.0 (January 2009)
- revised the Hacker Outpost model, closing the visible gaps around the tunnel exits
- tunnels in both Hacker Outpost and Salvage Gang replaced with models that use shaders (thanks, Griff!)
- docking bays in both Hacker Outpost and Salvage Gang replaced with Griff's models (ditto!)
- tweaked tugger model a little
- henchmen will no longer give the Hacker Outpost's location to everybody
- simplified the Hacker Outpost spawning
- Salvage Gang now aligning with the planet, and asteroid field spawned via ship script
- fixed a bug that would give the bribe offer too often
- fixed a bug that had replaced all Renegade Stations with Sentinel Stations in 1.1
- fixed a bug that would not initialise some processes if a new commander was started
- player's bounty now reduced 10% per jump if fugitive, instead of a 20 or 10 points
- salvaged equipment is now installed on buying, instead of waiting for launch
- equipment failure chance is now triggered through a timer, instead of a bunch of events; and now uses the new EquipmentInfo object
- there is also a chance now that salvaged equipment will work just fine, removing the failure possibility
- some minor tweaks in this readMe
- JS: replaced player.ship.bounty with player.bounty, which wasn't supported in Oolite 1.72
- JS: replaced all 'let' with 'var'
- requires now Oolite 1.72.1

version 1.1 (November 2008)
- the main script is now completely in JavaScript
- Hacker Outposts are now correctly facing the planet, via their new ship-script (thanks, Eric!)
- as a bonus also their Sentinel Asteroids are finally placed correctly and work (thanks, Eric!)
- added some flashers to the asteroid models
- AIs improved
- Hacker Outposts, Salvage Gangs and Renegade Stations have now their correct commodity prices
- requires Oolite 1.72

version 1.0 (February 2008)
- fully functional version
- requires Oolite 1.65

)

Posted: **Wed Aug 19, 2009 11:04 am**

Ehm... it's obviously because... you know.... well....

Thread locked.

No it's not, but the honest response is that I have no frakkin' idea