Entities with crews bug

[another_commander]

There have been some reports in the past of scripted cargo pods not working correctly. This is what Eric had posted here some time ago:

So I added the key cargo_carried and as content computers. This function was added in version 1.63. It works well with containers added by the system, but those added in a private role always say on scooping: captured a slave or captured "slavename". When I however look in inventory, one ton of computers is added and no slaves. And on docking I also get the insurance message of a captured slave.
If I shoot a competing ship that had already scooped some of those containers and get them back I get the same behavior.

I already tried setting "unpiloted" to yes, no and completely removed it.

You can repeat the bug by using Cargo_Wreck_Teaser. That OXP uses the cargo_carried command in the Gemspod and the Goldpod. Both can be invoked by adding a ship with role: Gold or Gemstones. It can be done very nice with the debugMenue.OXP in oolite 1.69.1

I just wanted to let you know that this has now been fixed. The problem was that when added to the universe, scripted ship entities without crews would be assigned one regardless of what they were. This way, cargo pods would have crews, boulders would have crews and so on. The result was exactly the symptom Eric described.

So, from now on ship entities which are of scan class CARGO or ROCK or entities with the unpiloted key set to true, will not get crews. Because of this change, commsMessage also now works slightly differently: No script added unpiloted entity can transmit messages any more. So if you want your scripted ship to send a commsMessage, be sure that it has crew assigned. I am currently looking at ways to have unpiloted ships send commsMessages, too.

[LittleBear]

Would just an unpiolted false be enough or will it need a particular pilot? The marks escape craft are cargo scripted items spawned with death_actions and send commsMessages pleading etc when lasered. I gave then scan_class cargo so they could be scooped and captured.

[another_commander]

You can give them the key pilot in their shipdata.plist definition. If you see how Oolite does it for the constictor, you will see this in shipdata:

Code: Select all

pilot = "constrictor-mission-thief";

. The string describes a game character that Oolite recognizes as a "special case". A character.plist would be needed to describe the pilot and I think, in the case of Random Hits, it would be exactly what you need. Any ship with a pilot already defined in shipdata, will get assigned crew on initialization, so you should be fine even if you set its scan class to cargo. Comms messages would be also transmitted without problem because crew would be already there.

Try it and let me know if you have issues. I understand that what I changed can affect a lot of unforseen things, but I believe that up to now there have been plenty oxps relying on buggy behavior. At the end of the day, if we hit a wall, I can always undo the changes and try a different approach, now that we know what is wrong with the crew system.

[another_commander]

Here is a small example of what a pilot entry in characters.plist might look like. Using this, I have tested with spawned cargopods, one with Trumble Cargopilot as crew, the other without crew. Both worked as expected and I scooped up Mr. Trumble Cargopilot successfully.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>cargo-test-pilot</key>
	<dict>
		<key>random_seed</key>
		<string>1 3 5 7 11 13</string><!-- fix the name and details, but use the key to keep it secret -->
		<key>bounty</key>
		<integer>30</integer><!-- not actually used, we do the reward in the script -->
		<key>origin</key>
		<integer>7</integer><!-- system number seven (Lave in Galaxy 0) -->
		<key>name</key>
		<string>Trumble Cargopilot</string>
	</dict>
</dict>
</plist>

To use it, enter the string "cargo-test-pilot" in the pilot key at shipdata.plist for any ship you need crewed, regardless of scan class.

Obviously, you may want to make some adjustments to make it fit with Random Hits, but this should be OK to see how it can be done.

[Eric Walch]

So, from now on ship entities which are of scan class CARGO or ROCK or entities with the unpiloted key set to true, will not get crews. Because of this change, commsMessage also now works slightly differently: No script added unpiloted entity can transmit messages any more. So if you want your scripted ship to send a commsMessage, be sure that it has crew assigned.

Good to hear. I'll look through my own OXP and change some to piloted when they need to send a message. My earlier escape pods had scripted items. Later on in the slave missions I used plain pods with cargo set to slaves, without a script, but with a scripted pilot. That works better as scooping him will add to the cargo slaves and that way needs storage room. Looks better and the storage room is cleared on docking. Only problem is that scripts now execute on docking, not on scooping. But that was no problem in my case.

Would just an unpiolted false be enough or will it need a particular pilot?

Will be enough. But see also the "Character.plist" entry on the wiki for piloted ships: http://wiki.alioth.net/index.php/Characters.plist

[Eric Walch]

Another_Commander,
There is still a related bug present. I was never able to create ships that had cargo. I only could eject cargo with a scripted ship by spawning cargo pods.

The problem is that the "cargo_flag" is set only for ships added by the system populator, not for scripted ships.

e.g: CARGO_FLAG_NONE, CARGO_FLAG_FULL_UNIFORM, CARGO_FLAG_FULL_PLENTIFUL, CARGO_FLAG_FULL_SCARCE, CARGO_FLAG_PIRATE, CARGO_FLAG_CANISTERS

As you know, all traders are cheating. At introduction into the system they get a cargo_flag set, but actually remain empty. I do not know if it is to save interstellar fuel, or just to same computer memory. Probably the first as interstellar fuel is expensive and RAM is cheap.

Only when the command "ejectCargo" is issued, it actually generates the cargo for that ship and ejects it. The same happens when a ship blows up. Only at that time cargo is generated based on those flags. Also when a ship scoops his first barrel, all predefined cargo is rejected and the ship holds from this moment only the actual scooped cargo and cargo flag is set to: CARGO_FLAG_CANISTERS.
With ships added with a "addSystemShips:" or similar, the cargo_flag is not set and nothing gets ejected on destruction. (only scooped items will be ejected). Cargo_flag of those ships should probably become: CARGO_FLAG_FULL_PLENTIFUL on adding.

This will change behaviour of some existing script added ships that never did eject cargo, but had cargo defined in shipData.plist. But it would be good to let them also behave the same way as system generated ships.