Oolite Bulletins

Posted: **Fri Jan 27, 2017 2:08 am**

This is notes for me, mostly. It helps me fix things in my head, but may be useful for others.

A couple of planets ago I did horrible things to a Leviathan involving a laser up the exhaust vent (I suspect this is the guilty OXP/Z for the next bit). After docking with a scooped tonne of slaves, I got a message about (blah blah) noises from the cargo hold (blah) unbrainwashed slave (blah) Nielson Peterling of Solageon (blah). Smells to me like it's a new mission generated by an OXP/Z, and I suspect the ex-Leviathan OZX/P that's doing it.
But how to confirm that? I'm guessing there are entries in various log files.

~/.Oolite/Logs/Latest.log
seems a good place to start.

Code: Select all

01:01:17.267 [LogEvents]: Player entered to the vicinity of [Planet position: (0, 0, 709720) radius: 64520 m]
01:01:20.495 [LogEvents]: Player VIEW_PORT
01:01:23.654 [LogEvents]: Player VIEW_FORWARD
01:01:23.819 [LogEvents]: Player entered to the aegis of Coriolis Station 5724
01:01:23.820 [script.javaScript.exception.unexpectedType]: ***** JavaScript exception (snoopers 2.5): TypeError: this.CRCNews is undefined

I wonder what is borked there.

Code: Select all

01:01:26.458 [LogEvents]: Player alert condition changed from 1 to 2
01:01:36.979 [LogEvents]: Player targeted Coriolis Station 5724 who has 25000 energy
01:01:41.652 [LogEvents]: Player got message from Coriolis Station 5724 : Docking authorized. You have an approach slot terminating at 2084881:16:03:35

docking (blah)

Code: Select all

01:02:24.375 [LogEvents]: Player gui screen will change from GUI_SCREEN_MAIN to GUI_SCREEN_STATUS
01:02:24.376 [LogEvents]: Player gui screen changed from GUI_SCREEN_MAIN to GUI_SCREEN_STATUS
01:02:26.119 [LogEvents]: Player gui screen changed from GUI_SCREEN_STATUS to GUI_SCREEN_REPORT
01:02:26.144 [LogEvents]: Player alert condition changed from 1 to 0
01:07:39.081 [LogEvents]: Taxi 16439 spawned at 1 km
01:10:59.313 [LogEvents]: Imperial Quaestor 81 spawned at 1 km
01:11:09.378 [LogEvents]: GalCop Viper 26094 spawned at 1 km
01:11:19.396 [LogEvents]: Imperial Quaestor 19004 spawned at 1 km
01:11:42.214 [LogEvents]: Adder 29239 spawned at 1 km
01:16:55.436 [LogEvents]: Imperial Quaestor 8368 spawned at 1 km
01:18:19.791 [LogEvents]: Gecko 20684 spawned at 1 km
01:18:29.809 [LogEvents]: Gecko 6256 spawned at 1 km
01:18:39.859 [LogEvents]: Sidewinder Scout Ship 13674 spawned at 1 km

So, I guess that's reports on the various data screens I saw about doing things to a Leviathan, then the slave thing. But no indication which OXP/Z. (Also stuff I hadn't really thought about about ships happening outside the station while I'm reading the screens.

Where to look next?
~/GNUstep/Applications/Oolite/oolite.app has lots of stuff, but nothing more recent than the installation.
~/GNUstep/Defaults/.GNUstepDefaults doesn't seem to have anything useful.
How about the current save-file? Well, there's lots of stuff in there, such as a list of places where there are Giant Space Pizzas - so that's looking more optimistic. but if I search for the slave's name ... nothing. The slave's planet however yields the following, which makes me suspicious that it's an UPS OXP/Z that's causing this, not the Leviathan-buggering OXP/Z :

Code: Select all

	<key>mission_ups_pplanet</key>
	<string>164</string>
	<key>mission_ups_slaverescue</key>
	<string>true</string>
	<key>mission_ups_slaves</key>
	<string>NO</string>
	<key>mission_ups_slplanet</key>
	<string>230</string>

That's enough for now. Seeing variables scattered around like that, I'm wondering if there is one hierarchy ("namespace"?) for OXP writers to drop their parameters into, or several, or none? But that's probably more about OXP-writing (not something I'm really into the idea of, at this time).

I'm assuming that the text of the initial data screen on docking - the (blah) about slave "Nielson Peterling of Solageon" is stored somewhere in a configuration file, but where should I look? I'm assuming somewhere under my user's "~" folder (well, I shouldn't be able to write into the install directory like "/usr" should I?) Time to shoot a few more Thargoids, then bed.

Posted: **Sat Jan 28, 2017 12:05 am**

The OXP in question would appear to be UPS Courier. I'm going to assume you have version 2 installed, as that version is (at least as far as I know) compatible with the current version of Oolite.

There is a mission in UPS Courier that involves rescued slaves, although the name might change with each player.

RockDoctor wrote:
Seeing variables scattered around like that, I'm wondering if there is one hierarchy ("namespace"?) for OXP writers to drop their parameters into

Yes, OXP writers store any mission-critical varaibles into something called "missionVariables". Anything saved in that object is reloaded with the saved game. All OXP's access this object the same way, so when looking at the save game file it can be quite messy. There shouldn't any need to view the save game file though, unless something's gone wrong. Did the mission not trigger? (Check your F5F5 screen and look for any instructions then on what you should be doing).

Posted: **Tue Jan 31, 2017 5:32 pm**

I've been away for the weekend - and in hindsight it's obvious that none of the people who have written the "planet tourist blurb" (F7) texts have any interest in hill-walking, since I can't recall a single planet advertised for it's "dramatic mountain views." Come to think of it, no skiing fans either. No adverts for sex tourism hotspots either - which strikes me as decidedly unrealistic given the amount of slave trading. Anyway.]

The OXP in question would appear to be UPS Courier. I'm going to assume you have version 2 installed,

That pack is certainly installed, but I'm on version 1.8.4, and the installation/ pack management system (whatever it's called) says that's "at the current version".
Hunting around in the save file, it now makes more sense. I found this block

Code: Select all

<key>mission_ups_slavename</key>
	<string>Neilson Peterling</string>
	<key>mission_ups_slaverescue</key>
	<string>true</string>

which does pin the events to that mission. The mission does seem to be working - I was just getting nosy. I'm also just a little concerned over having something like 95 expansion packs installed, and wondering where I'm going to encounter clashes between some things. (I'm used to breaking things.) One odd thing - not all of the variables follow the "mission_[pack name]_variable" format.

Code: Select all

	<key>ups_slaves</key>
	<string>Bring Neilson Peterling to Solageon.</string>

I guess that's a heritage of developing standards.
A bit of reading around in ~/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.EricWalch.UPSCourier.oxz shows me some interesting new quirks to the missions to come, which is the sort of thing I was hoping to get out if the exercise.

Posted: **Tue Jan 31, 2017 10:08 pm**

RockDoctor wrote:
That pack is certainly installed, but I'm on version 1.8.4

Ah. Version 2 is not yet available in the download manager - you have to manually install it. See this link for details: UPS Courier 2.0

RockDoctor wrote:
I'm also just a little concerned over having something like 95 expansion packs installed, and wondering where I'm going to encounter clashes between some things

Only 95? I don't think you're trying hard enough - I have over 200.

RockDoctor wrote:
One odd thing - not all of the variables follow the "mission_[pack name]_variable" format.

If it doesn't have the "mission_" prefix, then it's not a mission variable per-se. There are two things being recorded in the "mission_variables" part of the save file: mission variables themselves, and items that will be displayed on the F5F5 Manifest screen. The item you've highlighted is one of F5F5 manifest items.

Oolite Bulletins

How to identify which OX(P|Z) provides an in-game message.

How to identify which OX(P|Z) provides an in-game message.

Re: How to identify which OX(P|Z) provides an in-game message.

Re: How to identify which OX(P|Z) provides an in-game message.

Re: How to identify which OX(P|Z) provides an in-game message.