Oolite Bulletins

Update on the property list situation: rather than having a separate tool, future versions of Oolite will log error messages for bad plists. The actual error messages come from the Foundation framework, and will thus differ between OS X and GNUstep. Under OS X, they look like this: This particular message is misleading: the actual problem is that there are two <key> elements in a row. (The same problem exists in bandersnatch.oxp’s shipdata.plist and Cargo_wrecks_teaser.oxp’s shipdata.plist.) The most important thing, though, is that it provides a line number, so you know where to look.

The home-grown parser bit: currently Oolite tries to use Foundation, then falls back on a custom XML property list parser. This was introduced a while back, when GNUstep under Windows had problems with them. This is no longer the case, so we intended to remove the custom parser. However, it turns out that the custom one accepts some malformed plists – notably, the ones with the problem mentioned above – so it will be kept around at least into the next major version. However, it will eventually be removed to reduce code complexity, so if your OXP causes a message like this in the next version of Oolite, fix it.

I’m still considering the idea of using a single plist parser on all platforms. This won’t be in the next release, but the work done to provide error messages will make it simpler.

I actually found that the oolite stderr file mentions such shiplists when it encounters another more fatal error, like a non-NSdict AI. It then mentions the shipdata file in OXp so and so is not a correct NSdict.
(But uses it just fine as you mentioned earlier.)

Now that I know about the wrex foulup, I'll certainly look at it again.
(and add some of the long awaited wrex maybe)

---
Can't see any wrong syntax...
unless it is wrong code like:

<key>cargo_type</key>
<string>CARGO_THARGOID</string>

or

<key>cargo_type</key>
<string>CARGO_CARRIED</string>
<key>cargo_carried</key>
<string>20 gemstones</string>

that causes the error?

My mistake, the problem with cargo_wrecks_teaser wasn’t the one I thought it was. In fact, the problem is that it ends with “</plist>>”, with an extra >.

Ahruman wrote:

My mistake, the problem with cargo_wrecks_teaser wasn’t the one I thought it was. In fact, the problem is that it ends with “</plist>>”, with an extra >.

Mine doesn't. And I got it from Oosat 2 (before it broke down). So probably A_H had already fixed that?

But as we speak of it, I have another problem with Cargo_wrecks_teaser.oxp: The special cargoes don't work with my Oolite (1.65, Mac OS X 10.4.7). There are some special items defined in descriptions.plist and also in the shipdata. But whenever I scoop one of these I don't get a screen message like "1 t Synth-e-meat". Instead it's just "Cargo cannister scooped" or something like that. What could cause that?

Dunno...haven't looked at that bit of code in a while.
I was actually waiting for Giles to fix the problems with custom cargo.

I'll look into it. (May need to change the commsMessage to scanForNearestMerchantman+setTargetToFoundTarget+commsMessageTarget.)
I think the pod as is will (should) send comms to player irrespective whether he/she scooped it or an NPC.

Whaddya know, [my copy of] cargo_wrecks_teaser does have the problem I originally thought it did. Lines 317 to 320 need rearranging:

I'll see tonight if [my] copy has the same copy-paste mistake.
edit: nope.

<key>hexapod_b</key>
<dict>
<key>like_ship</key>
<string>hexapod</string>
<key>roles</key>
<string>cargopod(0.5)</string>
<key>model</key>
<string>cargo6b.dat</string>
</dict>

The end of the script is correct too.
You must have gotten one of the first releases of IT.
Please re-download from Oosat2... or wikisat?
I hope It was repaired with the latest version, otherwise I'll upload it again.
or try

http://home.tiscali.nl/arexack/arexack/ ... r_v1.2.zip
on my personal webspace.
(it has a readmeifyouplease.txt.txt file, which is probably hidden in the OXP folder. (sorry mac-users) )

I'd like to see if there is anything I can do for Oolite code-wise at a deeper level then plist/xml scripting.

Please, some info on Oolite-code?

-What is the program language?
python? Trying to learn that.
-I remember there is sourcecode available someplace... SourceForge? debian?
Ah: Aigidian download links. binaries.


I haven't got any programming background, save what gleamings I learned of python. (plus a bit of C=64 BASIC )
So can I be of service in some (small) way?
If so: where to start?

Oolite is written in Objective-C, which is a simple superset of C.

The source code is available from BerliOS.

know nothing about C++ or ooC.
(ook? )
I think I'll stick to learning python and Java for now.

I assume deep code requires in-depth knowledge of the language, so i won't be any use anyhow.

Okay.

Just a thought to make dependencies somewhat easier to manage (amongst OXPs)

Would it be a smart idea to have each and every OXP have a
script that does something like: It would make it much easier to check (within OXP code) whether an OXP is installed and then take an alternative option if not.

p.s. Maybe the 'requires.plist' file has a more adequate function, I do not understand it fully.

requires.plist can currently only be used for a version check. Additionally, starting with 1.69, any entries other than version will cause an OXP to be rejected (allowing for new types of compatibility checking to be added in future).

Incidentally, the type of set-up you’re doing can be done in JavaScript as follows: The advantage here is that it’s not done over and over again, only when actually necessary.</propaganda> ;-)

I’d go with something like mission_NAME_OF_OXP_INSTALLED set to "YES" (missionVariables.NAME_OF_OXP_INSTALLED in JS), though.

It shouldn't be a check for INSTALLED only, though.

IIRC someone (Murgh?, Cmdr Wombat?, I forgot) has proposed something similar a long time ago, but with a slight difference: The mission_variable should also give an information whether your OXP is finished or still running and therefore doing something. If the player has e.g. finished Ionics, the OXP won't do anything anymore. So no conflicting screens. No need to take care. The pure check for is Ionics installed? won't reveal that.

On the other hand there are non-ending OXPs like Thargoid Wars. There you only need to check whether they are installed.

Oh, another thing… mission variables are stored in saved games, so if you save, uninstall, and load, you’ll have the variable set despite the OXP not being there.

Most OXP's that end,
have a checkformissionstage variable that is set to stageX when running and COMPLETED when the oxp is finished.
So that functionality is already there.
The code is still evaluated, but never executed as the mission_flag is set to COMPLETED instead of undefined or other.


mission_installed is just for compatability reasons.
(eg you need the models of One.OXP and know that second.oxp has a compatibility problem. In case-one message player about the missing OXP or use alternative models. In case 2 message player about the problem and have him deal with it.)
...Or package an alternative (fixed) script.plist for the offending OXP ofcourse and notify the OXP-author. Although fixing is not always possible.

@ahruman: you are right, the variable won't reset after de-installation. :/
your java method seems to be checked everytime the game starts up.