You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
color = hsv { 0.58 1.00 0.72 }
color = rgb { 169 242 27 }
color = hsv360{ 25 75 63 }
position = cylindrical{ 150 3 0 }
color5 = hex { aabbccdd }
mild_winter = LIST { 3700 3701
# ....
}
A few options:
Support them generically: Create a TextToken::Header(Scalar) followed by a TextToken::Array (though it seems equally plausible that it is followed by an object)
Create a unique TextToken for each case (eg: TextToken::Hsv, TextToken::Rgb, TextToken::Hsv360, etc)
Parse similar objects to the same internal structure (eg: hsv, rgb, hsv360, and hex should all be about the same)
Right now I'm leaning towards option 1. as that will allow this mechanism for unforeseen tokens that I'm sure will be introduced with each game. With option 1, we should still keep the BinaryToken::Rgb as that is the only color that appears in the binary format (thus far). The downstream breaking change will come with deserialization, in order for a client to distinguish values the deserializer will need to expose the token header somehow. The only thing coming to mind is to emulate deserializing a tuple with the first element being (rgb, hsv, etc) and the second element being the data.
The text was updated successfully, but these errors were encountered:
Found these across several PDS games:
A few options:
TextToken::Header(Scalar)
followed by aTextToken::Array
(though it seems equally plausible that it is followed by an object)TextToken::Hsv
,TextToken::Rgb
,TextToken::Hsv360
, etc)Right now I'm leaning towards option 1. as that will allow this mechanism for unforeseen tokens that I'm sure will be introduced with each game. With option 1, we should still keep the
BinaryToken::Rgb
as that is the only color that appears in the binary format (thus far). The downstream breaking change will come with deserialization, in order for a client to distinguish values the deserializer will need to expose the token header somehow. The only thing coming to mind is to emulate deserializing a tuple with the first element being (rgb
,hsv
, etc) and the second element being the data.The text was updated successfully, but these errors were encountered: