Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Severe regression of weapon/gunfire syncing in 3258 #2934

Closed
Lucas7yoshi opened this issue Nov 15, 2024 · 3 comments
Closed

Severe regression of weapon/gunfire syncing in 3258 #2934

Lucas7yoshi opened this issue Nov 15, 2024 · 3 comments
Assignees
Labels

Comments

@Lucas7yoshi
Copy link
Contributor

Lucas7yoshi commented Nov 15, 2024

What happened?

Actual gunshot events appear to have massively regressed compared to 3095. Tasers sound like they are empty until they fire for remote clients several seconds later. Shotguns have a large delay, muskets do not even shoot at all. Up n atomizer projectile syncs instantly but the actual shoot effect shows up seconds later, laser minigun doesnt seem to work at all.

3095 (Working well): https://youtu.be/7IfqwRMYFzk
3258 (Bad to awful sync): https://youtu.be/KEt_us7j9MU

Expected result

Gun sync quality should be similar or identical to 3095.

Reproduction steps

  1. Start up a server on 3258
  2. Connect with two clients
  3. Go to the same area
  4. Shoot various firearms, shotguns, up n atomizer, and stungun as well as the musket are best for showing the discrepancy
  5. Repeat for 3095
  6. Compare

Importancy

Unknown

Area(s)

FiveM, FXServer, OneSync

Specific version(s)

FiveM 3258 (Canary, heard reports across stable/beta), Tested latest FXServer (11012)

Additional information

There needs to be more importancy options... I would classify this as "severe" for gunplay focused servers, and quite unideal for others.

Environment is identical, only change between is the sv_enforceGameBuild value.

@Lucas7yoshi Lucas7yoshi added bug triage Needs a preliminary assessment to determine the urgency and required action labels Nov 15, 2024
@tens0rfl0w
Copy link
Contributor

Some additional input:
In my testing, this seemed to only occur when the shooting task was AimGunOnFoot. Sitting in a vehicle, shooting the gun without aiming (just pressing the left mouse button), and other scenarios did not cause this type of delay. Needs some additional confirmation, as I just tested this briefly, but when cancelling all other tasks with some hacky usage of CLEAR_PED_TASKS this also fixed this delay.

prikolium-cfx pushed a commit that referenced this issue Dec 12, 2024
Fix for #2934

On build 3258+ there would be a significant delay between shot in source
client and shot in remote client. This would only appear when aiming on
foot. E.g. firing a weapon from a car worked fine.

The problem appeared because for some reason in 3258+ GTA5 started
syncronysing `CWeapon::m_State` ower the network. It is not the case in
3095 and below. The state is now updated in
`CNetObjPed::UpdateWeaponForPed()`. This leads to `m_State` be set to
`STATE_WAITING_TO_FIRE` on remote client before the shot actually
happens on remote client. So `CTaskAimGunOnFoot::Aiming_OnUpdate()` is
blocked until `CWeapon::m_State` is synchronised back to `STATE_READY`
and only after that shot on remote client actually happens.

This patch returns the original 3095 behavior.

It is unclear why the base game behavior was changed this way and why it
doesn't cause issues in GTA Online. My assumption is that it has
something to do with the order of events: e.g. maybe we somehow
synchronise states too early. And the state sync was added just in case.
Regardless of the reasons - I've tested build 3258+ with the patch and
there seems to be no issues, synchronisation works fine, no new problems
appear because of it (both with onesync on and off). The `CWeapon` state
is being updated as intended by the usual `CWeapon::ProcessState` (same
as it does on 3095)
@Nobelium-cfx
Copy link
Contributor

A fix should be available on Canary by now (0991173). @Lucas7yoshi Can you please confirm that it fixes the issue for you?

@Lucas7yoshi
Copy link
Contributor Author

A fix should be available on Canary by now (0991173). @Lucas7yoshi Can you please confirm that it fixes the issue for you?

Tested and seems to be resolved, thanks!

2024-12-14.00-00-07.mp4

@github-actions github-actions bot removed the triage Needs a preliminary assessment to determine the urgency and required action label Dec 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants