mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2026-02-09 07:49:09 +00:00
f5e30da403
## About The Pull Request Fixes #74126 Hi vsauce, Timberpoes here! Brains are being sent the gem room. But why???? *musical sting* Issue was caused by #73026  This early return added to brain Insert is the root cause. Let's have a butcher's at some code, eh?  Here we have a parent call in `. = ..()` and then a check for brains and brainmobs to do some special snowflake stuff before `brain.Insert(new_head_owner)`. This causes a problem. But WHY??????? Well... The parent call already inserts the brain, but without any snowflake stuff done.  The parent call returns and the child proc `/obj/item/bodypart/head/try_attach_limb()` which mashes the brainmob into the brain and slams the `brain.Insert()` proc a **second** time. This is a bug. But it worked despite being a bug, because the brain's Insert proc would still do logic even if the Insert was technically not successful. But... We come back to this again:  If the new early return for the parent call is FALSEy, it stops all that wonderful brainmob code from being executed.  ... And ITS parent call is FALSE because `owner == receiver` is now TRUE, as it was set the first time `Insert()` was called all the way back in `/obj/item/bodypart/proc/try_attach_limb()`. So the first `brain.Insert()` call in the parent `/obj/item/bodypart/proc/try_attach_limb()` succeeds, but brainmob related code isn't executed because the head bodypart hasn't set up the brain's state correctly at this point. And the second `brain.Insert()` call in the child `/obj/item/bodypart/head/try_attach_limb()` which occurs after the brain's state is correctly set, now fails because of an early return when the insertion fails (the owner is already the receiver). So, the old code only worked because it was bugged. Fixing the bug where it worked, created a bug where it didn't. But wait, why the gem room? Well, since all the code that handled qdeleting the brainmob failed, it persisted in the brain **even after the brain was inserted into the body**. Where does the body store all of its organs? That's right, it transfers them all to ~~the balls~~ nullspace!  And what is the brainmob? A mob! And what did it have? A client! And what happens when cliented mobs find themselves in nullspace when a Life() tick happens? A vacation to the gem room! I have opted for a very simple fix. I've moved the code into `/obj/item/organ/internal/brain/Insert()`. It now checks to see if it's in a head when it's inserted into the new brain_owner. If it is, the brain handles setting up its own state so it can successfully transfer. `brain.Insert()` only gets called once instead of twice and the snowflake behaviour is no longer controlled by the head. In my testing of shearing off heads of guest clients and reattaching them, this fixes the bug without any gem room errors on the other clients. ## Why It's Good For The Game Feex. ## Changelog 🆑 fix: Having your severed, brain-filled head reattached to a body no longer teleports your brain to the mythical Gem Room. /🆑
