The first clip is from studio playtesting. You can clearly see the parts keep respawning. The second clip is from the live game. You can see that after a few seconds, the parts stop respawning, because you have been desynced. I have uncopylocked the place (link above) so anyone can view the simple scripts.
Base concept of them is invoking a RemoteFunction two times every heartbeat, and printing out the response from the server. The server prints out the amount of times it has received a request, and returns that to the client. The server also spawns parts every second and adds them to Debris (so they get deleted after a second). After a while, the parts no longer respawn, because the client has desynced.
robloxapp-20200512-1811269.wmv (1.7 MB) robloxapp-20200512-1812341.wmv (1.7 MB)
@ post approval Should I create a new post with more detailed repro, or keep using this thread?
@rickje139 and @PeZsmistic I was unable to verify the behavior when I joined instances of that game (I couldnât find other players showing the effect) so I was unable to verify if this specific flag was related.
@TheGuyWithAShortName the issue did not reproduce for me reliably in that game even though there were other players moving nearby, so I was unable to verify the relationship of the flag to this issue.
@Coasterteam, @DevFlonk, I was able to confirm that the effect is unrelated to the feature we previously released by temporarily disabling the feature. However I also enabled some additional logging locally that has provided some more context for your games in particular.
For Pinewood Computer Core, I suspect what is happening is that physics updates for the trains are consuming the majority of the physics update bandwidth. Coasterteam, you can try moving the spawning platform to be physically further from the trains, or you can try making the trains less physically complex (e.g. attaching Bogies with a rigid joint like a weld instead of a hinge constraint). When objects are connected with constraints/joints that allow movement then we need to expend bandwidth to describe dynamic movements of those connections, but if the parts are connected rigidly like with a weld then we donât need to expend physics bandwidth for the sub-components.
For Tank Warfare Arcade, it similarly looks like the tanks themselves are highly physically complex. Due to their complexity and the way that we manage physics update sending, it is likely that each client may only be able to see one or two tanks moving at a time (each tank on its own is large enough to expend the step budget for physics sending).
From these, my guess for Be an Alien - Renewal is that some alien forms (like that slithering snake) may also be highly complex and also be consuming a large portion of the budget.
@PeZsmistic in the linked videos, which character was the local player? We perform physics send throttling by distance to the playerâs character, so if you have e.g. a free-cam mode, and the camera goes far from the playerâs character (or Player.ReplicationFocus if set) then you will see similar effects.
Thanks for looking into it, itâs very weird you couldnât find instances of this in my game; I could find them within ~10 minutes, and I also saw one user in chat asking if other people could see them, implying they were being seen as teleporting around.
Was anything related changed recently? I have never ever had problems like this until recently. Something changed for the worse, and many other users are seeing similar issues.
The local player was invisible, centered on the camera position (I didnât want to disrupt other players). It was definitely physically nearby.
I am doing something a little bit strange for creating the custom character (old code that will be replaced soon) that involves removing all of the parts from the character Model, and replacing them with parts cloned from a template character model. But again, I have never ever had issues like this.
This is still happening in my game, but Iâm waiting for a new server to confirm itâs still an issue given the below reply.
I donât think it has been fixed.
It appears to be fixed as of right now, about 4/5 hours ago it was still happening. i guess it just got fixed.
â edit, i just noticed it happened again in my game.
Youâre stating here that itâs caused by high physics bandwidth. How exactly does that have to do with RemoteEvents/Functions and how does it explain four bricks causing complete disconnects? This seems like a completely unrelated explanation to meâŚ
Also, @rickje139, it still happens in my test game. Does not seem like anything changed.
could you try joining me? i just noticed its happening again.
yet the server ping is fine.
âedit
whoops, i noticed i had the follow button set to friends only, try it now.
Could you try joining me? Its happening in my server right now.
https://www.roblox.com/users/19823479/profile
Iâm having the same desync issue as everywhere, on that game. I think one of the workarounds is trying to minimise all remote traffic⌠which may be very difficult.
this has never happened until a few days ago.
contact me when youâre online and iâll get a lot of people in the test server to make the desyncing issue show up.
I was not trying to imply that. I definitely think itâs a roblox issue, but itâs caused by heavy RemoteEvent/Function traffic, so a workaround for it would be reducing that.
Thats not really possible in my physics game, there is no way to reduce the remote event traffic, every mechanical block needs a remote event to replicate the physics to the serverside so that other players see it and it wont glitch them out.
Oh itâs definitely possible. You could fire just one remote every physics cycle for all the blocks in a creation (dictionary {[part]: changes}). If you want even more throttling (would look increasingly awful though), only fire it every n physics cycles. And Iâm sure there is more remote traffic than just those physics. Every reduction might help.
this is not possible in my game as of now, the game is 5 years old and its somewhat hardcoded, there is nothing i can do to acomplish that unless i rewrite the full game.
Thank you for the information and your test results,
We were able to conclude the trains at Pinewood Computer Core caused the latency issues ourselves by doing A-B testing, trains and no trains, this is very strange as weâve not seen this before and itâs almost as if physics handling has been nerfed on servers in general for it to perform so poorly now. What I may try is setting network ownership back to each individual driver so they handle the physics again from their client, we originally moved away from this because having the train physics handled serverside meant passengers on the trains had a smoother experience and it worked very well up until recently, where something fundamental to how the physics engine works seems to have changed.
Can confirm the trains in my games are having issues, other playerâs just stay in place for a few minutes, and teleport to the next after a few minutes. This is severely affecting gameplayâŚ
Happening in Terminal Railways, Grand Continental Railways, my current unreleased Streamlined game, but also noticed it in Ultimate Driving WestoverâŚ
Really makes these all unplayable
Yeah, Iâve also gotten into the same darn issue!
My ping is usually unstabely fluctuating, it seems as if servers are slowing down siginifically.
Is this due to the outbreak? Or this is for an other reason?
I have just published a new update and went to check how everyone is doing and i noticed there were tank threads driving around without the actual tank.
MFS X Games(Neo Warfare X, Naval 1918, Stardust, and Nebulon) are facing this same issue. The physics of things are completely janked to the point that ships teleport all over the place. To add on, there is still an issue where physics are causing major lag. This issue with physics appeared a couple updates ago and has made some aspects of Stardust unplayable due to the lag. I really hope this is resolved either with todays update or the next update, this prolonged lag is not healthy. Also would like to note, earlier playing games like Arsenal, the lag was just as bad. Probably safe to say itâs Roblox wide.