Wrong output of getBlipSize() function

[Cyber52]

Describe the bug
GetBlipSize() function returns wrong output when you call it from clientside and the blip was created serverside

To reproduce
Steps to reproduce the behaviour:

--server
local blip = createBlip(0, 0, 0, 41, 5, 0, 255)
setElementData(resourceRoot, "blip", blip)
print(getBlipSize(blip), "serverside") -- returns 5

--client
local blip = getElementData(resourceRoot, "blip")
print(getBlipSize(blip), "clientside") -- returns 2 (default value)

Expected behaviour
It should return proper value

Version

• server/client version 1.5.7/1.5(?)

[patrikjuvonen]

In Wiki:

size: The size of the radar blip. Only applicable to the Marker icon. Default is 2. Maximum is 25.

In packet handler:

mtasa-blue/Client/mods/deathmatch/logic/CPacketHandler.cpp

Lines 3541 to 3554 in ca56af7

	// Read out size and color if there's no icon
	if (icon == 0)
	{
	// Read out the size
	SIntegerSync<unsigned char, 5> size;
	bitStream.Read(&size);
	// Read out the color
	SColorSync color;
	bitStream.Read(&color);
	pBlip->SetScale(size);
	pBlip->SetColor(color);
	}

We only read the size and color client-side if the blip icon is set to Marker (ID 0).

We could change this behavior to be consistent across the board, for example:

1. Omit size on server and client if the blip icon is incompatible.
2. Allow setting blip size regardless of its icon, but risk it won't work at all or the blip will look distorted without further enhancements on the rendering side of things.
3. Hard error on bad usage (size was provided with incompatible icon).

Additionally, we should add a usage warning for any upcoming change to this behavior, and perhaps also after the matter.

So in short, this is currently intended behavior and to change it we need to address backwards compatibility one way or the other (we can't change it just server-side because that will also introduce problems).

Personally, I don't think we need to change this behavior unless we plan on introducing support for scalable blip icons, or perhaps we should change the behavior in the next breaking release (1.6) for consistency.