I’m reasonably certain they’ll get around to it. One of the reasons RO was so enduring was that people loved to WOE and MVP. They didn’t have to tolerate 6-10 frames per second even on their ancient neanderthal rock and wheel computers.
We won’t put up with it forever, either. It’s something we endure on the understanding that it’ll be fixed. So they’ll either get around to it or lose the enduring appeal of field bosses and guild battles.
It will probably be good to create a new thread maybe in the bug reports section documenting the tests done here.
There are a few more questions that I’m curious about personally, once we collect at least some data for the questions below we can probably send off a bug report, because it’s probably due to some unexpected network properties of the iToS servers that the kToS servers don’t have…:
- What is the function that governs the FPS decrease as the number of players nearby increases? Is it linear (i.e. each additional player nearby incurs a 1 FPS drop)? or maybe some other relationship?
- If a lot of players are spamming normal chat in the same channel, but are out of view, do you still get FPS decreases?
- If you have a lot of players nearby AND they are all spamming normal chat at the same time do the FPS decreases combine and get even worse?
- Do player skills being activated nearby (either in visible range or outside of visible range) effect FPS?
- Does actual player geographic distance affect framerates? Is having a bunch of SEA players nearby worse for an American player’s FPS than having a bunch of other American players?
So far I’ve taken @chronosanct’s summary of this thread and translated it word-by-word to the developers, as I’m not too keen on computer technology.
I’ll be coming back to this thread so please make your updates here if the experiments are still on-going, so I can find them quickly.
Thank you.
Wonderful! Thank you!
Oh! Thanks much for listening!
You should take a look here as well: Micro-stuttering / Game catches up when you stop moving
It’s a very similar issue, might be caused by the same thing, and has videos to show it off.
Yup, that particular thread I already bookmarked. I also have animation freezing, companion’s Coursing animation discrepancy, and skills having to be used more than once to actually work.
If there’s something else I missed please let me know, thank you. 
Here is a better summary of the situation that I would send instead of the spaghetti thoughts I’ve had so far in the thread:
I would specifically tell them to look at code relating to their TCP protocol because I suspect it’s somehow causing the overall game process to idle and consume fewer CPU (and probably GPU) resources (perhaps because it is blocked and waiting for repeatedly lost packets).
Our initial tests showed that the ToS client .exe does not appear to be CPU limited because only 2 out of 4 active cores of an Intel i5-4460 is enough to achieve 60 FPS when there are not a lot of other players around. The ToS client .exe is likely not GPU limited either because as shown in the opening post, even when there are a lot of players, the GPU does not appear to be very active. Furthermore, even when using an Intel HD Graphics 530 card, a player can achieve 40 FPS in a city map when no other players or NPCs are around.
The biggest giveaway is that restricting the Client_tos.exe to only 1 core reduces FPS by 25 when there are few players around, but restricting Client_tos.exe to only 1 core reduces FPS by only 5 when there are a lot of players around. This suggests that something about having a lot of players around causes less draw calls (resulting in lower FPS).
EDIT: Special thanks go to @ridleyco, @Maavy, @sksben for collecting much of the data and the useful back and forth.
Thanks also to @nizidr for prodding me into taking a deeper look at the whether the ToS client was truly multi-threaded or not. Turns out it is multi-threaded, but turns out the performance hits might have nothing to do with CPU or GPU.
I guess this proves that IMC has some pretty bad programmers.
On top of the FPS rate, their network programming is also pretty bad. If you lag, your character would glitch to attack twice or freeze in animation. It’s too server side heavy in terms of processing data.
And now this post here proves that their engine is also badly designed. Inefficient and not optimized.
i think the problem is that one core just cant do 1080p even a i7 , i dropped my res to 1600x 900 and the fps is alot better :S , the solution is getting a 720p monitor xD.
They were in iCBT2.
40+ players Dullahan was hell. (Yep, 2fps, you named it.)
I too had the feeling (even in “empty” field) that drooping packets were harming TOO MUCH my performance. (Things like attack/skills not triggering, or with seconds delay.) This only happened on “bad” (=unlucky) days.
I remember this one boss monster attack in iCBT2 that really killed the framerate when it was used. They seem to have removed it from the game now. This bullet hell thing.
Now with the eyes on Lag through TCP stuff it might make sense because every bullet probably had to be synced and wait for a response and thuse immediately cause huge lags > low framerates.
Allthough, in field boss fights when there’s a lot going on and now we think the low framerates are not caused by gpu/cpu but TCP waiting.
I remember occasionally having graphical glitches when there are a lot of spells on screen.
This is also a screen from iCBT 2, but i’ve already had this happen recently in fights, just didn’t capture it anymore.
Notice especially those blocky sprites popping up near my reflect shield. I Think the flames over the screen were also wrong.
People who have been in big field boss fights may know this flickering issue.
So that clearly has to be a GPU issue, no? (I’m using an i7-4790k @ 4.00 GHz & Geforce GTX 980)
So about tcp stuff if i understand well a customer with low ping have a best framerate than the one with average ping but the game is hosted in NA actualy isn’t he ?
So we can say when they will merge server in eu our framerates will up more or less ? did i understand or i’m totaly wrong
There might be something up with the UI in general as well. Chat bubbles (especially from megaphones) cause FPS dips (PLEASE PLEASE PLEASE tell the Dev team we want an option to completely turn off global chat), and I just took a video to show the freezes that happen when you have to pick up a lot of objects:
http://puu.sh/ogBbj/c5c1c56533.avi
I guess it could just be the network code, too, but without fail whenever something new has to appear on screen, like a notification you just looted something, the game decides to freeze.
I’ve read somewhere in reddit from a user with wireshark, that the main issue seems to be positioning other players. Basically it was stated that other player’s movement need to be synced which resulted in a LOT of packets. Considering the boss that had bullet hell, this would perfectly explain what the problem was.
Concerning global chat spam lag, you could fix it just by adding a firewall rule that prevented the TOS client from even receiving those messages, and by not having to process them in the client the FPS was higher and smoother (you could do this with windows firewall for example).
This also explains a bit about the world, ToS has instances because this network model doesn’t scale, so you can’t have huge maps with everyone in it sendind position packets of everything to everyone. Another possible fix would be to not receive data concerning users/enemies who aren’t close to your viewport. So basically if theres a player on the other side of the map, you don’t need to see him or acknowledge where he is/what he is doing. Im not sure how the game works, but I assume that you receive data from every player on the map. This could easily be tested, just go to a crowded map and stand in an edge far away from everyone else. If you still have big Lag spikesm then the issue is confirmed. On my experience in cities, it seems to be the case since even standing at the edge of the city I still see Lag quite often.
TOS is a server-side centric, and considering how sparse the player population is at the moment it certainly explains a lot of issues. So one quick solution would be to have more servers closer to the playerbase. So one server that is actually in Europe, another in South America, another in USA West Coast and maybe some others places as well…
But the real solution seems to be optimizations on how player position/action is syncronized.
@Nyyppa: You’re correct. Every client-sided information is a possible path for cheating, although that’s how mob collision works right now (your client tells the server “I hit the X mob with Y skill” and the server calculates the damage.
@chronosanct: A “hand-implemented” packet confirmation for UDP pretty much makes it become one of the various other protocols mentioned in that paper, according to implementation. Most of them are based on UDP (as all network traffic supported by our infrastructure is either TCP or UDP nowadays).
(Also, the HD Graphics 530 can deliver over 50fps on Bioshock Infinite @1080p on High settings; it’s a pretty solid GPU)
For documentation, my testing was done from Brazil, with a ping of about 230ms.
@Staff_Julie: Thanks for listening! Good to know that our voice is being heard. I hope to see fruits from this!
@miguelc0611: I don’t think that the issue is server-sided. They use AWS, the server should be set up with more than enough processing power for any MMORPG.
@Minto: Care to provide some numbers? Our testing didn’t involve multiple resolutions, but we pretty much showed that processing power isn’t the issue with the FPS drops. Maybe reducing the resolution also reduces your field of vision (which is a bad move), decreasing the number of player objects? I’m not online to test this myself right now.
@herbafina: Yes. Ping should directly affect framerate, as you’ll spend less time waiting for TCP confirmation… assuming the server isn’t taking long to deliver this confirmation due to a high CPU load on the server.
You don’t get input from players directly out of your viewport; they don’t even have to be close. That’s why sometimes player models take a while to load right when they come in your screen.
Party members are an exception. You get a part of their movement packets to update map position.
I dunno if you guys also go on reddit, but they have a similar thread related to performance that covers a lot of similar bases (but also includes some potential fixes)
Based on what I’ve read, the problem isn’t just that the game’s networking is only in TCP. The bigger issues seems to be that all of the networking is done on the game’s main thread and networking is done using TCP. Meaning your computer is waiting on packets to draw frames. Meaning high packet loss = a significant drop in FPS.
Are you sure? Because if this is true then going to an empty place in Klaipedia should allow you to retain your max FPS, and I have the feeling I have lower FPS in cities no matter where I am, even if no other players is rendered in my viewport. I will test this later.
