Split: Cargo bug

[Eric Walch]

I like that.


About Eric Walch not being able to reproduce the Disembodied bug - from reading it seemed to occur when along with the escape pods one ton of slaves was scooped in a cargo pod, not escape pod ?

That would be another possibility, but I never have encountered a bug with missing cargo before. The only theoretical possibility is to define a pilot in the character.plist and give that pilot a script. Only pilots with a script attached don't award slaves themselves, but make the script responsible for it. But character.plists are rare, and those with scripts even rarer. Thus very unlikely.

In the mean time have I my code working. Not yet with a definitive message, that will be a next step.

To get the pilots faster, I defined a console macro that first awarded an escape-pod to the ship, and than ejected the pilot. That way I even got pilots from ships that originally had no pod to eject.

Interestingly I found two new bugs that way:

1) When the ship had a custom escope-pod defined in its shipdata, but that pod did not exist because of a spelling error, no pod at all was released. Instead an error was logged. Fixed now by falling back to the default escape-pod in such cases.

2) When ejecting a pilot from an escort, nearby the station aegis, the empty escorts were never removed from the mothers group. So when mom entered the aegis, it gave all its escorts an dockingAI, including the abandoned ships. The hulks suddenly started flying again! Fixed now.

[Svengali]

1) When the ship had a custom escope-pod defined in its shipdata, but that pod did not exist because of a spelling error, no pod at all was released. Instead an error was logged. Fixed now by falling back to the default escape-pod in such cases.

Does Oolite still give an error/warning then? Without entry in Latest.log it will be hard to spot.

[Eric Walch]

1) When the ship had a custom escope-pod defined in its shipdata, but that pod did not exist because of a spelling error, no pod at all was released. Instead an error was logged. Fixed now by falling back to the default escape-pod in such cases.

Does Oolite still give an error/warning then? Without entry in Latest.log it will be hard to spot.

Added a warning about wrong "escape_pod_model" in combination with ship dump now because you are right.
I had the warning:

Code: Select all

 [ShipEntity.abandonShip.notPossible]: Ship <ShipEntity 0x101f34a00>{"Boa Class Cruiser" position: (-36563.8, 76277.9, 417979) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT} cannot be abandoned at this time.

regularly in my log during the past months, but never could find the culprit. I even added extra code in my trunk version to find the ship. Without success. Only today when I explicit targeted a ship and no pilot ejected but the error appeared in my log, I knew what ship it was. (I have a lot of oxps with boas installed) And when seeing it had a custom pod defined made things immediately clear to me.

[Switeck]

"Boa Class Cruiser" ...cannot be abandoned at this time.

Sounds like Boa Class Cruisers are getting "punked" pretty often as well.
Unless you've got some special OXPs installed, those are almost certainly non-pirate ships...so something pretty nasty is probably hitting them.
Only times I see Boa 2's die tends to be when they're grossly outnumbered or they run into something.

What kind of meat-grinder do you have going on in your game?

[Eric Walch]

"Boa Class Cruiser" ...cannot be abandoned at this time.

Sounds like Boa Class Cruisers are getting "punked" pretty often as well....
What kind of meat-grinder do you have going on in your game?

It was the boa from Neolite.oxp.
I didn't like that is was replacing the core ships, so I renamed all the ship-keys to unique names. This way I have the neolites alongside existing ships, instead of replacing the existing ships. Somehow I made a name-error with the escape_pod_model used by that specific ship. Because defining an escape_pod_model in current ships is very rare, I didn't think at that cause for the problem.

Back to pods with both bounty and insurance. Trader pilots should already have their bounty cleared according to the code. Maybe I did get the escort pilot when I got the inconsistent message. I fact most pilots for ships in populator roles get either the bounty or the insurance cleared after character generation. So both values present should only happen for ships in custom roles, escorts and original clean pilots ejecting from a ship with a bounty.

On the subject of messages for pilots with both insurance and bounty I used both Pagrooves version and one I had in mind:

Code: Select all

	"rescue-reward-for-@@-@-credits-@-alt" = (
							"For rescuing %@, %@, their insurance pays %@ ₢. This includes a %@ ₢ bribe for clearing the offender status.\n",
							"Police officers are waiting for %@, %@, but after a hasty discussion and an exchange of Credits they depart. Insurance pays you %@ ₢. (%@ ₢ went into the bribe).\n"
							);
	"capture-reward-for-@@-@-credits-@-alt" = (
							"For capturing %@, %@, you’re paid a bounty of %@ ₢. The insurance fee of %@ goes to governmental taxes.\n",
							"Police officers escort the loudly protesting %@, %@, away. You receive a bounty chit worth %@ ₢ instead of an insurance payment of %@ ₢.\n"
							);

On screen it gives one line more. Maybe a bit verbose when it appears often, but these messages will be rare, so being a bit longer seems no real problem. And by using two alternatives, you get some variation. The code is replacing the "%@" occurrences with calculated strings. The first 3 always were there and the 4th is newly added. In case an insurance is paid, the bounty is subtracted first. (I just call it "bribe" so there is no relation to a bounty for the reader. A higher bounty just means that it takes a higher bribe to keep the pilot out of prison). In the unlikely case that this value would become negative, you get the other message instead that pays the full bounty.