[DiscordArchive] was there a particular reason why the requester guid check was down there instead of right at the to
[DiscordArchive] was there a particular reason why the requester guid check was down there instead of right at the to
Original source
was there a particular reason why the requester guid check was down there instead of right at the top?
rektbyfaith
01-30-2024, 11:50 AM #1Archived author: Northstrider • Posted: 2024-01-30T11:50:59.210000+00:00
Original source
was there a particular reason why the requester guid check was down there instead of right at the top?
Original source
uh, actually
rektbyfaith
01-30-2024, 11:53 AM #2Archived author: Tea • Posted: 2024-01-30T11:53:14.174000+00:00
Original source
uh, actually
Original source
this doesnt fix anything
rektbyfaith
01-30-2024, 11:53 AM #3Archived author: Tea • Posted: 2024-01-30T11:53:18.255000+00:00
Original source
this doesnt fix anything
Original source
Yea unfortunately something still must prevent a decline in the same packet handling loop from being handled after an accept, otherwise the deferred reference to the pointer in the rez function will be null still afaik Or take the easy way out and just check the pointer in the rez function
rektbyfaith
01-30-2024, 11:54 AM #4Archived author: HelloKitty • Posted: 2024-01-30T11:54:19.340000+00:00
Original source
Yea unfortunately something still must prevent a decline in the same packet handling loop from being handled after an accept, otherwise the deferred reference to the pointer in the rez function will be null still afaik Or take the easy way out and just check the pointer in the rez function
Original source
because this still happens
* send accept (ok, has resurrect)
* queued to later update tick (waiting for TELEPORT_ACK)
* send decline (ok, resurrect not cleared by accepting, still waiting)
* resurrect data deleted
* accept is processed
* BOOM
rektbyfaith
01-30-2024, 11:54 AM #5Archived author: Tea • Posted: 2024-01-30T11:54:54.597000+00:00
Original source
because this still happens
* send accept (ok, has resurrect)
* queued to later update tick (waiting for TELEPORT_ACK)
* send decline (ok, resurrect not cleared by accepting, still waiting)
* resurrect data deleted
* accept is processed
* BOOM
Original source
ah, the crash happens during the delayed operation?
rektbyfaith
01-30-2024, 11:55 AM #6Archived author: Northstrider • Posted: 2024-01-30T11:55:15.660000+00:00
Original source
ah, the crash happens during the delayed operation?
Original source
yeah that's fucked up. k, will fix
rektbyfaith
01-30-2024, 11:55 AM #7Archived author: Northstrider • Posted: 2024-01-30T11:55:53.381000+00:00
Original source
yeah that's fucked up. k, will fix
Original source
you need to modify ResurrectionData struct to include a `State` member and reject the opcode if it had a response already
rektbyfaith
01-30-2024, 11:56 AM #8Archived author: Tea • Posted: 2024-01-30T11:56:33.923000+00:00
Original source
you need to modify ResurrectionData struct to include a `State` member and reject the opcode if it had a response already
Original source
https://github.com/Ovahlord/TrinityCore/...e316f6679c like this?
rektbyfaith
01-30-2024, 12:03 PM #9Archived author: Northstrider • Posted: 2024-01-30T12:03:55.316000+00:00
Original source
https://github.com/Ovahlord/TrinityCore/...e316f6679c like this?
Original source
eh, moving the inline initialization into ctor, sec
rektbyfaith
01-30-2024, 12:04 PM #10Archived author: Northstrider • Posted: 2024-01-30T12:04:17.536000+00:00
Original source
eh, moving the inline initialization into ctor, sec
1 Guest(s)
1 Guest(s)