Unknown keys

[Chaky]

As I was goung through those logs I posted earlier today, I can't help but to think that alot of OXP makers are using non-existing keys:

has_energy_unit
likely_scavengers
port_weapon_type
starboard_weapon_type


.. the list goes on and on.

[Commander McLane]

Yes, there are many guys who just work on "The Principle of Hope".

So they come up with keys of themselves, just hoping that they might actually do something (I think Charlie was particularly fond of this, but I could be wrong).

Anyway, apart from creating error messages with the OXP verifyer, non-existing keys don't do any actual harm. So it is not a very urgent problem.

[Thargoid]

A number are also due to like_ship and is_template. The use of the former for example to make player ships from NPC ships (or vice-versa) can introduce invalid keys into one from the other. And is_template doesn't seem to be parsed correctly at the moment, for example on name key requirements and such.

But as McLane correctly says, in most cases it's nothing to worry about. Although there are some in the logs which are genuine errors (bouy rather than buoy in a couple of places for example).

[Eric Walch]

As I was goung through those logs I posted earlier today, I can't help but to think that alot of OXP makers are using non-existing keys:

has_energy_unit
likely_scavengers
port_weapon_type
starboard_weapon_type.

As others already remarked, most warnings are harmless. Some, like "max_missiles" and "port_weapon_type" were even present in oolite 1.65 own shipdata for npc ships. And I assume a lot of ship creators just copied those entries not realising those keys were not used in the original. And even when it was known that they were not used, there could have been future plans to use them so they were just added to be on the sure side. The shipdata.plist on the wiki is only 3 years old. Before ship designers had no real database that contained valid keys so most were just copied from existing work and others were just added because of likelihood with existing keys.

Even when the most are harmless, your list does contain some more serious errors and all real errors/warnings should be removed on a next release of those oxp's.

[Chaky]

Well, since "is_template" doesn't get parsed, I can't really trust OXP-Verify code, right?

I intend to implement shipdata.plist-purging feature to my baby and use OXP-Verify as internal check.

Since there are allot of benign warnings (like "max_missiles not used for this kind of ship") that clog the logs, I want to make it automatically purge as much as possible those ever-repeating errors, leaving "real" problems to be solved manually.

The problem is, it is not reliable as it should be, and I don't want to make a piece of code that kills OXPs...

[JensAyton]

Contributions welcome. ;-)

[Chaky]

Another valid key not parsed:

scan_class

[JensAyton]

Another valid key not parsed:

scan_class

Fixed in r2754.

[Chaky]

Fixed in r2754.

Thanks for the info.


Seems like the "principal of hope" applies to "scanClass" types too.. and heavly.

CLASS_HOSTILE
CLASS_MINE
CLASS_NEUTRAL
CLASS_NONE
CLASS_SHIP
...

[Eric Walch]

Seems like the "principal of hope" applies to "scanClass" types too.. and heavly.
...

CLASS_MINE and CLASS_NEUTRAL are real scan classes. CLASS_MINE does definitely set the correct scan_class for a mine and is needed when spawning a mine by script. And CLASS_NEUTRAL is just the default value (yellow lollypops) when no class is defined so it is not needed.

There are probably much more things missing as that file used by the verifier is not really updated recently while a lot of new keys were added.

[Chaky]

In that case Wikipages should be updated...
.. and OXP Verify code, for that matter.

OXP Verify mentions "CLASS_NOT_SET" as valid scan class. Same as "NEUTRAL"?

[Eric Walch]

In that case Wikipages should be updated...
.. and OXP Verify code, for that matter.

OXP Verify mentions "CLASS_NOT_SET" as valid scan class. Same as "NEUTRAL"?

No, with CLASS_NOT_SET you don't get the "clean/hostile" status.

[JensAyton]

Actually, the default is not CLASS_NEUTRAL, it’s CLASS_NOT_SET. There are several classes which can be set here but which are not supported, and which may cause problems if used. The supported classes are:

• CLASS_NOT_SET
• CLASS_BUOY
• CLASS_CARGO
• CLASS_MILITARY
• CLASS_MISSILE
• CLASS_POLICE
• CLASS_ROCK
• CLASS_STATION
• CLASS_THARGOID

Note: CLASS_MINE is not on the list because a mine’s class is always set when it’s launched, but a missile doesn’t have to be CLASS_MISSILE (notably, it can be CLASS_THARGOID).

[Chaky]

So, if someone is to make a ship with "CLASS_MISSILE" as scan class, it will not be shown as missile on scanner?.. or does that apply only to entries with role "missile"?

What if missile with scan class of, say, "CLASS_NOT_SET" is used? Will that still be shown as missile on scanner?

[JensAyton]

So, if someone is to make a ship with "CLASS_MISSILE" as scan class, it will not be shown as missile on scanner?.. or does that apply only to entries with role "missile"?

As it stands, I believe it will.

What if missile with scan class of, say, "CLASS_NOT_SET" is used? Will that still be shown as missile on scanner?

That would invoke undefined behaviour. (It would be sensible for CLASS_NOT_SET to be treated as CLASS_MISSILE when a missile is launched, but it isn’t currently. It looks as though it would currently be yellow on the scanner.)