View Issue Details

IDProjectCategoryView StatusLast Update
0005207Multi Theft Auto : San AndreasServerpublic2012-03-16 10:58
ReporterFlobuAssigned ToCazomino05 
PriorityhighSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
Product Version 
Target Version1.3Fixed in Version1.3 
Summary0005207: onVehicleDamage is triggered by fixVehicle with a positive value as loss parameter
Description

^
in debug it only happens on first time using it

TagsNo tags attached.

Relationships

has duplicate 0005540 closed New issues onVehicleDamage is called with fixVehicle 

Activities

x86

2010-05-12 20:12

administrator   ~~0011456

A little bit debugging..

Just hitting something..
Old Health: 1000.244263, new health: 971.428589, diff: 28.815674
Old Health: 971.428589, new health: 969.963379, diff: 1.465210

And now using fixVehicle():
Old Health: 1000.000000, new health: 969.963379, diff: 30.036621

Flobu

2010-05-12 20:14

updater   ~~0011457

yeah i found this out too but not why

x86

2010-05-12 20:16

administrator   ~~0011458

Well, fixVehicle is calling CVehicle::SetHealth(1000).

And the Vehicle Sync packet is calling CVehicle::GetHealth, which was set to 1000.

Flobu

2010-05-12 20:18

updater   ~~0011459

hm ok
so the problem is that fixVehicle didn't set the real health of the vehicle

Gamesnert

2010-12-21 19:36

developer   ~~0012337

Unable to reproduce, is this bug still present?

arranTuna

2010-12-21 19:43

manager   ~~0012338

Not triggering for me either (1.0.4 2106)

onestone

2010-12-22 20:40

viewer   ~~0012346

Still present. Can reproduce it some times.

arranTuna

2011-01-11 13:14

manager   ~~0012529

And what was the server version? As i've been trying in 1.1 and cant reproduce it with fix vehicle, however I found something a bit odd with onVehicleDamage:

Arran executed command: addEventHandler("onVehicleDamage", root, function(loss) outputChatBox(loss) end)
Command results: true [boolean]
Arran executed command: setElementHealth(root, 905)
Command results: false [boolean]
Arran executed command: setElementHealth(root, 906)
Command results: false [boolean]
0.01708984375
Arran executed command: setElementHealth(root, 907)
Command results: false [boolean]
0.040283203125
Arran executed command: setElementHealth(root, 950)
Command results: false [boolean]
0.06103515625
Arran executed command: setElementHealth(root, 998)
Command results: false [boolean]
0.19781494140625
Arran executed command: setElementHealth(root, 999)
Command results: false [boolean]
0.22100830078125
Arran executed command: setElementHealth(root, 1000)
Command results: false [boolean]

Note that it starts at 906 (bit random) and ends at 999.

Talidan

2011-04-17 18:36

administrator   ~~0013199

Seems to me that this is as a result of floating point innaccuracies in bandwidth optimizations. Might be worth neglecting loss values <1.

That said, i can get real positive values with fixVehicle easily by crashing the car then using 'repair'. It doesn't always work, but if you do it immediately after crashing it normally does happen.

Cazomino05

2011-06-18 00:33

reporter   ~~0013696

I can't reproduce this any more on the latest build I've tried debug and release

I can reproduce arranTuna's bug but that's to do with bandwidth inaccuracies and when it's producing differences of 30 odd I doubt that's the case.

x86

2011-08-12 18:45

administrator   ~~0014241

Please retest!

LooooP

2011-12-05 13:00

reporter   ~~0015332

Can't reproduce it too (MTA:SA 1.1.1 r3505)

Cazomino05: I can reproduce arranTuna's bug but that's to do with bandwidth inaccuracies and when it's producing differences of 30 odd I doubt that's the case.

I can reproduce too, may it's also causing problems with clonated objects in Map Editor (e.g. If you clonate an object with 90/180/360 [and many others] rotation [Doesn't matter if rotX, Y or Z] it will turn to 179.999666...)

Issue History

Date Modified Username Field Change