| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |

Altrue
Exploration Frontier inc Brave Collective
877
|
Posted - 2014.01.20 09:02:00 -
[1] - Quote
Hi !
So if I understood correctly, the problem with big fights is that each thing one client does, like firing, the server has to forward this information to every other client on grid. This generates an exponential load.
Now some of you were complaining about TiDi, which is of course a pain. But considering that without TiDi fights would be chaotic with nodes crashing and modules/ships being stuck, TiDi is not an option, it is something mandatory. With the recent battle of HED, everyone have realized that TiDi isn't enough.
So currently you have three 'layers' of lag : 1- Server CPU Usage. From 0 to 100% capacity. 2- Then TiDi starts kicking in. From 100 to 10% capacity. (Virtually increasing server performances by a tenfold am I correct ?) 3- True lag, with things starting to go crazy just like when TiDi didn't exist. and server reached 100% CPU usage.
What about adding a true third layer here, (server going crazy becoming the fourth layer) : The Fog of War. Now before you start crying, remember : Just like TiDi isn't something that CCP is turning off to **** you off, the fog of war isn't something I'm suggesting as a gameplay mechanic, just as a lag reduction method.
The idea is simple, since, as said at the beggining of this post, the server has to forward every client action to every other client, lets reduce this ! So, once the server reaches 10% TiDi, the Fog of War could start kicking-in, and each client would stop seeing the most far-away ships. The more load the server would have to compensate, the less ships each client would see on grid. (This would not be a distance matter, it would be a capped maximum number of ships displayed at once, starting by hiding the most far away, with the cap decreasing when needed)
Of course, exception to that would be people in Fleet Command positions that would still be able to see the battlefield as a whole. Once a target is broadcasted, should it be for reps or as a primary, this target would of course become visible to everyone.
This idea needs more design time of course, like : Who do you exclude from the fog of war ? FCs ? Scouts ? Anchor ? How do you define who is who ? How do you prevent abuses ? What kind of limitation do you put to avoid mass-broadcasting to voluntarily crash the node ? And so on...
But I believe this would be an elegant manner to ease CPU usage on the server without heavily impacting the gameplay. (Broadcasts are still working, Primaries are still working, etc) Also, during these fights a lot of people have they graphics in low, they camera as far away as possible, and their brackets off... Just like an improvised fog of war to increase client-side performances. Which would be the last benefit of my idea, this fog of war could even allow people to keep their graphics high during big fights :D I'm signature tanking !
|

Zan Shiro
Alternative Enterprises
360
|
Posted - 2014.01.20 09:15:00 -
[2] - Quote
The game already makes sniping hard to do effectively (on grid warp for example) and now you want say Rokhs at extreme range not seeing targets?
Also what happens when fc who sees all calls primary, then most of fleet is going wtf you smoking as you seem to be seeing stuff that doesn't exist.
|

