From e5137491195130d9efc9ce5bf4e9585d36557329 Mon Sep 17 00:00:00 2001 From: Anton Tarasenko Date: Sat, 18 Jul 2020 02:40:07 +0700 Subject: [PATCH] Add stub for color docs --- docs/Colors.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 docs/Colors.md diff --git a/docs/Colors.md b/docs/Colors.md new file mode 100644 index 0000000..94b1481 --- /dev/null +++ b/docs/Colors.md @@ -0,0 +1,16 @@ +# Colors + +The main, and possibly only, notable thing abotu **Acedia**'s colors is it's support for parsing their text representation. To be precise, **Acedia** understands: + +1. Hex color definitions in format of `#ffc0cb`; +2. RGB color definitions that look like either `rgb(255,192,203)` or `rgb(r=255,g=192,b=203)`; +3. RGBA color definitions that look like either `rgb(255,192,203,13)` or `rgb(r=255,g=192,b=203,a=13)`; +4. Alias color definitions that **Acedia** looks up from color-specific alias source and look like any other alias reference: `$pink`. + +You should be able to use any form you like while working with **Acedia**. + +## [Technical] Color fixing + +Killing floor's standard methods of rendering colored `string`s make use of inserting 4-byte sequence into them: first bytes denotes the start of the sequence, 3 following bytes denote rgb color components. Unfortunately these methods also have issues with rendering `string`s if you specify certain values (`0` and `10`) as red-green-blue color components. + +You can freely use colors with these components, since **Acedia** automatically should fix them for you (by replacing them with indistinguishably close, but valid color) whenever it matters.