Event `onVehicleDamage` doesn't trigger if vehicle health is above ~2050

[guibzo]

Describe the bug

Apparently, this event is not triggered when vehicle has above a certain amount of health.

Steps to reproduce

addCommandHandler("spawncar", function(player)
  local x, y, z = getElementPosition(player)

  local car = createVehicle(400, x, y, z, 0, 0, 0)

  setElementHealth(car, 3000)

  addEventHandler("onVehicleDamage", car, function(loss)
    iprint("loss", loss, "health", getElementHealth(source))
    -- this only starts printing on about ~2050 health
  end)
end)

Version

v1.6-release-24124

Additional context

No response

Relevant log output

Security Policy

• I have read and understood the Security Policy and this issue is not security related.

[QueryOfficial]

Investigation notes (not proposing a PR yet)

I looked into this and I believe the current behavior may be intentional, not a random bug.

onVehicleDamage on the server is driven by synced health dropping below LastSyncedHealth. Vehicle health is encoded with SVehicleHealthSync in Shared/sdk/net/SyncStructures.h:

struct SVehicleHealthSync : public SFloatAsBitsSync<12>
{
    // 0 - 2000 step 0.5                                2047.5 = ( 2^12 - 1 ) * 0.5
    SVehicleHealthSync() : SFloatAsBitsSync<12>(0.f, 2047.5f, true, false) {}
};

That gives a fixed 12-bit budget in puresync packets, with a max of 2047.5 — which fits GTA’s vanilla vehicle health range (~250–1000, default 1000) and keeps bandwidth usage predictable. The low-precision lightsync variant (SLowPrecisionVehicleHealthSync, 8 bits, max 2040) looks like the same trade-off.

The problem appears when setElementHealth allows values up to MAX_VEHICLE_HEALTH (10000): values above 2047.5 get clamped during sync, so the server doesn’t see health drops until the synced value falls below that ceiling — which matches the ~2050 repro.

If this was a deliberate sync design choice for performance/bandwidth, I don’t think it needs changing without staff input. If you’d like it aligned with MAX_VEHICLE_HEALTH, the fix looks straightforward and would not require extra bits — only a wider range with a coarser step, e.g.:

// 12 bits unchanged; step 2.5 → max 10237.5 (covers MAX_VEHICLE_HEALTH = 10000)
SVehicleHealthSync() : SFloatAsBitsSync<12>(0.f, 10237.5f, true, false) {}

// 8 bits unchanged for lightsync
SLowPrecisionVehicleHealthSync() : SFloatAsBitsSync<8>(0.0f, 10200.0f, true, false) {}

That would be a protocol-breaking change (client + server must match), but the code change itself is small — mostly SyncStructures.h plus a few round-trip tests.

Happy to prepare a proper PR if a staff member confirms this is the direction you want. Until then, I’m treating the 2047.5 limit as a likely intentional sync constraint rather than something to patch unilaterally.