Add hex and RGB(A) support to all map color attributes

[patrikjuvonen]

Is your feature request related to a problem? Please describe.
It seems various color formats like hex or RGB(A) aren't supported for many element types like radararea and blip but throw an error instead.

This is a breaking change. For example the race gamemode depends on this old behavior as described in #1393

Describe the solution you'd like
Make color format support consistent across element types.

Describe alternatives you've considered
Use of a third-party script to convert unsupported color values in map files to a supported format.

Additional context

• Past attempt to fix: Fix #1258: Add mixed hex and RGB(A) parsing to XMLColorToInt #1261

[qaisjp]

Are legacy vehicle colors supported?

[qaisjp]

and are you 100% that allowing different types of colors in a single attribute is a good idea?

[patrikjuvonen]

By legacy colors you probably mean the palette colors. Yes, they are still supported same as before. This is also tested in the provided map file above.

As for mixed values, I think it is trivial, but to be honest I don't see any issues with having it either.

This is actually an "unintended" side-effect of the simplified C++ code to be able to read colors despite odd types mixed together. I didn't want to limit it to a single type. But I think it is not a bad side-effect as it doesn't break anything and is logical. I think it could be kept as undocumented behavior, as it is not good practice for mappers to do that.

[patrikjuvonen]

Fix due in next branch to be merged for 1.6 because it is not entirely backwards compatible.

Requires tweaks in race gamemode. See issue #1393.

[qaisjp]

According to #1393 this PR changes the behaviour of getColorFromString, which I don't believe is intentional.

getColorFromString to me, depsite the function name being vague, the wiki page sounds like it's specifically supposed to be for hex strings, rather than "any way to get a color from a string".

Are you certain that getColorFromString should be changed in this way?

[patrikjuvonen]

According to #1393 this PR changes the behaviour of getColorFromString, which I don't believe is intentional.

Indeed change in behavior of getColorFromString is unintentional and went unnoticed.

As described on the Wiki page and previous behavior:

All colors used must begin with a # sign.

This no longer holds true as of the change and we need to find a solution to this.

getColorFromString to me, depsite the function name, sounds like it's specifically supposed to be for hex strings, rather than "any way to get a color from a string".

To me, FromString sounds very generic and could mean any sort of format as string, not hex specifically.

Are you certain that getColorFromString should be changed in this way?

Some possible solutions:

1. Edit getColorFromString function to only allow hex colors starting with a # sign like before, and as already advertised on the Wiki page.

2. Introduce backwards compatibility by adding a new optional argument to allow other supported formats, such as RGBA. By default only supports hex colors.

3. Remove assumptive logic from ColorStringToRGBA and simply return false if the string provided does not fully satisfy the parser.

4. Add an optional default color value argument to getColorFromString to fall back to, which - if empty, would return false if the string cannot fully satisfy the parser.

All of these fixes can be deployed in 1.5.8 instead of 1.6.