Players time out instead of crash report in playerDropped

Hi

It seems like the “playerDropped” event rarely report the game crash error anymore.
Instead, the reason of disconnection is now “Server->client connection timed out. Last seen XXXX msec ago.”

Currently, I use the playerDropped event to log crashes that happen on my server, this data is then used to map out where are located some crash if they are zone specific.
It seems like there is less reporting of the correct reason of disconnect, and the server only assume they disconnected by timing out players.

I think this is a valid use case because I know the crashes are most of the time caused by custom mapping, or replaced models, so this will lead to more invesgation by server owners and less reporting of “FiveM just crashed”.

I have observed playerDropped doesn’t report these game crashes (or at least in a very reduced number) since around February 8th or 9th.

I suspect commits around this date have changed this specific system. (fix(launcher/minidump) & fix(client/launcher) have been pushed around this date).
This is unverified, only an hypotheses.

1 Like

Yeah, I suspected this broke again at some point. Sadly, it’s a bit difficult to repro as it might be dependent on specific crash types (not) working, and intentionally inducing a crash when in-game is already difficult.

Similarly, I’m confused as to how this functionality breaks this… often. It’s explicitly fragile, yes, but still - odd.


Ah, in this case it turns out this breaks because the game process is (somewhat ‘obviously’, as we moved to asynchronous processing) already terminated by the time our custom handler runs. While this is ‘better’ for the user experience (the game window not appearing ‘stuck’ while the crash is being processed), it indeed also breaks this flow.

1 Like

Fixed, I think.

2 Likes