Add vehicle status player events

[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

[Cocodrulo]

If've check and we cannot replicate the events in baseevents just with CEvents. There is just one event useful here that is the one you mentioned "CEventNetworkPlayerEnteredVehicle". The problem is that baseevents provides (and therefore QBCore uses) four events:

• enteringVehicle
• enteredVehicle
• enteringAborted
• leftVehicle

With the provided event we can detect the enteredVehicle and kind of the leftVehicle if we make a loop when entered a vehicle and check if it is still inside or not. But the enteringVehicle and the enteringAborted cannot be detected (at least in any way I found). So we have really to options, continue with the baseevents fallback and make those event reliable and works under any circumstances or just do two out of four events. What do you think? @Qwerty1Verified

[Z3rio]

If've check and we cannot replicate the events in baseevents just with CEvents. There is just one event useful here that is the one you mentioned "CEventNetworkPlayerEnteredVehicle". The problem is that baseevents provides (and therefore QBCore uses) four events:

• enteringVehicle
• enteredVehicle
• enteringAborted
• leftVehicle

With the provided event we can detect the enteredVehicle and kind of the leftVehicle if we make a loop when entered a vehicle and check if it is still inside or not. But the enteringVehicle and the enteringAborted cannot be detected (at least in any way I found). So we have really to options, continue with the baseevents fallback and make those event reliable and works under any circumstances or just do two out of four events. What do you think? @Qwerty1Verified

I mean, there are 10000+ servers using qb-core, https://5metrics.dev/resource/qb-core
And less than 500 servers IN THE ENTIRETY OF FIVEM, that use baseevents, https://5metrics.dev/resource/baseevents

this counts literally all servers, realistically, this is less than a percentage of all qbcore users.

It is very apparent that baseevents, and the functionality it provides, is something people (excuse my language) couldnt care less about. And something that 99% of qbcore servers live without daily.

As you mention though, we do use baseevents in some of our default qb-core logic. More specifically, for the QBCore:Client:VehicleInfo event, which in turn triggers these events:

• QBCore:Client:EnteredVehicle

used in smallresources for ejection logic + shuff

• QBCore:Client:EnteringVehicle

used in vehiclekeys for robbing logic

• QBCore:Client:LeftVehicle

used nowhere

(The QBCore:Client:AbortVehicleEntering event is also used nowhere)

All of the abortion logic of the entering vehicle is handled in the respective script(s) mentioned above.

So, we could in theory 100% make due with the "CEventNetworkPlayerEnteredVehicle" event.

In my opinion, we should rather just rework the above mentioned scripts to use the "CEventNetworkPlayerEnteredVehicle" event, as that should in theory perform better(?).

[Cocodrulo]

@Z3rio I know that baseevents it's used by anoyne, I don't use it either. But I think that if QBCore had an event to check enetering and leaving vehicles, scripts will be more optimized (each scripts has a loop to check for entering a vehicle). So I could use the CEventNetworkPlayerEnteredVehicle to check when entered and left the vehicle and the entering just be the same that when you enter. Do you agree?

[Z3rio]

I agree that would be an optimal solution, yeah. But is the CEventNetworkPlayerEnteredVehicle event really annoying to use / badly documented? If not, then I'd argue we have no real reason to make our own event that does the exact same thing - scripts should/could just listen to CEventNetworkPlayerEnteredVehicle directly.

So the real work here would rather be actually refactoring all applicable qb-core resources to not use baseevents in its entirety (and not include in txadmin recipe), in favor of the CEventNetworkPlayerEnteredVehicle event

[Qwerty1Verified]

Yeah I'd rather run a thread when needed than 24/7, so if we can avoid running a thread 24/7 by doing what I mentioned in an earlier comment we should be able to both remove any baseevents dependence, and improve performance overall.

For example, if a player is not in a vehicle, we don't need to know whether they left or switched seats. We do need to know if a player is in a vehicle though so we can then look for those other changes, which the game event gives us

[Cocodrulo]

I think that making a QBCore wrapper is the best option @Z3rio beacuse that event only provides the "player entered" functionality, but player left still needs a thread, so having it only in QBCore is better than in every single resource, right?

I propose this:

• Use CEventNetworkPlayerEnteredVehicle to trigger QBCore:Client:EnteredVehicle and QBCore:Server:EnteredVehicle
• When a player have antered a vehicle (checked with CEventNetworkPlayerEnteredVehicle) a thread is checking when player left vehicle and then triggers QBCore:Client:LeftVehicle and QBCore:Server:LeftVehicle

Do you @Z3rio and @Qwerty1Verified agree with this?

[Qwerty1Verified]

Yeah sounds in line with what I mentioned.

It only runs when necessary in that case, still facilitates our required use case, and since the timing for those other events are less critical also allows us to reduce the loop frequency for massive performance gains.

I also agree having a centralised and optimised thread that fires events is better than having repeated logic and threads running across several first and third party resources. We can control the conditions, and reduce repeated computation doing this.

[Cocodrulo]

@Qwerty1Verified if you could check out the code and tell me what do you think. It was added:

QBCore:Client:EnteredVehicle

RegisterNetEvent('QBCore:Client:EnteredVehicle', function(vehicle, seat, model)
    print('Entered vehicle', vehicle, seat, model)
end)

QBCore:Client:LeftVehicle

RegisterNetEvent('QBCore:Client:LeftVehicle', function(vehicle, seat, model)
    print('Left vehicle', vehicle, seat, model)
end)

QBCore:Client:ChangeSeat

RegisterNetEvent('QBCore:Client:ChangeSeat', function(vehicle, seat, newSeat)
    print('Change seat', vehicle, seat, newSeat)
end)

Same server events (replace "Client" with "Server") but instead of vehicle entity, its vehicle network id

[Cocodrulo]

Did you take a look? @Qwerty1Verified I tried in my server and it worked

[Cocodrulo]

@Qwerty1Verified

[Qwerty1Verified]

The changes look good, but this breaks the table structure passed by the QBCore:Client:VehicleInfo event, which is the event that usually fires these Entered/Exited events.

[Cocodrulo]

yes, but there isn't lots of people that uses the current system, since it relies on baseevents and there isn't lots of servers that use it. https://5metrics.dev/resource/baseevents

[Qwerty1Verified]

I think we could make it work with VehicleInfo with minimal modifications (I'm currently testing this out don't worry). Upon testing, I do notice a check that seems to be causing the thread to not begin.

When the game event is triggered, you setup lastVehicleData, manually trigger the event, and then call the vehicle thread function. When this function begins, it returns if lastVehicleData.vehicle has a value, which it does since it was previously set via the game event. Due to that, the thread doesn't begin, unless I'm missing something during testing?

[Cocodrulo]

I remembered trying it and working. But reviewing my code now, it doesn't make sense. So I removed the vehicle manual declaration.

About the VehicleInfo. I think it is better to separated it in different and self named events so it is clear what I'm cheking and so if I'm only checking for vehicle entering that function don't be triggered more times that necessary.

[Qwerty1Verified]

Ah ok thank you, I'll take another look with those changes and compare with mine. As for VehicleInfo, that event actually does fire off specific events, it's just an internal event we use to consistently build data, but after that the specific events are fired off based on the event field being concatenated. I do very much agree with having separate events from a developer perspective, it makes sense, but can still work that way with VehicleInfo.

In theory you could listen to the entire VehicleInfo event itself if you wanted all events, and then run your own checks against the event field, which I do kinda like.

[Cocodrulo]

So what do you want to do?

[Qwerty1Verified]

I just need to check out that new change, and ensure that we tackle the key points whilst keeping developer usability as is. I pretty much finished the changes on my end and they were very minor.

[Cocodrulo]

perfect!!