0009891: Add support for more map attributes

[patrikjuvonen]

Mantis Bug Tracker issue:
9891
fixes #454

Summary:

• Add visibleDistance and size attributes to <blip>
• Add headless and walkingStyle attributes to <ped>
• Make "all" option case-insensitive for upgrades attribute on <vehicle>
• Add headLightColor, taxiLightOn, engineOn, lightsOn, damageProof, explodableFuelTank, toggleRespawn, respawnDelay, respawnPosX, respawnPosY, respawnPosZ, respawnRotX, respawnRotY, respawnRotZ attributes to <vehicle>
• Make code style more consistent
• mtasa-resources edf + editor update issue + PR open here: edf: add missing map attributes mtasa-resources#115

Test map file:
test_263_v2.txt

[qaisjp]

• Introduce new forceColor attribute (default: false), which can be used to toggle whether color attribute being 0,0,0 will be read as forcefully black or random (default color will be overridden by force). Added for backwards compatibility.

I was thinking:

• the default value of randomColor would be black, which is the old functionality
• randomColor=true would force a random color
• randomColor=false would allow you to use the black color

But then it isn't obvious what randomColor does by default (I would expect it to be false if I was reading a .map file).

And my worry with forceColor is that it isn't very semantic & has the same issue as above (could someone know what forceColor=false does without reading the docs?)

Perhaps we could do a census (ask racing servers to run a script for us and tell us the output), and if results say that color=0,0,0 is rarely used, we can just choose to break backwards compatibility?

It's up to you really, that sort of census sounds like too much work it would drag this PR on for too long

[patrikjuvonen]

I think the problem here is that by introducing randomColor attribute I'm expecting to get a random color doesn't matter what I input into the color attribute, at least in my opinion. This behavior would break existing maps.

Because it's actually quite "ambiguous" what the default behavior is, by introducing a forceColor attribute, we will make it clear that whatever our vehicle class does now or in the future by default will be overridden by the color attribute.

So whichever way we go, people would have to read up on Wiki what it does.

We could however name it __backwardsCompatibleColorBehavior, __useOldColorBehavior (default true) or something other specifically dirty so it marks that this isn't good behavior and may be changed in the future to only work with the new style which is that 0,0,0 will result in black color, not random color.

I do however believe we should introduce a new randomColor attribute that will generate a random color even if the current default vehicle class behavior was refactored and random color wouldn't happen by default. We could even make it so that if no color attribute exists on the node, it will generate a random color, however I think this behavior would break more maps.

And meanwhile, we could inquire race server owners whether they have any color="0, 0, 0" strings in any of their map files, then replacing all of these occurrences by randomColor="true", if their intended behavior was indeed to get a random color, and not black color.

[Woovie]

I contacted AfuSensi on Discord, who owns/operates/works on Mr. Green's

Search "<vehicle.*color="0,0,0" (1485 hits in 167 files)

Search "<vehicle.*color="([1-255]{1,3}),\1,\1" (82 hits in 33 files)

Around 2500 maps total, and this is the total amount of returns.

[patrikjuvonen]

Thanks @Woovie, I think we should separate the vehicle color fix as its own PR and issue so we can discuss that matter in a different thread to see what would be the best solution. I do believe something has to be done since the current default behavior is not expected behavior in my opinion.

[Woovie]

So we should revert 274d9b3 and I guess it's ready for merge? @qaisjp what do you think?

[qaisjp]

So we should revert 274d9b3 and I guess it's ready for merge? @qaisjp what do you think?

sounds fine

[patrikjuvonen]

I have now removed the forced color attribute from the PR. Making a new issue about it now, and also of the broader color syntax seen earlier in this PR.

Black RGB color attribute issue created at #1257
Hex and RGBA color attribute support issue created at #1258

[qaisjp]

go for merge, lgtm, , @patrikjuvonen