altv-issues
altv-issues copied to clipboard
Player fist fight not synced on first connect
Client/server version
Build 5.3, release
Current behavior Currently, the fist fight sync is, again, not working properly. If a player joins a server the first time, fist fighting seems not to be synced. After reconnecting fist-fighting is fine.
Expected behavior Fist fighting should be synced even on first connect.
Steps to reproduce
- Setup a clean server with JS-Module installed and debug mode enabled.
- Add the following server code to a new resource:
import * as alt from 'alt-server';
alt.on('playerConnect', (player) => {
player.model = 'mp_m_freemode_01';
player.spawn(0, 0, 72, 0);
});
- Connect two different computers to the server to simulate two different players.
- Now, punching another player does not result in synced the "throwback" animation nor is the health synced then (as shown in the video below)
- After reconnecting to the same server using the
reconnect
command, fight sync and health sync is fine.
Possible solution I guess parts are not synced if a connection was not established before or a player hasn't connected before.
Video report https://user-images.githubusercontent.com/10392626/127742035-f2110a2e-65a0-4884-bb23-e408072b1352.mp4
Info to the video: Both players (two different computers) are connected the first time to the server over LAN. After reconnecting, fist sync works fine as expected.
Fixed in dev
Fixed in dev
@C0kkie Seems not to be synced again in 6.4
. Can be opened again.
Happens in alt:V version 8.4, too.
Note 1: If one of the players dies, the sync works fine for both parties - even when the previously attacked player punches the previous attacker.
Note 2: Players that are re-streamed (moving out of the stream-zone of a player and moving back in), or - streamed in after spawning - may be punched without any animation problems. Hard to reproduce, since it only happened once for me (Streaming distance 400; migration distance 150; flying away and coming back with a helo).
Note 3: If a player gets hit by a vehicle, the player may be "punchable" afterwards.
Note 4: When a player is not "punchable", then the health is also not synced correctly.
Assumption: I assume that some animation dictionaries are not loaded correctly when spawning the player the first time.
Alt:V server used to reproduce on a Windows machine:
File | Checksum |
---|---|
fist-fight-server-1.zip | FB72BDF3D9687A0BEEDDFC20DACCD6F3C2DE37111174EE9F2558BAC728208930 (SHA-256) |
Use at your own risk.
A little test overview-matrix:
Case | A (first connect) | B (first connect) | A (reconnect) | B (first connect) | A (reconnect) | B (reconnect) | |||
---|---|---|---|---|---|---|---|---|---|
w/out WpnDmgHndl Debug | no | no | no | yes | yes | yes | |||
w/ true WpnDmgHndl Debug | no | no | no | yes | yes | yes | |||
w/ false WpnDmgHndl Debug | no | no | no | no | no | no | |||
w/out WpnDmgHndl Non-Debug | no | no | - | - | - | - | |||
w/ true WpnDmgHndl Non-Debug | no | no | - | - | - | - |
Note to the test results: I was using the weapon damage handler like this:
alt.on('weaponDamage', () => true);
// or
alt.on('weaponDamage', () => false);
when tested with the weapon damage handler.
I also have to note that for the above results, I only enabled and used the JS module.
Maybe, when I was trying to reproduce the issue I was thinking in the wrong direction.
In the beginning of the research I thought that maybe an unloaded animation dictionary may be the problem - but as it turns out it seems that the player model is not loaded correctly by the alt:V client itself.
Afaik the player model should be automatically loaded if it is either of model mp_f_freemode_01
or mp_m_freemode_01
- please correct me if I am wrong.
That said, after delaying the spawn of a player with one of those models above and requesting one of those models manually using natives.requestModel(...)
, the animation sync works fine.
My guess is that, by default by the alt:V client, the loading of the model is not awaited correctly.
@FabianTerhorst May that be the case?
Please test again with latest dev build.
Still happens for me on release 11.6.
Confirmed on release 12.10 and 13.0-dev12
Fixed in next dev