Altrue
Exploration Frontier inc Brave Collective
877
|
Posted - 2014.01.20 09:18:00 -
[3] - Quote
Well as I said in my edit that came after you posted ( ), you could probably set in your client settings the fog of war to start hiding the closest ships instead of the most far away. (Or hide by standing starting with blues or reds depending if you're a logi or a dps)
Also, if I haven't been clear in my first post : Once the FC broadcasts a target, this target is temporarily excluded from the fog of war for his own fleet. Then once the broadcast expires, the broadcasted target dissapears for the members of said fleet, except if they have it locked, in which case it remains visible for those who have locked it. I'm signature tanking !
|

Kenrailae
Mind Games. Suddenly Spaceships.
133
|
Posted - 2014.01.20 09:24:00 -
[4] - Quote
Grid-FU is already problematic enough.
I'm not saying I have a better solution... I don't. But I don't think this will solve anything either. The Law is a point of View |

Altrue
Exploration Frontier inc Brave Collective
877
|
Posted - 2014.01.20 09:29:00 -
[5] - Quote
Well your FC would be spared of that anyway so it shouldn't change anything for the general course of the battle.
This is a much more elegant solution than, say, splitting grids (which would be stupid). Also remember that you can still shoot stuff that you can't see, precisely because once the FC starts broadcasting things, it appears for your fleet. At the opposite of Grid-fu where two objects at lock range of eachothers on different grids cannot target eachothers. I'm signature tanking !
|

Sigras
Conglomo
657
|
Posted - 2014.01.20 10:48:00 -
[6] - Quote
I dont think you understand how servers and processing works . . . sending data to the clients takes a negligable amount of CPU because 99.99% of that is handled by the NIC and the CPU sends it over in a single clock.
Also the clients dont get updated on everything everyone else is doing, just some of the things. What really takes up the server time is the ray tracing for range and damage calculations. Consider for every tick (in game shortest unit of time) the server needs to get the XYZ coordinates of your ship, and every ship you're targeting. Then it needs to do the 3 dimensional distance formula (which involves 3 squares and one square root) for every ship you're targeting to make sure you're still in targeting range. Then consider it needs to do this for each person on grid. Though it can de-dup for the people it has already done it for (IE if youre targeting me, the server doesnt need to do the math again if im also targeting you)
The fog of war mechanic would not help this because the server only does this for the people you're targeting anyway.
That being said, this suggestion would also cause more lag because the server would need to do a ray trace between you and every ship on grid to determine whether or not that ship was in fog of war
TL;DR servers dont work the way you think they do, this wouldnt help at all. |

Altrue
Exploration Frontier inc Brave Collective
877
|
Posted - 2014.01.20 10:55:00 -
[7] - Quote
I see where you're trying to get here, and maybe you're right.
On the other hand, the server DOES cares about ships that are not targeted because you can see their distance from yourself anyway, and it gets updated every tick too. Since I-dont-remember-which-expansion we even have a visual indication on every ship in targering range.
Maybe the visual is a client-side process but the distance displayed is certainly a server side process. So the server already does a ray trace between each ship on grid. What's right however, is that fog of war for the sake of avoiding ray trace would be pointless, because you need to do it to determine if you're visible or not. Still, I believe that there are much more informations that are at stake than just the distance between ships. Whether or not it would be relevant to not calculate them is another question. I'm signature tanking !
|

Danika Princip
Freelance Economics Astrological resources Tactical Narcotics Team
2321
|
Posted - 2014.01.20 12:44:00 -
[8] - Quote
Surely your idea would actually add MORE lag to the servers, since they now have to check that not only is that other ship on grid, but is it within X range of every other ship to see if it's visible or not? |

Dirala
Rim Collection RC Sorry We're In Your Space Eh
1
|
Posted - 2014.01.20 12:56:00 -
[9] - Quote
Altrue wrote:I see where you're trying to get here, and maybe you're right.
On the other hand, the server DOES cares about ships that are not targeted because you can see their distance from yourself anyway, and it gets updated every tick too. Since I-dont-remember-which-expansion we even have a visual indication on every ship in targering range.
Maybe the visual is a client-side process but the distance displayed is certainly a server side process. So the server already does a ray trace between each ship on grid. What's right however, is that fog of war for the sake of avoiding ray trace would be pointless, because you need to do it to determine if you're visible or not. Still, I believe that there are much more informations that are at stake than just the distance between ships. Whether or not it would be relevant to not calculate them is another question.
The Problem is not what the clients are seeing here. The Clientside Lag is because you get all the information from the server, but your computer is just not able to render/process it all.
The Problem is what the Server needs to calculate in order to process the fight. If the server sends you the information or not does not reduce server lag. The Battle needs to be calculated one way or the other.
A big step to better the servers would be to have multiple servers handle the same Node, or even better the same grid. But about the synchronization issues this would produce I will rather not start thinking. |

Lucas Kell
JSR1 AND GOLDEN GUARDIAN PRODUCTIONS SpaceMonkey's Alliance
2429
|
Posted - 2014.01.20 13:13:00 -
[10] - Quote
As Sigras said, what you are talking about would only affect network usage, which is not an issue. The problem is processing the data, not sending the data. So they need to either process more data quickly, or have less data to process. if a ship is in the system doing stuff, it need to be processed, regardless of how many people can see it.
Realistically they need to multithread the server, since they have pretty much reached the limits of what single threading can cope with. But that's a lot of work, so they may not do that until it's an absolute requirement. The Indecisive Noob - A new EVE Fan Blog for news and stuff. |

Daniel Plain
Science and Trade Institute Caldari State
1791
|
Posted - 2014.01.20 13:51:00 -
[11] - Quote
i have to agree with the gentleman above me. as tricky and difficult and dangerous as it sounds, the backend NEEDS to be rewritten/updated to scale with modern technology ASAP. not only is this the only thorough solution, it is also the only realistic alternative to manually capping the number of players in system, tidi, fog of war and other band-aids (which cause almost as much frustration as the problem itself).
i cannot claim to speak for the majority but i am pretty sure that a large portion of the community would much rather get rid of tidi and one second server ticks than get another expansion like odyssey or rubicon.
"I don't troll, I just give overly blunt responses that annoy people who are wrong but don't want to admit it. It's not my fault that people have sensitive feelings" -MXZF |

Altrue
Exploration Frontier inc Brave Collective
878
|
Posted - 2014.01.20 13:56:00 -
[12] - Quote
Okay thanks for the explainations. So I guess that as you said, sending the informations to each pilot is negligible compared to the whole simulation thing.
What about a dynamic tickrate ? Like, having the server tick four times a second when the node has the possibility to do it, and slow until something like one tick every four seconds under extreme stress ? Please note that I'm not talking about slowing the game, only the tickrate. (Which would mean 40seconds under 10% TiDi).
Signature Tanking - Best Tanking. |

Danika Princip
Freelance Economics Astrological resources Tactical Narcotics Team
2322
|
Posted - 2014.01.20 15:13:00 -
[13] - Quote
Altrue wrote:Okay thanks for the explainations. So I guess that as you said, sending the informations to each pilot is negligible compared to the whole simulation thing.
What about a dynamic tickrate ? Like, having the server tick four times a second when the node has the possibility to do it, and slow until something like one tick every four seconds under extreme stress ? Please note that I'm not talking about slowing the game, only the tickrate. (Which would mean 40seconds under 10% TiDi).
I'm pretty much certain that would represent a MASSIVE amount of extra data the servers would need to deal with. Four ticks per second is literally quadrupling the server load. How on earth would that help?
And one tick every four seconds is still a massive amount of extra load on the servers if that's your idea of heavy tidi. |

Altrue
Exploration Frontier inc Brave Collective
878
|
Posted - 2014.01.20 15:19:00 -
[14] - Quote
Of course a tickrate four times more accurate would generate more load, but if CCP were to ever code a tickrate able to slow down as a third layer of CPU charge, they could also enable it to accelerate when the server feels like it can support said load, to improve the gaming experience on less populated nodes. Signature Tanking - Best Tanking. |

Danika Princip
Freelance Economics Astrological resources Tactical Narcotics Team
2324
|
Posted - 2014.01.20 15:20:00 -
[15] - Quote
Altrue wrote:Of course a tickrate four times more accurate would generate more load, but if CCP were to ever code a tickrate able to slow down to at as a third layer of CPU charge, they could also enable it to accelerate when the server feels like it can support said load, to improve the gaming experience on less populated nodes.
Are you not literally just describing tidi though?
Well, a form of it that kicks in four times earlier than current I mean. |

Lucas Kell
JSR1 AND GOLDEN GUARDIAN PRODUCTIONS SpaceMonkey's Alliance
2430
|
Posted - 2014.01.20 16:20:00 -
[16] - Quote
Altrue wrote:Okay thanks for the explainations. So I guess that as you said, sending the informations to each pilot is negligible compared to the whole simulation thing.
What about a dynamic tickrate ? Like, having the server tick four times a second when the node has the possibility to do it, and slow until something like one tick every four seconds under extreme stress ? Please note that I'm not talking about slowing the game, only the tickrate. (Which would mean 40seconds under 10% TiDi). As Danika has pointed to above, what you are describing is essentially how tidi works. While they still operate on 12 second ticks, as in they will receive your messages as 1 second intervals, they won't process them at that rate, they will process them at a slower rate, so a single click will take longer to register.
TIDI is just taking the current timing and multiplying it to stretch the same work over a longer period of time. Whichever way you look at it, it's still a workaround solution, and as Daniel has stated, the workaround solutions are just as annoying as the issue. Currently in max TIDI, with no additional server lag, a 2 hour battle will take 20 hours. Considering EVE is not the most active game as it is, that's an insane amount of time to make people have to sit about. Oh, and 4 second ticks independent of tidi would cause some issues. Consider you firing a weapon that fires once per second, you'd not actually be able to fire just one shot then deactivate, you'd fire a minimum of 4 before the server let you stop it firing (unless ti was set to not autorepeat).
Multithreading a system as large as the EVE server will be a considerable amount of work, but it's something that will have to be done. The main selling point of EVE is big, single-shard battles, so as more people come to EVE for that, the fights will only get larger. HED-GP actually sustained less players than the 6VDT battle, even though it was on the Jita megaserver, so it's likely that not just players, but the sheer volume of drones contributed to the load, causing the server to die. We're essentially at the point now that a defending coalition could essentially fill a system up with blues and drones, and nobody would be able to get in, and that's a bad place to be. The only feasible long-term solution is for CCP to lube up and do what needs to be done. The server needs to be threaded, so it can be spanned to multiple CPUs and multiple servers where required. The Indecisive Noob - A new EVE Fan Blog for news and stuff. |

Altrue
Exploration Frontier inc Brave Collective
878
|
Posted - 2014.01.20 16:35:00 -
[17] - Quote
No no, tidi slows the game, but if you increase or decrease the tickrate without affecting the speed of the game, you get a game more or less responsive without affecting the actual gameplay speed. Signature Tanking - Best Tanking. |

Sigras
Conglomo
661
|
Posted - 2014.01.22 18:47:00 -
[18] - Quote
That would allow for strange stuff to happen all the time:
Ships that are actually dead would still be doing damage until the next tick Ships could be destroyed after they warp/cyno out. Your MWD would stay on after being hit with a scramble until the next tick.
This is not better than what we have now with actual lag. |
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |