Many players of Isle have been reporting issues regarding extremely high ping (in the thousands). This is making the game completely unplayable and causing the player count to dwindle rapidly.
After further investigation It has been discovered that the bug has to do entirely with FPS.
Setting FPS cap to 30:
Setting it back to 60+:
This is also not platform dependent, console players have reported the same issue.
This issue only started occurring as recently as a week or two ago. There is a survey as a testimony to this:
No scripts have been changed for over a few months.
As soon as you’re in the ship cutscene, or anywhere in the game run the FPS unlocker and cap your FPS to 30.
You’ll immediately notice your ping will start gradually increasing by 100-200 every second.
Setting your FPS back to 60 or uncapping it will rectify your ping almost immediately.
I want to clarify that you do NOT need to use the FPS unlocker, users who don’t and have low FPS are still impacted by this. I only included the FPS unlocker because It’s an easy way to reproduce the bug.
The script that I’ve isolated for “Isle” is one that is used to drive a snake model and attaches its individual segments to the ground in a sort of procedural animation method. Due to its large size and long body, it is impossible to use an animator, since it is also traversing through rough, mountainous terrain. The script fires every .Stepped cycle, and calls :SetPrimaryPartCFrame() to move the model. The part count is around 250. The place “CFrameTest” mimics the behavior of the script.
I am aware that optimizations are possible, such as unioning, meshparts, and lowering the function call frequency. However, I would like to know how low FPS could lead to an increase in ping without limit, and how it could have led to a recent (since June 30th) increase in lag reports for the game?
Personally, this happens to me in every game, it’s why I don’t believe the classic bandwagon of “ping doesn’t correlate with fps.” I had a pretty bad CPU at the time, so serving frames to my GPU, running game logic, and responding and parsing HTTP requests is a big deal.
I’m not sure if this is an engine bug, but yeah, when you get low fps in any game for that matter, your ping can skyrocket to 1k ms (1 second delay for everything you do!!)
Not sure if system specs are required here, my old computer was around 200 dollars, so that can help with the magnitude of things (extremely entry-level pc)
Especially when you artifically cap your FPS, you can see it happen.
Also another thing, I had Ethernet back on my old computer, so I can confirm this happens regardless of Wireless or Ethernet connections, drivers were also up to date.
Don’t use SetPrimaryPartCFrame to move models around like that, that way you are sending 250 individual CFrame updates per frame or roughly 15000 CFrame updates per second to the clients!
Unlike with physics the server will not try to throttle the CFrame updates you are sending and once you surpass the amount of data the server can send or the client can recieve per given timeframe all those updates you are sending will start queueing up on the server.
The ever increasing queue in turn results in an ever increasing ping as you increase the size of it every frame.
A simple solution for now would be to weld all parts in the model to the primary part using Motor6Ds, unanchor all parts except for the primarypart and only change the CFrame of the primary part of the anchored primarypart.
This should massively reduce the amount of data you are sending as the server will treat the model as a single assembly and only send a single CFrame update instead of one for every single part in the model and as a result fix your problem.
Even then, you should really rethink your approach to animations as updating CFrames on the server will result in choppy movements as this isn’t the intended method to animate objects.
I have converted the model to operate in the Motor6D logic as described above. The head is CFramed once, while the remaining 10 segments have their Motor C0 calculated and applied. This resulted in a slight performance increase. There was still issues with the ping buildup at 30 FPS. I reduced the function call rate to perform after each wait(). Overall, the CFrame update per frame was reduced by more than half. The solution seemed to have worked, although ping still builds up for an FPS less than a certain threshold, it is much lower than 30 FPS, so I guess the solution sort of worked.
I assume that reducing part count via MeshPart or Unions would be the best next step.
I’m still not sure as to why this problem popped up recently. I have not published that particular place since mid February. Lag reports were far and few in between the months, but had increased dramatically since June 30th. Lots of the players weren’t able to play, and the developer metrics showed a sharp decline in visits since then.
Despite it not being on the roadmap, I would consider something like this to be quite a priority, especially considering the massive playercount of competitive games like Phantom Forces, Counter Blox, Ragdoll Mayhem etc.
I’ve noticed for my own games, such as No-Scope Sniping or Pistol 1v1, low-end users will experience a framerate of about 25-45 FPS, resulting in ping being in the triple or quadruple digits. Such ping makes the user experience really unpolished and nonreactive, appearing as if it is of fault of myself or the developers not optimizing the universe correctly.
A fix like this would definitely increase average user play time and like ratio, which would benefit both the developers and Roblox staff.
I hope to see this fixed soon. I would prefer for my users to have a positive experience, not a laggy one.
