Holy ■■■■ this is getting interesting.
I’m going to do some affinity tests in cities and in the field, too! After that I’ll update my OP with the hard work you guys are doing.
UDP for actions is a no-no. It causes serious syncing issues when a packet is lost, and the server won’t account for it. Unless basically everything gets moved to server-side and the client takes care of less stuff, but then the game would be unplayable with anything over 100ms ping.
And the messages are ordered by your client in ToS, according to a timestamp in the packet. This becomes obvious when you get a message with a glitched timestamp that always stays on bottom, because your client thinks it’s the latest message; happens quite often on /y chat.
Fair enough, but I think the strategy proposed by the paper I linked empirically seems to be the most efficient:
M Strategy: M combines all three options, that is, multi-streaming, optional ordering, and optional reliability. Under this strategy, there are three kinds of streams: ordered and reliable streams, unordered and reliable streams, and unordered and unreliable streams. Messages that must not be lost and must be processed in order must be transmitted via ordered and reliable streams. On the other hand, if messages can be lost without affecting the correctness of the game play, it is better to put them in unordered and unreliable streams. For messages that require reliable transfer without strict order maintenance, unordered but reliable streams should be used.
Specifically:
PM employs the M strategy, which transmits move messages via an unordered and unreliable stream (UDP), attack/action messages via an unordered and reliable stream (SCTP), and talk messages via an ordered and reliable stream (TCP).
The results of various netcode implementation on mean delays:
Results of the netcode implementations on mean jitter:
When you have skillshots, movement has to be reliable too (that is, if collision is processed server-side as it is right now; if they change collision to be detected client-side it would be totally fine not to confirm packet loss for movement).
And UDP is an example of “unordered and unreliable stream”. They could use one of the other protocols mentioned in this paper. Not UDP.
Yeah I pretty much think that your FPS is some proportional relationship to the number of players around you and maybe also a function of the number of messages occurring as well…
So I would test FPS when there are 5, 10, 15, 20, 25, 30 other players are around.
I would also want to test what the FPS looks like if those people are all sending messages continuously.
Assuming you guys are on to the hidden truth, and that these FPS drops aren’t related to rendering models at all, well - isn’t this bit of networking wizardry something that all the other mmos have figured out?
How does WoW do it, or FFXIV? I’ve been to Odin fates with 100+ people crammed into a thirty yard radius and not had problems like this.
Here’s another tidbit you guys might want to try, and something I found really interesting. It also supports your hypothesis somewhat: I had my total player models displayed capped at 10 in that screenshot. This change is applied in the user.xml file located in the TreeOfSavior/release folder, by modifying the number of:
DrawActorPersent=“x”
Whereas x is the desired number of player models displayed at one time.
This is damning evidence, now that I think about it, that you guys are correct in your assessment that the fps hitch has nothing to do with graphical display at all.
Simple - using protocols that don’t lock your thread (like TCP), and, if you do, use a different thread for netcode (which can cause characters teleporting and such in case of extreme lag or packet loss, but it’s certainly better than your whole game’s framerate dropping)
They can’t change that without extra vulnerability for hacking/cheating in game, right? That’s why all the new mmos tend to be server-sided on these things afaik.
Based on what I’ve read you can get reliable UDP and many game programmers have regretted using TCP due to how it implements “reliability”
http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
I’d say around 20 on screen not including the npcs, and a few players moving on and off my screen. Yes when I moved to the area to the right just above the stairs, no npc or player could be seen on screen.
1 Like
This post was flagged by the community and is temporarily hidden.
You know I thought about things a bit more and this is what I concluded…
As a game developer in Korea, catering to a playerbase that has an extremely fast and (more) reliable internet and who is not distributed geographically over large distances, you probably don’t think too often about events like packets dropping or routing gone horribly horribly wrong…
But when you start talking about European users trying to connect to the US, or South American users trying to connect to the US, or SEA users trying to connect to the US, or even US users trying to connect to the US, I think then you start realizing that packet delivery failure is going to happen A LOT…
And so the TCP implementation they used probably worked decently in Korea, but because TCP really doesn’t deal with dropped packets so well or network issues or high user loads so well, this is probably resulting in the terrible performance for iToS…
But the best suggestion I think we as players can make is that imc need to take a really hard look at their network protocol. Either a massive rework or a redesign is probably needed if we ever want good FPS in boss fights, guild battles, or town interactions…
I can’t even believe how poorly optimized this game is. It’s nearly unplayable.
I would say this is pretty convincing evidence to me that the FPS issue is player and/or likely network related…
It also shows that a Intel HD Graphics 530 can get 40 FPS in ToS which is quite remarkable given that it’s a fricken Intel integrated HD Graphics!
EDIT: And the issue is not related to rendering of many players because as @ridleyco showed in his opening post GPU is hardly being used even when there are a fair number of other players and pets on the screen.
Basically what we’re finding is that the FPS drops don’t seem to be related much to CPU or GPU. They seem to be related to netcode issues…
So doesn’t matter what your system is like, everyone will be effected quite hard by this regardless of the CPU or graphics card or ram that they have.
1 Like
This post was flagged by the community and is temporarily hidden.
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.
3 Likes
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.
18 Likes
Wonderful! Thank you!
1 Like