[MIRROR] Further Prevention of Disposals Qdeletion #634
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
* Further Prevention of Disposals Qdeletion (#79714) ## About The Pull Request Fixes the consequences of #79629 - Verdict is still out on what the root issue is This has been an issue for the last two years and everything I go bananas trying to get a consistent reproduction case to figure out the root issue. After three session of picking, I think it's just a consequence of certain thing in disposals code sleeping due to `addtimer()` and whatnot so I'm just throwing in the towel and just making it so we stop sending atoms to nullspace for no reason. `target_turf` is typically always a present arg, but regardless we are guaranteed to get a valid turf to send people to instead of the deleted mob room. We still `stack_trace()` whenever this happens, so tracking this issue doesn't change any more than the present status quo- we just don't keep torturing mobs by sending them to the shadow realm. ## Why It's Good For The Game One day we'll figure out why we keep getting `null` passed into `forceMove()` like this but today is not that day. i know turfs technically can't be deleted but it's just there as a safety since we nullcheck anyways (which is the whole point of this fix). Let's just stop screwing with players for the time being also the code looks much better ## Changelog :cl: fix: Safeties in the code have been added to prevent things in disposals going into nullspace whenever they get ejected from a pipe - you will just magically spawn at the turf that you were meant to be flung towards. /:cl: * Further Prevention of Disposals Qdeletion --------- Co-authored-by: san7890 <[email protected]>
AnywayFarus
added a commit
that referenced
this pull request
Nov 15, 2023
Iajret
pushed a commit
that referenced
this pull request
Jan 26, 2024
* Fix runtime from triggering rush organ via goliath grab (#81101) ## About The Pull Request `trigger_organ_action`'s first and only argument is trigger flags to pass to `Trigger` The first argument if signals is the datum sending the signal  ## Changelog :cl: Melbert fix: Rush Gland now triggers correctly on being grabbed by a Goliath /:cl: * Fix runtime from triggering rush organ via goliath grab --------- Co-authored-by: MrMelbert <[email protected]>
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.
Mirrored on Skyrat: Skyrat-SS13/Skyrat-tg#25015
Original PR: tgstation/tgstation#79714
About The Pull Request
Fixes the consequences of #79629 - Verdict is still out on what the root issue is
This has been an issue for the last two years and everything I go bananas trying to get a consistent reproduction case to figure out the root issue. After three session of picking, I think it's just a consequence of certain thing in disposals code sleeping due to
addtimer()and whatnot so I'm just throwing in the towel and just making it so we stop sending atoms to nullspace for no reason.target_turfis typically always a present arg, but regardless we are guaranteed to get a valid turf to send people to instead of the deleted mob room. We stillstack_trace()whenever this happens, so tracking this issue doesn't change any more than the present status quo- we just don't keep torturing mobs by sending them to the shadow realm.Why It's Good For The Game
One day we'll figure out why we keep getting
nullpassed intoforceMove()like this but today is not that day. i know turfs technically can't be deleted but it's just there as a safety since we nullcheck anyways (which is the whole point of this fix). Let's just stop screwing with players for the time beingalso the code looks much better
Changelog
🆑 san7890
fix: Safeties in the code have been added to prevent things in disposals going into nullspace whenever they get ejected from a pipe - you will just magically spawn at the turf that you were meant to be flung towards.
/:cl: