Hello. For a few days, possibly more, characters in Twilight Daycare are randomly dying on peoples’ clients. This is affecting both NPCs and non-NPCs alike. We are currently using the OLD avatar joints system (we can’t upgrade at the moment) and there have been no changes made to the game that would affect this in a long time. I’m not sure if it’s a streaming-related issue, something to do with the fact we’re using old avatar joint characters and there was a regression with old characters, or something else.
Update: I have confirmed it isn’t related to if Avatar Joint Upgrade is toggled, because it still happens even when I’ve upgraded the characters to the new rig.
Disabling the Dead state for the Humanoids seems to be a temporary fix to this problem. My guess is it’s streaming related because both times it happened to me, it was after I respawned. However this solution is not ideal because we rely on the Humanoid.Died event firing in various places.
I still also hear the death sound playing even though the state is disabled.
To reduce rendering and streaming load, our game places some object-heavy areas approximately 100,000 studs away from each other and moves players between them using teleportation within the same place.
This setup has been working without any issues for a long time. However, starting yesterday, players began hearing the death (“oof”) sound almost every time they are teleported.
(We first noticed the issue yesterday, although it is possible that it actually started earlier and simply went unnoticed until then.)
A few additional details:
Avatar death is disabled in our game.
The teleport system itself has not been changed recently.
The distance between areas and the teleport method have not changed.
This behavior started suddenly without any relevant game-side updates.
We’re currently unable to determine what is causing it and are investigating whether it may be related to a recent Roblox engine change.
streaming enabled bug, just dont use streamingenabled if possible
it might also just be with streaming, i’m not sure, but i doubt that as regular streaming thats built in has less restrictions and ive never seen that happen in a game without streamingenabled
i do also know that some sort of death event is fired after a character is streamed out according to a few people i know (that could be wrong) so its for sure related to that afaik
Hello There! I hope you’re doing well.
Thank you for taking the time to submit this issue and for reading our message.
To help us move forward, we’d appreciate your support with a few questions:
• Is this issue still occurring on your device?
• If so, could you please send us a microprofiler dump File, system information & log?
Don’t worry — we’ve got you covered!
You can find step-by-step instructions on how to generate and send the log How to post
a Bug Report - Bug Reports - Developer Forum | Roblox
Following these steps will help us better understand the issue and work on a solution
more efficiently.
Thank you again for your cooperation!
The issue was first reported by my player base at 10:53 AM Eastern US time, although it is said to have been appearing the prior evening. It is still occurring to this date. I have not been able to replicate it myself, and I have no microprofile dumps or logs to offer yet. Nothing appears in the client console. StreamingEnabled is on, and it does seem to happen in areas where I would expect the streaming in/out of characters. Anchored players may be immune to this effect. The effect is completely client-side: random characters will appear disassembled only for that client.
Here are a couple of the clearest screenshots. I have lots and it seems to be affecting many people often.
Happening in our game as well. This creates a potential exploit, since you cannot see their character moving around, but they are still alive and well on the server.
I would imagine this is some weird edge case with streaming, where the torso of the character gets streamed in before the head, killing them. Maybe it would be fixed if you manually set characters to be Atomic?
After some simple testing, it seems like setting characters to Atomic indeed fixes this issue. So there you go. I suppose you can’t depend on the parenting order with Nonatomic, but this seems a little silly either way.
I’ve patched the issue around a week ago so it’s not currently happening (I did this by disabling all humanoids’ Dead state in a localscript) but judging from later replies I can only assume it’s still happening.
Stream another player’s character out for 10 seconds by walking away, then stream them back in by getting close.
Subject the player to a .Touched event tracked by your client on a part you own.
NetworkOwnership will temporarily shift in some manner, and the player may fall apart and be affected by physics with the .Touched part, even if the collision table dictates they should not collide.
NetworkOwnership debug visualization is on. .Touched event fires on parts belonging to 4 nearby recently streamed out characters, one character breaks:
In the past, this bug was noted, but it only resulted in players being moved around client-side by objects that shouldn’t affect them. It was ignored as a silly quirk. Now, the movement itself seems to break all the joints and make them an irreparable pile of parts, whereas before it would resolve when the character started moving again.
I have a MicroProfiler dump file for a 128 frame section of gameplay where this happened, although I did not find it illuminating. The Script_FieldTools Timer/Thread is where the .Touched event is connected. I will send it in a DM.
Fortunately, our game doesn’t require the player death feature, so we worked around the issue by simply disabling the “Oof” death sound.
Because of that, I can no longer confirm whether the issue is still occurring in our own game. However, I still see it happening in other games.
Many Speed Escape games frequently teleport players back to the starting area from locations that are very far away. In several different Speed Escape games, whenever another player teleports back to the start, the “Oof” sound plays as they appear.
Because this is happening across multiple games, I believe the issue is still present.
I would appreciate it if you could continue investigating and resolve the issue.
Thank you for taking the time to read our message.
Seeing your reply and as the original poster of this report you confirm this is no longer happening we will proceed to close this report.
Thank you for taking the time to submit your request in the forum. We appreciate your collaboration in helping us improve.
But If you, or other user encounter any further problems or issues, please don’t hesitate to report them again in a new report. With all files available.
