#fff issue

ID:2851670
 
Jan 30 2023, 2:56 pm
Not a bug
BYOND Version:515.1598
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 109.0.0.0
Applies to:Dream Seeker
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
When changing a atom's color variable, setting it to #fff will cause it to set the color variable to null instead of to #fff

Code Snippet (if applicable) to Reproduce Problem:
mob/Login()
    ..()
    var obj/a = new(locate(1,1,1)); a.color = "#fff" // Becomes null
    var obj/b = new(locate(1,2,1)); b.color = "#444" // Becomes #444444

obj/Click()
    world << "Color? ([color])"


Expected Results:
#fff to get the same treatment as the other color codes.

Actual Results:
#fff is cancelled

Workarounds:
#eee

Jan 30 2023, 3:12 pm
Supposedly setting color to #ffffff also sets the color value to null. Technically null and #fff and #ffffff are interchangeably used as "white".
Jan 30 2023, 3:15 pm
In response to Taitz
Taitz wrote:
Supposedly setting color to #ffffff also sets the color value to null. Technically null and #fff and #ffffff are interchangeably used as "white".

Is there a reason it's set to null instead of to #fff? Just seems like undesirable behavior when expecting a string and instead it's null but you swore you set it.
Jan 30 2023, 6:11 pm
Lummox JR resolved issue (Not a bug)