scannerDisplayColor

[jh145]

Something's up with the four variables named like ship.scanner*DisplayColor*.

First: if I set(*) SDC1 to null and SDC2 to "darkGrayColor" then the lollipop is displayed solid dark grey irrespective of the ship's default SDC1 (which might be yellow). The docs suggest I should get flashing yellow (picked up as a default for SDC1) / dark grey (specified by me). I can't imagine it would break many OXPs to fix this, would it? -- I mean to decree that an unset SDC value falls back to the default in the shipdata or for the scan class.

Second: if I set(*) either SDC (but leave the scannerHostileDisplayColors untouched) then, when the targets go hostile, they don't change to their hostile orange colour; they stay using the non-hostile colours that I set!

Have I messed up, or are these bugs?

(*) set X == get my world script to alter the X property of a Ship encountered in-flight; I'm not modifying shipdata.plist or anything like that.

[another_commander]

Not entirely sure about the second (need to test), but for the first one I believe the docs are wrong. If either color is defined, the lollipop should get that color, otherwise we fall through to the defaults.

[jh145]

Sure, what you say re the first is consistent with the code, but it's inconvenient if you want flashing usual-colour-1 / dark-grey. I can't think of a good way of achieving that; can you? It might be better if null => use what's specified (or implied) by shipdata.plist and to have those Ship.scanner*displayColor* variables populated initially with non-null values.

The second surprised me too. If your testing contradicts mine, I'll try to come up with a minimal example for comparison.

[another_commander]

Well, normally usual color is the scan class color, so you can get that when the ship spawns and map the scan class to standard colors (i.e CLASS_NEUTRAL -> yellow). That would be your scannerDisplayColor1. Then set scanerDisplayColor2 to whatever you want. If you want to cover all cases, you can also make a check for pre-scripted scanner colors before checking the scan class.

Regarding the second point, I confirm your observation. The code seems to be specifically written to do what you are observing, but it does seem odd. Maybe one to look at, but I wouldn't call a stop for release if it doesn't get fixed in time. We need to keep in mind that there are already OXPs using these properties as they are now and changing this at this moment may break them.

[jh145]

Well, normally usual color is the scan class color, so you can get that when the ship spawns and map the scan class to standard colors (i.e CLASS_NEUTRAL -> yellow). That would be your scannerDisplayColor1. ... you can also make a check for pre-scripted scanner colors before checking the scan class.

That's emulating Oolite core code within the OXP: it's wasteful and prone to error/deprecation. The core should offer a method to return the actual displayed colours or set those actual colours in the scanner*DisplayColor* variables directly. But I suppose in the mean time I'll just have to do it the long way.

Regarding the second point ... We need to keep in mind that there are already OXPs using these properties as they are now and changing this at this moment may break them.

OK, point taken and text crossed out New method please!

[another_commander]

The core should offer a method to return the actual displayed colours[...]

Noted for post-1.82 code freeze.

[cim]

Second: if I set(*) either SDC (but leave the scannerHostileDisplayColors untouched) then, when the targets go hostile, they don't change to their hostile orange colour; they stay using the non-hostile colours that I set!

This is necessary for compatibility.

SHDC is a 1.82 addition. In 1.80 and earlier, setting SDC also overrides the hostile colours to that value. To avoid breaking existing OXPs, therefore 1.82 must use for hostile colours SHDC > SDC > defaults for scan class.

[jh145]

Second: if I set(*) either SDC (but leave the scannerHostileDisplayColors untouched) then, when the targets go hostile, they don't change to their hostile orange colour; they stay using the non-hostile colours that I set!

This is necessary for compatibility.

SHDC is a 1.82 addition. In 1.80 and earlier, setting SDC also overrides the hostile colours to that value. To avoid breaking existing OXPs, therefore 1.82 must use for hostile colours SHDC > SDC > defaults for scan class.

Just as a throwaway remark: how about if SHDC's undefined (old OXPs), fall back to SDC; if SHDC's null (potential new OXPs), fall back to defaults for scan class. Too fiddly?

[cim]

Just as a throwaway remark: how about if SHDC's undefined (old OXPs), fall back to SDC; if SHDC's null (potential new OXPs), fall back to defaults for scan class. Too fiddly?

The distinction between "undefined" and "null" isn't one that could be stored in the core game's data structures without excessive work - and it would now also mean a change in behaviour between 1.82 and 1.84.

In practice it's probably only CLASS_NEUTRAL entities (admittedly the majority) where setting a custom SDC but using the default SHDC is particularly useful, and it's not a lot of extra work in that case to say SHDC1 = [1,0.25,0,1]; either in shipdata or JS.