[Doors] Remove door dev tools spam on client controlled doors #2824
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
catapultam-habeo
pushed a commit
to catapultam-habeo/pyrelight-server
that referenced
this pull request
Mar 27, 2023
…2824) * [Doors] Remove door dev tools spam on client controlled doors * Update client_packet.cpp * Update client_packet.cpp * Update ruletypes.h
fryguy503
added a commit
to wayfarershaven/server
that referenced
this pull request
Aug 1, 2023
There was an issue on Discord that is incredibly obscure, apparently only on Windows, can't be reproduced in a way that makes it easy to trap. @hgtw @KimLS both tried to reproduce and failed to do so and they run Windows development setups as well. The issue is stems from a door in the zone that is a switch that appears to also be client controlled. Never have I seen in any zone outside of this zone where the client tries to control a door entity in this way. Related PR and issue EQEmu/Server#2824 When a NPC opens it and the door it is related to, the client will try to "force" the door into a zero state when the server hasn't done so itself fast enough and will spam "OP_CLICKDOOR" packets over and over. Since we've dumped a ton of time into this with no real solution other than workarounds which appear to be not having the NPC mess with the switches, this PR adds a static blacklist for now which codifies the workaround. https://discord.com/channels/212663220849213441/1134586539389755412  Original report "Valorith [Clumsy's World] OP — 07/28/2023 3:41 PM Looking for some validators/people to test an issue that we're seeing on several servers as it appears to be on master and seems to have started in/before May. There appears to be an issue where Temple of Sol Ro will crash after 5-10 minutes of being in zone. There won't be a crash log or any indicator other than you just getting disconnected. You will not be able to reconnect and zone into soltemple and you will not be able to shut the zone down in-game. The zone process must be nuked. If the zone is booted but in stasis (empty) this problem never appears. I have not been able to isolate it to any other zones (yet) Edit: Plenty possible this is a windows server issue (as most seem to be). This has been confirmed on multiple windows servers, to include with NO scripts or plugins active on binaries."
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
In certain zones, there are client controlled doors that are triggered or linked to other doors that the client will try to force into a desired state. It causes spam for GM's in various zones. This is even more so when many clients are in the zone all trying to force the state of the door simultaneously.
It's fine to let the client control these doors, but the spam can be unruly and lead to believe that there is a deeper issue.
Solution
The solution for now is to distance check these doors for clients before trying to display the dev tools prompt and triggering quest door click events.
If not within distance, we still process
HandleClickinternally to let the client trigger the door back to the state it should be per normal