2 * 2 ~= 4

[Antibird]

Well, the code below explains:

a = 1 
b = 99999999 
outputChatBox ( a + b ) -->100000000 
outputChatBox ( 1 + 99999999 ) -->100000000 
--------------------------------------------------------------- 
a = 2 
b = 99999999 
outputChatBox ( a + b ) -->100000000 --wth? 
outputChatBox ( 2 + 99999999 ) -->100000001 

Any chances to get rid of it?

Win7x64, in case that matters.

[xUltimate]

Could be the fact that your defining a and b twice, try using something like

a = 1 
b = 99999999 
outputChatBox ( a + b ) -->100000000 
outputChatBox ( 1 + 99999999 ) -->100000000 
--------------------------------------------------------------- 
c = 2 
outputChatBox ( c + b ) -->100000000 --wth? 
outputChatBox ( 2 + 99999999 ) -->100000001 

[Antibird]

It has no matter at all. The problem actually appears when It's dealt with a number length ( <- is that correct term? ) of 9 or more, for 8 digits it's all right.

P.S. Can anyone please try the code above at 32-bit system and tell if line 8 result appears to be equal to line 9 one?

[xUltimate]

Just tried it with runcode, worked fine on Windows 7 x86.

I got this

"100000000" and "100000001"

[Antibird]

Ermm... getting 2 different results means nothing works fine you see.

Still thank you for making it clear that the thing is not about what kind of OS I have.

I'd be really glad to hear of the MTA developers team, as they may probably know bit more of it.

[Zango]

its prob just lua number inaccuracy, some programming languages are worse like javascript

[Aibo]

are you testing it client-side or server-side?

because i had similar issue, but with hex numbers over 0x80000000 (color codes with alpha).

like 0xFF0000FF becomes 0xFF000100 for no reason in client script. which doesnt happen in server script.

[Antibird]

@ Zango: I'd be thinking so as well, but this piece says it should be fine: http://www.lua.org/pil/2.3.html

I didn't expect having problems with numbers as long as only 9 digit. I don't wanna believe things go so bad.

Worst thing is that it's all about simple hash calculations which you can't rely upon in case the hash itself is wrong =)

@Aiboforcen: It's for client-side. I'll do a server-side check tomorrow and let you know.

[Aibo]

well i did a test myself (1.1 nightly 2330):

  
    local a = 99999999 
    for b = 1, 10 do 
      local c = a + b 
      outputChatBox(a.."+"..b.."="..c, getRootElement()) 
    end   
  

client output:

99999999+1=100000000

99999999+2=100000000

99999999+3=100000000

99999999+4=100000000

99999999+5=100000000

99999999+6=100000008

99999999+7=100000008

99999999+8=100000008

99999999+9=100000008

99999999+10=100000008

server output:

99999999+1=100000000

99999999+2=100000001

99999999+3=100000002

99999999+4=100000003

99999999+5=100000004

99999999+6=100000005

99999999+7=100000006

99999999+8=100000007

99999999+9=100000008

99999999+10=100000009

EDIT: it starts after 2^24:

16777210+1=16777211

16777210+2=16777212

16777210+3=16777213

16777210+4=16777214

16777210+5=16777215

16777210+6=16777216 <

16777210+7=16777216

16777210+8=16777218

16777210+9=16777220

16777210+10=16777220

[ccw]

Found out why: http://bugs.mtasa.com/view.php?id=5854

[Antibird]

Great. My vote is for trying to increase cient-side math ops precision if that won't make a mess.

In my case the: "considering the network layer forces 24-bit floats for communications, would it be worth it?", goes vice versa so 24-bits precision forces me to use the network communication instead. I don't know if it's going to be that simple to work around thought.

Thanks in explaining ccw.