Cataclysm-dda: Acceptable JSON "symbol" list

[i2amroy]

Does one of these exist anywhere? As is they generally seem to accept most basic letters, but some symbols seem to be accepted while others have special codes and others are just flat out rejected.

If one does not exist it would be very helpful is someone in the know would write up a short document of the accepted symbols for the various JSON files.

[kevingranade]

What do you mean "rejected"? In principle it should be ok with anything in utf-8, if it isn't it's a bug.

[BevapDin]

Monster symbols can be full UTF-8 strings. They only need to be exactly 1 console cell width, but can consist of any number of code points / characters.

The other symbols (terrain/items/...) should be converted to that system.

[Mshock777]

Maybe on the similar topic: is it possible to make json mapgen accept characters from extended ascii? (currently it only accepts printable characters)

[illi-kun]

This topic can be related to the existing issue #6198 (which is almost empty).

[i2amroy]

What do you mean "rejected"? In principle it should be ok with anything in utf-8, if it isn't it's a bug.

For example, terrain stuff throws out characters like '¤', which is still a single width character last I checked, with the error message "Must be a single character". '‡' gets thrown out with the same message as well.

6198 is also a big issue on top of that; overmap_terrain is full of things like "sym" : [118, 60, 94, 62], as well as things like "sym" : [4194424, 4194417, 4194424, 4194417],. What the four numbers are supposed to stand for is explained, they're the way it appears in different rotations, but what they actually _mean_ symbol-wise is totally undocumented.

[Mshock777]

I know nothing about encoding, but I think using '¤', '‡' would require switching too 16-bit encoding. And doxygen should support it.

[i2amroy]

I mean we're already using things in that boat like ö in our descriptions and names just fine; there should be no reason why we are allowed to use a single-width characters like that in our descriptions and names but not as a symbol on the map for a monster or terrain.

[Mshock777]

Description and names don't get checked for key.size, but as I said, I would like to have more characters to choose from.

[i2amroy]

So I did some digging into this and it is properly horrifying. As best as I can tell the basic process goes something like this:

1. Take the value in as a long. Why a long? Supposedly to support curses line drawing, but honestly I'm not sure how this is actually still functional because pretty much the very first thing we do with it is cast it (through a function call, not explicitly) to a "chtype" which is just an alias for int (and which can, in some implementations, be too small by definition to hold our specially pre-defined LINE_XOXO values).
2. At this point we pass that int down about two levels through obtusely named (unless you know curses system class) functions without any commenting, which is when we then create a char and do char charcode = our_int_val.
3. We then compare our (now a char) value with our pre-defined longs through a switch statement, and set our char value to a predefined hex byte if it matches any of them.
4. Alternatively if it doesn't match any of the special line longs then we just do charcode = (char)our_int_val again (though this time we do specify that we want to cast to a char explicitly).
5. We then manually turn that char into a char[] and add a null-terminator before calling printstring().

I honestly have no idea how this whole thing doesn't explode at the drop of the hat. Almost every single line gets highlighted by my IDE with a "values of type X may not fit into the receiver type Y", and not only that but we seem to be explicitly causing overflow errors on purpose in some of the cases (such as line drawing).

I can understand the desire to keep consistency in output.h with the curses (linux) system calls, but if we're going to use them in that fashion then we need to be making sure that we are actually putting in valid inputs instead of secretly casting magic numbers that are potentially too large to fit into their defined boxes (twice) and then praying that whatever compiler the user compiled on doesn't break anything so badly that it can't function.

[ZhilkinSerg]

Partially addressed in #29161.