'm' is normal light but R_AnimateLight uses (map - 'a') * 22. This causes 'm' to translate to 264, not 256; yet 256 is assumed as normal fullbright everywhere else. This has always bothered me (even though it's likely not even noticeable) - just pick one and be consistent about it.
What is there to prevent a mod author from using chars outside of the 'a'..'z' range for lightstyle animations? Nothing so far as I can see; these are legal. If QCC accepts chars > 127 as lightstyles then these are also legal. Yet map is a signed char so these translate to negative lights; R_BuildLightmap needs to be able to catch these (or should it instead be compatible with ID Quake even though ID Quake's behaviour is clearly a bug?)
I wonder have any examples of this ever been unleashed in the wild?
QCC behaviour here needs to be consistent with engine behaviour for saving/loading lightstyles. If they conflict which one should be considered "correct"? I'd personally vote "engine" because engine source came last; before the engine source was released QCC had no choice but to conform to what the engine did. This standard should be maintained.
(Curious aside - have I just found a use for the "signed char" data type? To make it explicit in code that yeah, signed behaviour is what you want here, this is not a bug, don't go trying to 'fix' it.)
Food for thought.
Animating lightstyle notes
Animating lightstyle notes
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for