Add baseevents fallback for vehicle event triggers

[Cocodrulo]

Description

This pull request adds a fallback implementation for vehicle-related player events in server/events.lua to ensure core vehicle event handling works even if the baseevents resource is not running. The new code tracks when a player enters, aborts entering, enters, or leaves a vehicle, and triggers the appropriate server events.

Baseevents fallback implementation:

• Added a thread that monitors the player's vehicle interactions and triggers server events (baseevents:enteringVehicle, baseevents:enteringAborted, baseevents:enteredVehicle, baseevents:leftVehicle) when the baseevents resource is not started. This ensures consistent vehicle event handling regardless of resource state.
• Implemented a helper function GetPedVehicleSeat to determine the seat index the player occupies in a vehicle.

Checklist

• I have personally loaded this code into an updated qbcore project and checked all of its functionality.
• My code fits the style guidelines.
• My PR fits the contribution guidelines.

[Cisternita]

not useful

[Cocodrulo]

not useful

Why not? Why make a full event of QBCore relly on the existance of a script or not in the server and don't have a fallback?

[Qwerty1Verified]

I haven't tested this event personally, but could we benefit from using the CEventNetworkPlayerEnteredVehicle game event instead of the thread?

[Cocodrulo]

I don't think that event will detect the seat change

[Qwerty1Verified]

Do you mean when someone shuffles seat without leaving the vehicle?

[Cocodrulo]

exactly

[Cocodrulo]

And also when entering is aborted

[Qwerty1Verified]

From what I see, the current logic is: if not inVehicle -> if IsPedInVehicle -> Get Seat. This check only seems to occur during the transition from no vehicle to a new vehicle. The same goes for if the loop runs whilst they're trying to get into a vehicle: if not inVehicle -> if GetVehiclePedIsTryingToEnter.

[Cocodrulo]

From what I see, the current logic is: if not inVehicle -> if IsPedInVehicle -> Get Seat. This check only seems to occur during the transition from no vehicle to a new vehicle. The same goes for if the loop runs whilst they're trying to get into a vehicle: if not inVehicle -> if GetVehiclePedIsTryingToEnter.

True, Do you know if that event triggers every time someone tries to get into vehicle? I mean, is it like the shooting one that triggers once for each ped near the shooting or is it only one by the player trying to get into a vehicl

[Z3rio]

I dont really think we should be forcing our users to use baseevents, which this is pretty much doing. It isnt performant at all, and it is very well possible that servers choose intentionally not to use baseevents - which this would circumvent.
Afaik, baseevents is generally considered deprecated, barely 1% of FiveM uses it, for good reason - https://5metrics.dev/resource/baseevents

[Qwerty1Verified]

I agree we shouldn't force users to use baseevents, especially due to its performance. In theory I don't think this PR forces people to use baseevents, since the logic acts as a stand-in and just fires off those same events but not with the purpose of people having to listen to them (unless you're referring to the logic being a stand-in, and also running the same).

The way I see it is people should instead be using QBCore:Client:VehicleInfo since it's easier to standardise, as it's tied to the core rather than a resource people mightn't be using. This PR allows qb-core to listen to the baseevents triggers even if it's not in use, and then fire off QBCore:Client:VehicleInfo.

To me, that just leaves the main question of:

• If we're accounting for baseevents not running, it's likely they removed it for a reason (like Zerio mentioned). Should we be implementing something that runs similarly to how baseevents does?

Also, was my first comment ever looked into further for entering vehicles? If not I can try to fit some time in to look at it: CEventNetworkPlayerEnteredVehicle
I should check the resmon on this thread too.

If we can't find something more event based for everything, I believe our best course of action is:

• Listen for player enter vehicle event and kick off a polling thread from there, OR poll less frequently for player enter (300-500ms, serious resmon improvement over 0-50ms)
• Poll for seat change and vehicle less frequently (300-500ms again?). If exit, destroy thread.

[Cocodrulo]

I'll look into this