Regression: Ped health above 16383 no longer synchronizes correctly on newer game executable (e3889) #4354

What happened?

I found a PED health synchronization regression after moving from older game builds to 3889.

Our previous setup supported synchronized PED health values up to 65535 with OneSyncBigIdEnabled enabled. On b3889, higher health values become incorrect on remote clients.

In our test, the same networked PED reported:

• Owning client: 49160 HP
• Remote client: 8 HP

This matches truncation to the low 14 bits: 49160 & 0x3FFF = 8.

This affects our networked PEDs during combat. The clients disagree about the ped health, which disrupts damage handling and can make the ped appear invulnerable.

Expected result

PED health and maximum health should retain the previously working synchronization range up to 65535. A networked PED with 49160 HP should report 49160 HP on both the owning client and remote clients.

Reproduction steps

1. Run a server game build 3889 with OneSync enabled.
2. Connect two clients and keep both within streaming range of the same networked, non-player PED.
3. On the client that owns the PED, call SetPedMaxHealth(ped, 65535).
4. On the owning client, call SetEntityHealth(ped, 49160).
5. Allow the PED's state to synchronize.
6. Compare GetEntityHealth(ped) on both clients.

Observed: The owning client reports 49160, while the remote client reports 8.

Importancy

There's a workaround

Area(s)

FiveM, OneSync, Natives

Specific version(s)

FiveM 38324/beta (b3095 [e3889]) ,Server b38317 windows

Additional information

Possible cause

Commit f57a4b3 by @Gogsi documents that maxHealth and pedHealth changed from 13 to 14 bits in b3717.

However, the existing hooks in rlNetBuffer.cpp expand unsigned read/write operations and their cursor increments from 13 to 16 bits only when:

length == 13 && icgi->OneSyncBigIdEnabled

Previously, the health fields received this expansion, allowing values up to 65535. The newer 14-bit health fields no longer match the condition.

This appears to explain why increasing the game's original field width reduced the effective synchronization range in FiveM.

Scope of the evidence

• Offline inspection confirmed 13-bit health fields in the original b3095 serializer and 14-bit health fields in b3751.
• We have not directly disassembled the b3889 serializer.
• On b3889, we observed the client-to-client mismatch described above.

Commit f57a4b3 updates the server parser to match the newer game format. This report concerns the loss of the previous effective 16-bit range; it does not establish that the commit introduced the regression.

Requested behavior

Could the previous effective 16-bit range be preserved for both PED health and maximum health on b3717+, with matching client and server handling?