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

Rejecting vehicle spawns/edits deletes vehicles #358

Open
carsakiller opened this issue Aug 13, 2024 · 1 comment
Open

Rejecting vehicle spawns/edits deletes vehicles #358

carsakiller opened this issue Aug 13, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@carsakiller
Copy link

Fill out general information
OS: Ubuntu container
BeamMP-Server Version: v3.4.1

Describe the bug
When cancelling a vehicle spawn, the player's vehicle will be deleted.

When cancelling a vehicle edit, the player's vehicle will be deleted after some delay (~5 seconds, maybe).

To Reproduce
Steps to reproduce the onVehicleSpawned problem:

  1. Return 1 from a onVehicleSpawn handler
  • Returning math.random(2) == 1 may make the effect more obvious, as it is not just preventing the spawn of a car, it is actually deleting your vehicle if you already have one. Using a randomizer allows you to somewhat easily get a vehicle spawned in first, (hopefully) and then reject the change of that vehicle.
  1. Keep spawning a vehicle until you actually get one and it is not rejected
  2. Try changing vehicle (not spawning new)
  3. Notice that it did not just prevent the vehicle from changing, but it actually deleted your current vehicle.

Steps to reproduce the onVehicleEdit problem:

  1. Return 1 from a onVehicleEdited handler
  2. Try editing your vehicle
  3. Wait for multiple seconds, maybe 5-10.
  4. Your vehicle will have been deleted.

Expected behavior
I didn't expect cancelling to just delete the player's vehicle. I thought it would either prevent the spawn/edit from occurring at all (all clients), or at least prevent propagation at the server (to other clients) and then ask the initial player's client to revert the changes/spawn.

Is the current behaviour as-designed? It was very unexpected for me, as I assumed spawning/editing would first ask the server for permission before the client proceeded with the operation, due to it being cancellable. I can see how that could be slow and possibly hard to achieve in BeamNG, so perhaps just performing a “patch” after a cancelled event to resync the initial client would be best?

@carsakiller carsakiller added the bug Something isn't working label Aug 13, 2024
@20dka
Copy link
Collaborator

20dka commented Aug 13, 2024

you are correct about the current behavior, the event is sent to the server after it has already happened clientside. I am not sure about any concrete plans to change this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants