Can't scoop escape pod

[*cat]

Running 1.71.2 on OS 10.4.
Encountered (near a station) an escape capsule that was yellow on the radar rather than white. The ID said "Escape Capsule". Tried to scoop it anyway, but I just bashed it (towards the planet actually... oops). It didn't blow up thoug - just hurtled planetwards...
I'm running lots of OXPs - I think I was in the midst of the first Galactic Navy police mission.

[TGHC]

Was your cargo hold full?

[TGHC]

Perhaps your cargo hold was full.

[Eric Walch]

Encountered (near a station) an escape capsule that was yellow on the radar rather than white. The ID said "Escape Capsule". Tried to scoop it anyway, but I just bashed it ....

This is a bug in an OXP. Only when it is white it is seen as cargo by the system. Not all white things can be scooped but a yellow thing has for sure no scanClass cargo.

[Commander McLane]

The only problem is to find out which OXP the bug stems from...

@ *cat: If you feel like hunting, then you should open the shipdata.plists in all your OXPs and look for an entry which is by name and/or roll an escape pod, but lacks the following key:

Code: Select all

          <key>scanClass</key>
          <string>CLASS_CARGO</string>

If it also lacks a like_ship-key that points to an entry with the correct scanClass, then you have your prime suspect.

In that case it would be nice to report your findings here, so that the OXP in question can be corrected. As you already guessed, inserting the missing

Code: Select all

          <key>scanClass</key>
          <string>CLASS_CARGO</string>

will do the trick.

[Eric Walch]

@ *cat: If you feel like hunting, then you should open the shipdata.plists in all your OXPs and look for an entry which is by name and/or roll an escape pod, but lacks the following key:

It is probably not this what is happening. I think a script adds a default escape-pod from the internal set. There no scanclass is set and it gets the default one. So I think you must look for a script that adds such a pod that has not defined it in shipData. A difficult search. Most likely it is an script in death_actions of a ship.

[Commander McLane]

Ah, you're right, Eric.

@ *cat: So this means that you still would have to open the shipdata.plists, but then search for death_actions-arrays. If there is one that contains either of the following lines

Code: Select all

               <string>spawn: escape-capsule 1</string>

or

Code: Select all

               <string>spawn: oolite-escape-capsule 1</string>

then it is your prime suspect (the number in the end could also be more than 1; in that case there would be more than one escape pod created).

Only the fix is a little more complicated. You need to create a custom escape pod, which means a new entry in the shipdata.plist in question. It should be called OXPname-escape-capsule (OXPname being the name of the OXP whose shipdata you are working on) and contain three entries: a like_ship, pointing to the default escape-capsule, a new custom role (preferably OXPname-escape-capsule), and the entry that sets the scanClass correctly. The whole thing looks like this:

Code: Select all

     <key>OXPname-escape-capsule</key>
     <dict>
          <key>like_ship</key>
          <string>escape-capsule</string>
          <key>roles</key>
          <string>OXPname-escape-capsule</string>
          <key>scanClass</key>
          <string>CLASS_CARGO</string>
     </dict>

Then you have to return to the death_actions, and replace the "escape-capsule" or "oolite-escape-capsule" (whatever is there) with your freshly created "OXPname-escape-capsule".

And, of course, report to the board where the bug is located.

[*cat]

Urkh! That sounds like some kind of Unix search... maybe even.... gasp ...regex!
Anyone got an idea for a grep(?) command that'll search inside the OXP packages on a 10.4 mac?
Cheers
- Paddy

[Commander McLane]

AFAIK Spotlight does generally not search inside packages (it doesn't on my machine).

So, as far as bug-squashing in OXPs is concerned, I don't really see a way around opening the packages and the plists themselves, and then searching the plists with an editor (that's at least what I am doing all the time).

Of course I would be very happy to be pointed at a more efficient method, because this one-by-one approach tends to be quite time-consuming.

[Rimbaud]

In 1.71.2 on Mac, several times I have fired an ECM hardened missile, which actually launched an escape pod instead! This was the normal missile colour and couldn't be scooped.

[Commander McLane]

In 1.71.2 on Mac, several times I have fired an ECM hardened missile, which actually launched an escape pod instead! This was the normal missile colour and couldn't be scooped.

This seems to be another case of the wrong-ship-being-spawned bug that is already known for 1.71.2. Although the reported cases so far usually were boulders being spawned instead of cargo, I think.