Error Log/Crash about eventqueue-fix HOT 6 CLOSED

Working on it.

from eventqueue-fix.

Finally got around to debugging the crash, and it turns out that DHooks sometimes fail to parse data. Should be fixed with the latest commit. Closing this issue for now. If you experience more crashes let me know

from eventqueue-fix.

L 07/02/2021 - 14:56:16: [SM] Exception reported: Entity 1843 (1843) is not a CBaseEntity
L 07/02/2021 - 14:56:16: [SM] Blaming: eventqueuefix.smx
L 07/02/2021 - 14:56:16: [SM] Call stack trace:
L 07/02/2021 - 14:56:16: [SM]   [0] AcceptEntityInput
L 07/02/2021 - 14:56:16: [SM]   [1] Line 300, N:\csgo\sm 1.10\eventqueuefix.sp::ServiceEvent
L 07/02/2021 - 14:56:16: [SM]   [2] Line 343, N:\csgo\sm 1.10\eventqueuefix.sp::OnPlayerRunCmd

Had a big ol' spam of this (about 500k lines in 12 minutes).

Also possibly related, had a couple crashes on a specific map (surf_sandman_v2):
https://crash.limetech.org/t547mzyzs5v5

What map was the first issue encountered on?

Also, the second issue is known, but I'm not sure what the proper solution would be as the problem relates to dhooks not having a way to check if a string is null or valid.

from eventqueue-fix.

What map was the first issue encountered on?

surf_perennial

from eventqueue-fix.

It might be a good idea to store event.caller as an entity reference too. Entities might be dying and then the index that's stored could point to something wrong and be erroring the AcceptEntityInput call.

Also I just realized that for SetClientEvents, the event.activator and event.caller stuff should probably be set to the client so timer persistent data for example doesn't use the events on the wrong players when multiple people join/disconnect (and change player indices).

from eventqueue-fix.

I am not able to replicate the issue on surf_perennial. Could you try the latest version (1.1.0) in the master branch and confirm the problem is still persistent? @sneak-it
The crash you experienced on surf_sandman is a DHooks related issue. I will create an issue at the updated DHooks fork, or create my own fork at some point to get this resolved when I have a better idea of what is happening.

The issues you brought up regarding persistent data and dying entities should now be resolved as caller is stored as an entity reference, and event.activator is now the clients unique serial identifier which is resolved at run-time. @rtldg

from eventqueue-fix.