hostile cargopods

[Commander McLane]

I think I've hunted the bug down which sometimes creates offender or fugitive cargopods.

The problem is that scanClass is not automatically inherited through like_ship. And all pods in both Cargo_and_wrecks.oxp and Pods.oxp, which have a like_ship key, are missing the scanClass key.

This is no problem, as long as the cargopods are created by the game engine from a dying ship. But if--as is the case with personalities.oxp and some other OXPs--cargopods are spawned via script, the ones with no explicitely defined scanClass get CLASS_NEUTRAL.

The solution is that all cargopods should explicitely get scanClass CLASS_CARGO.

Generally all shipdata-entries should always have their scanClass explicitely set, if it is not the default CLASS_NEUTRAL, even if they are like_shipped from another entry.

[Thargoid]

I'm planning to update pods.oxp at the weekend anyway (add the extra roles we discussed previously), so I'll drop the scanClass key into them too whilst I'm at it.

[Micha]

The problem is that scanClass is not automatically inherited through like_ship.

I believe there is an effort underway to ensure that -every- key is inherited through like_ship.

[Eric Walch]

I think I've hunted the bug down which sometimes creates offender or fugitive cargopods.

The problem is that scanClass is not automatically inherited through like_ship. And all pods in both Cargo_and_wrecks.oxp and Pods.oxp, which have a like_ship key, are missing the scanClass key..

I have never seen anything wrong with the like_ship key. I have spawn a lot of such pods in the past without seeing ever any problem.

I just created a role for such a pod and used:

Code: Select all

> player.ship.spawn("alienpod2")
[Ship "Alien cargo" ID: 296 position: (54355.7, -27945.8, 356408) scanClass: CLASS_CARGO status: STATUS_IN_FLIGHT]

The CLASS_CARGO was not defined in the ship data but inherited with like_ship. It is more likely you are referring to pods without any defined scanClass at al.

[Commander McLane]

I somehow think that scanClass is different from the other shipdata keys, because it sometimes is set by the populator according to how the ship is spawned (like ai_type). I had a couple of instances before, where I created a clone of an existing ship and spawned it, but it got a scanClass different from the one I had expected. Setting it explicitely in its entry, and not relying on the one that should be inherited, always solved the problem.

I don't know what exactly is happening here internally, but I think the bottom line is that the scanClass key should be mandatory for every entity.

[Micha]

I somehow think that scanClass is different from the other shipdata keys, because it sometimes is set by the populator according to how the ship is spawned
<...>
the scanClass key should be mandatory for every entity.

I think the code should be checked and as long as nothing -relies- on the internal code generating a (semi-random?) scan-class for like_ship'd entities to function correctly then the code should be modified such that if the entity or its like_ship-parent entity supplies SCAN_CLASS then that SCAN_CLASS should be used instead of one being generated.

IMHO a like_ship'd entity should be exactly like the parent except for whatever is overridden. Having some entries mandatory and others inherited makes no sense (to me).

I'm happy to take a look at this but won't get a chance till next week.

[JensAyton]

Every key is inherited through like_ship, except display_name and is_template.

is_template is not inherited because it relates to the inheritance system itself and inheriting it would make no sense.

display_name is not inherited because if B inherits from A, and A has a display_name through a shipdata-overrides.plist in a localization OXP, B’s name should not be overridden. (It could be reasonably argued that B should inherit display_name if it doesn’t have an explicit name, but that is currently not the case.)