-
Notifications
You must be signed in to change notification settings - Fork 566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xeno Corpses Consumed By Weeds Glitching Out #6220
Comments
Oh forgot to add, when using alt + click to see the tile contents of the tile with the weed-covered runner in the pictures, the panel had no such corpse noted. Actually nothing was on the tile. Also, dunno if this is relevant but the pictures were taken post-crash on the Almayer though I had seen weed covered corpses moved multiple times earlier in the round via explosions while using the mortar. |
Not showing up in alt click is intentional; They also don't show up in right click, nor respond to left click, nor show up in the hover text on the bottom left. They are "transparent" to the mouse. However I am not able to reproduce this issue. Nor do I see any related runtime in that round. When you become weeded, you become anchored. Additionally, even if I edit their anchored variable, drop a bomb on them (had to make the weeds very healthy and the corpse very healthy to not destroy/gib) they unweed when they are moved since I have a signal for movement here: https://github.com/cmss13-devs/cmss13/blob/master/code/datums/components/weed_food.dm#L117-L119 |
Very interesting. The situation with the pics I grabbed was the Alamo had crashed into the Brig, marines pushed into the Alamo to take the core down. HEDPs were being thrown left and right and I saw this weeded runner corpse moving with the explosions. I was curious and tried to break weeds on it but none existed. I then tried to move it and could not. I wish I had another HEDP or I would have tested that. I did also see these corpses moving groundside so maybe something happened in round to unlock this behavior? Sorry for making you test it to no success. Just had not seen this behavior in rounds before this one. |
Mentioned it to you in DMs, but just for others this is likely also the same problem, but I do not know how to reproduce it: https://discord.com/channels/150315577943130112/964684928161808384/1191195372266197094 |
# About the pull request This PR resolves an issue where dropships were causing the `parent_turf` is mismatch with the mob's actual `loc` because a shuttle launch changes the turf of its contents, but doesn't call the `COMSIG_MOVABLE_MOVED` signal making the corpse location incorrect. I also renamed a cosmig signal to comsig that I previously created for weed_food. E.g. ![image](https://github.com/cmss13-devs/cmss13/assets/76988376/ec02ad02-753c-4404-a971-10fb6a5453f0) # Explain why it's good for the game Fixes #6220 # Testing Photographs and Procedure <details> <summary>Screenshots & Videos</summary> Put screenshots and videos here with an empty line between the screenshots and the `<details>` tags. </details> # Changelog :cl: Drathek fix: Fixed weeded corpses staying weeded if they were transported by shuttle /:cl:
Testmerges
#5401, #6103, #5957, #6148, #6039, #6150, #6146, #6178, #6212, #6155
Round ID
21993 - Recon Tango-Golf
Description of the bug
Xenos consumed by weeds after being dead on a weeded tile for some time can be 'moved' by the force of an explosion but if the weed under them is not broken, they stay in this weird limbo where you can not drag them, shoot them, punch them, etc. In this case there are no other weeds around and this runner corpse is still covered in weeds.
What's the difference with what should have happened?
Corpses should not bug out to the point of not being able to interact with them in any way. Unfortunately I can not replicate this bug on demand but am seeing it quite often round to round.
How do we reproduce this bug?
This is how the bug happened as I saw it for the screencaps above but could be related to something entirely different.
Issue Bingo
The text was updated successfully, but these errors were encountered: