scannerDisplayColor

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

Post Reply
User avatar
jh145
Dangerous
Dangerous
Posts: 94
Joined: Thu Dec 25, 2014 8:39 pm

scannerDisplayColor

Post by jh145 » Tue May 12, 2015 6:29 pm

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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5397
Joined: Wed Feb 28, 2007 7:54 am

Re: scannerDisplayColor

Post by another_commander » Tue May 12, 2015 7:26 pm

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.

User avatar
jh145
Dangerous
Dangerous
Posts: 94
Joined: Thu Dec 25, 2014 8:39 pm

Re: scannerDisplayColor

Post by jh145 » Tue May 12, 2015 7:40 pm

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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5397
Joined: Wed Feb 28, 2007 7:54 am

Re: scannerDisplayColor

Post by another_commander » Tue May 12, 2015 7:57 pm

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.

User avatar
jh145
Dangerous
Dangerous
Posts: 94
Joined: Thu Dec 25, 2014 8:39 pm

Re: scannerDisplayColor

Post by jh145 » Tue May 12, 2015 8:17 pm

another_commander wrote: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 :wink: New method please!

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5397
Joined: Wed Feb 28, 2007 7:54 am

Re: scannerDisplayColor

Post by another_commander » Tue May 12, 2015 8:26 pm

jh145 wrote:The core should offer a method to return the actual displayed colours[...]
Noted for post-1.82 code freeze.

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: scannerDisplayColor

Post by cim » Tue May 12, 2015 8:35 pm

jh145 wrote: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.

User avatar
jh145
Dangerous
Dangerous
Posts: 94
Joined: Thu Dec 25, 2014 8:39 pm

Re: scannerDisplayColor

Post by jh145 » Tue May 12, 2015 8:48 pm

cim wrote:
jh145 wrote: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?

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: scannerDisplayColor

Post by cim » Tue May 12, 2015 9:42 pm

jh145 wrote: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.

Post Reply