View Issue Details

IDProjectCategoryView StatusLast Update
0004298Multi Theft Auto : San AndreasServerpublic2015-03-07 13:39
ReporterNeonBlack Assigned Toccw  
Status resolvedResolutionfixed 
Summary0004298: triggerClientEvent() doesn't pass large numbers or floats accurately

arc_ already reported strings being not passed correctly here:
I couldn't reopen that issue so I post a new one now.

This time it's the numbers that aren't passed correctly.
If I send 1234567890 to the client it puts out 1234567936.
If I send 3.14159 to the client it puts out 3.14159011084082.
I guess it's nearly the same for all other numbers.

Until now I used a workaround for that: Converting the numbers to strings serverside and looping through the arguments clientside checking which argument is convertable to a number. But this is shit.

Additional Information

You may test this with the code I used:

local _root = getRootElement()
addCommandHandler("ev", function (source) triggerClientEvent(source, "ev", _root, 1234567890) end, false, false)

local _root = getRootElement()
addEvent("ev", true)
addEventHandler("ev", _root, function(num) outputChatBox("Number: "..tostring(num)) end)

And yes, it's reproduced from arc_'s issue :P

TagsNo tags attached.


has duplicate 0007686 closed New issues Unable to correctly send numbers bigger than 16777215 using triggerClientEvent 
related to 0005854 resolvedccw Multi Theft Auto : San Andreas Client runs with reduced mathematical precision compared to the server. 
related to 0008128 resolvedccw Multi Theft Auto : San Andreas Integer data change when sending it between server and client 



2009-05-14 12:39

viewer   ~~0009232

By the way: it's the same vice versa (triggerServerEvent).


2009-05-14 12:41

administrator   ~~0009233

This is simply because triggerClientEvent sends all numbers as 32-bit floats, which have limited precision (Lua uses 64-bit doubles internally). Not actually a bug like that report about strings, rather a consequence of the choice to use floats for saving bandwidth.


2009-05-14 12:55

viewer   ~~0009234

Last edited: 2009-05-14 12:55

But this should be fixed in any way, at least noted on the wiki.
As I tried sending numbers to the client the first time I spent hours into searching the mistake until I found out that this function doesn't work correctly.

The thing is that we have the choice between sending ”big“ (I think 64 bit are no problem today) data and being able to use them or sending small but wrong data which we can't use anyway.
Converting them to strings as a workaround just increases the need of bandwith.
So you should send them as 64bit doubles by default and maybe add some boolean as argument that enables sending them as 32bit floats if the scripter wants that. But I'm sure no one wants that, because it's just a corruption of data making the data useless. (imo)


2009-05-14 12:58

administrator   ~~0009235

Last edited: 2009-05-14 12:59

Depends on what you call "useless"... For the absolute majority of gamemode related numbers (positions/rotations, model ID's, health amounts etc), floats are perfectly fine. Huge numbers like 1234567890 rarely occur, and I also doubt you will ever need more than 5-decimals precision.

There could be made a special case for large integer numbers, sending these as 32-bit ints rather than floats. But sending doubles seems completely overkill to me.


2013-12-20 14:21

manager   ~~0019815

This bug is still present in newest 1.4 nightly.


2015-03-06 23:09

viewer   ~~0023074

Last edited: 2015-03-06 23:15

tried sending to client a number via command /num on latest 1.4.1 nightly and it worked fine for me without any mistakes

crun addEvent("onNumberRecieve",true) function outputNumber(num) outputChatBox(tonumber(num)) end addEventHandler("onNumberRecieve",root,outputNumber)

srun addCommandHandler("num",function(thePlayer,cmd,num) triggerClientEvent("onNumberRecieve",thePlayer,tonumber(num)) end)


2015-03-07 08:22

viewer   ~~0023075

There was a fix for integers only.


2015-03-07 13:39

administrator   ~~0023077

Should be OK now

Issue History

Date Modified Username Field Change