Pages: [1] 2 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 16:27:00 -
[1]
OK, so posting here is never fun, every word is contentious, every idea ignites zealous cries of hate and slanderous persecution... never the less, every couple years I just have to throw in my 2-cents worth, so for better or worse, here it goes.
So everyone knows fleet battles are the catÆs meow in EVE... now if we could just get this whole lag/node crashing/server choking issue under control the folks at CCP could finally slay this demon and move on to something more productive... perhaps EVE II *hint hint*
Well, so how do we fix it?
We all know CCP isnÆt going to budge on the æfleet instanceÆ idea. They are proud of the technology that keeps the game world un-instanced and contiguous. I agree with them, itÆs quite a feat to make a gaming world that can hold 60,000 people all in one great big happy universe.
So, in a world of compromises, here is what I suggest to fix the lag in this amazing world called EVE.
Fleets:
When a fleet is formed, the game engine will automatically change ship graphics into a shadow mode. In this new fleet graphic, a ship will no longer tax the server resources/client resources to implement all the fancy bells and whistles that make EVE graphically stunning.
IÆll leave it to the designers to decide how they could graphically represent a ship while in fleet mode û it could be an outline of a ship, it could be a graphical symbol, or ship code (ie. Like those used by traffic controllers at an airport control tower).
I can hear the people out there crying foul now, the ones that FRAPS and love the graphical snapshots of those gigantic fleet battles... read on.
Record the Battle:
Part of the idea here is to allow those 1000+ ship conflicts to flow smoothly, and give all the pilots involved a smooth experience. So in this regard, the fleet battles will become lag-free but no one is going to want to watch a battle of symbols and fleet codes marching across their screen when they play the encounter back on YouTube.
So, in conjunction with the new fleet shadow mode, the game will allow a designated member(s) from each fleet to act as a recorder of the events of the battle. While the designated fleet recorderÆs EVE client chugs on all the fleets movements, a new data file will be created which can be played back later within the EVE client at full graphical settings with FRAPS running behind the scene collecting the battle in all its lag-free glorious detail.
So to summarize the ideas here:
1)û Shadow Fleet: a symbolized, or graphically simplistic view of ships, structures, ordnance, drones/fighters, etc.
2)û Record of Conflict: an actual data file of every ship/structure and their actions within the conflict which can be played back later within the EVE client allowing for a full FRAPS in all its graphical glory.
Yes this is a compromise, but the goal is to have lag-free fleet battles within the current EVE technology.
*deposits her 2-cents into the EVE Forums*
Aurora
|
Joe SMASH
You Got A Purty Mouth
|
Posted - 2010.07.28 16:33:00 -
[2]
If you think the reason fleet battles lag is because of visuals you are completely ignorant. All graphical rendering is done on client side, not server side. Server is where the lag happens. Lag is a result of the node's database being hammered too hard because of poor coding and db structure. Something in Dominion exasperated the issue and made it completely broken.
Recording the battle would be one more thing to cause lag. So no. -----------------------------------
Originally by: Kali Zero Warp core stabilizers are like condoms. Nice and safe, but they make it a little less fun for everyone involved.
|
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 16:56:00 -
[3]
hehe... so it begins.
The experts have arrived.
Well I'm not an expert on databases, or faulty game code so I won't pretend to be able to help CCP in that matter.
However, from my own experiences within the game, and the lag I've seen associated within fleet conflicts, or maneuvers I can only imagine this:
The server has a terrible time dealing with player's connection to the game when said player's computer locks-up/freezes due to graphical overload...
...compound that issue several orders of magnitude when a fleet arrives on the scene and likelihood that 85% of the participating player's have computers that start choking due to cpu/gpu/memory/internet limitations.
Now I could be completely wrong... maybe the EVE server takes over for a player's ship and all subsequent actions when a player's computer is no longer synchronized to the game server. Maybe the game server elegantly handles all the network trash and un-synchronized communications between client and server.
I don't suggest that my idea will fix any underlying issues with the game-code, or the game's database - if such issues do indeed exist.
After all, I only gave 2-cents worth.
Aurora
|
Tarasina
|
Posted - 2010.07.28 17:15:00 -
[4]
Edited by: Tarasina on 28/07/2010 17:15:34 How do you explain the fact that 1000 vs 1000 battles could be had with no such issues as you currently suggest?
Has nothing to do with graphics or clients performance.
|
Simply Human
|
Posted - 2010.07.28 17:23:00 -
[5]
Edited by: Simply Human on 28/07/2010 17:23:26
Originally by: Aurora Aujii ... The server has a terrible time dealing with player's connection to the game when said player's computer locks-up/freezes due to graphical overload...
...compound that issue several orders of magnitude when a fleet arrives on the scene and likelihood that 85% of the participating player's have computers that start choking due to cpu/gpu/memory/internet limitations. ...
When your client locks up, the server doesn't care. |
Namira Sable
Minmatar Pator Tech School
|
Posted - 2010.07.28 17:24:00 -
[6]
Originally by: Tarasina Edited by: Tarasina on 28/07/2010 17:15:34 How do you explain the fact that 1000 vs 1000 battles could be had with no such issues as you currently suggest?
Has nothing to do with graphics or clients performance.
May I ask which 2000 man battles you are referencing?
|
Dzajic
Gallente
|
Posted - 2010.07.28 17:38:00 -
[7]
Client lag even on slow machines when loading graphics and textures is tiny, and simulation processing is running on server and you are just updated. Only thing sever tells the client is that you have such and such ship, going at such and such speed in such and such direction. Those are necessary for simulation. Also you must know your HP so server tells you when you are damaged (and by whom) so the client then renders turrets firing and hitting your ship.
There is no excessive information being sent on client server chain due to graphics engine. Even turning off all graphics would only improve your FPS, client server loop latency and breakups and timeouts would remain the same. (And oh yeah, brackets kill FPS because no one has bothered to implement even most basic vector/2D graphics on GPU acceleration for more than 15 year now.)
Polished content =/= broken and unbalanced content. |
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 17:43:00 -
[8]
... I know we're all experts at something.
Dev Blog - CCP Blaze
Once again, its just 2-Cents worth.
Aurora
|
Alizandro Goderaski
Minmatar Tanasinn. HYDRA RELOADED
|
Posted - 2010.07.28 17:48:00 -
[9]
Aurora, don't post about large fleet battles if you've never been in one yourself.
|
Joe SMASH
You Got A Purty Mouth
|
Posted - 2010.07.28 17:50:00 -
[10]
Originally by: Aurora Aujii ... I know we're all experts at something.
Dev Blog - CCP Blaze
Once again, its just 2-Cents worth.
Aurora
That dev blog is about performance boosts to the client, not the server. You seem to have a hard time distinguishing the two.
Keep your two cents and buy an informed opinion imo. -----------------------------------
Originally by: Kali Zero Warp core stabilizers are like condoms. Nice and safe, but they make it a little less fun for everyone involved.
|
|
Darriele
Minmatar THE MuPPeT FaCTOrY
|
Posted - 2010.07.28 17:54:00 -
[11]
It's not worthy to speculate on how things should be done because we do not know how the things are done in the first place. As in we do not know how eve client/server engines were designed. Inappropriate signature removed.Applebabe |
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 18:20:00 -
[12]
Originally by: Darriele It's not worthy to speculate on how things should be done because we do not know how the things are done in the first place. As in we do not know how eve client/server engines were designed.
I agree Darriele.
hehe
It's always fun to read the replies to ideas/suggestions on this forum.
People thrive on tearing down an idea, just for the sake of...
...well actually I have no idea why they do it.
I'm more interested in the folks that play this game who have similar ideas, or thoughts about possible solutions.
As for all those 'so called experts'... yes, yes, yes... you're right, and I'm wrong. Thank you for pointing that out.
To those who'd like to see some progress on a solution, lets put up some constructive ideas... maybe, just maybe one of the CCP folk will catch wind of an idea from this that will give them an idea for a solution.
Sometimes all it takes is 2-cents.
Aurora
|
Pennwisedom
Gallente Sublime.
|
Posted - 2010.07.28 18:31:00 -
[13]
It really isn't that fun to read a suggestion that isn't based in any sort of reality. It's much more fun to not talk about things you don't know anything about.
|
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 18:44:00 -
[14]
Originally by: Pennwisedom It really isn't that fun to read a suggestion that isn't based in any sort of reality. It's much more fun to not talk about things you don't know anything about.
LOL
Now that is funny Pennwisedom.
If what you say were true, then we'd have to disregard about 98% of the posts in this forum wouldn't we?
LOL
Aurora
|
Darriele
Minmatar THE MuPPeT FaCTOrY
|
Posted - 2010.07.28 18:44:00 -
[15]
Originally by: Aurora Aujii
Originally by: Darriele It's not worthy to speculate on how things should be done because we do not know how the things are done in the first place. As in we do not know how eve client/server engines were designed.
I agree Darriele.
hehe
It's always fun to read the replies to ideas/suggestions on this forum.
People thrive on tearing down an idea, just for the sake of...
...well actually I have no idea why they do it.
I'm more interested in the folks that play this game who have similar ideas, or thoughts about possible solutions.
As for all those 'so called experts'... yes, yes, yes... you're right, and I'm wrong. Thank you for pointing that out.
To those who'd like to see some progress on a solution, lets put up some constructive ideas... maybe, just maybe one of the CCP folk will catch wind of an idea from this that will give them an idea for a solution.
Sometimes all it takes is 2-cents.
Aurora
Probably you do not have anything else good to do if you started a new thread just for fun :) Inappropriate signature removed.Applebabe |
Witcher
Amarr Russian Specialists Group
|
Posted - 2010.07.28 18:50:00 -
[16]
excellent idea
*A-L-L* *I-N* *F-A-V-O-U-R*
just to add a point - the decision to change graphical mode could be up to fleet boss and once boss decides to do so, it will force client of every fleet member to display simplified graphics as well, so to ensure that none of fleet members lags
|
Yuki Kulotsuki
|
Posted - 2010.07.28 19:06:00 -
[17]
This would be more interesting if it actually solved a real problem. The main lag issue is not client side but server side. Graphical lag is client side. There would be no reduction in information conveyed to the client with your shadow fleet idea. CCPs thin client that they are working on doesn't involve changes to the server code.
I'm sure plenty of people would like both aspects of this idea. Many people joke about wanting an ASCII or command line client but the truth is sometimes people do want just info, no eye candy especially if graphic lag is an issue. Being able to record the information a client receives so that it can have a top graphical settings playback is also a feature many want. That's essentially the idea behind the fleet fight recorder idea.
Essentially there's nothing new here. You're trying to apply two old and well liked ideas to a problem they don't solve. Better luck next time. See you in F&I.
Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
|
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 20:26:00 -
[18]
Originally by: Witcher excellent idea
*A-L-L* *I-N* *F-A-V-O-U-R*
just to add a point - the decision to change graphical mode could be up to fleet boss and once boss decides to do so, it will force client of every fleet member to display simplified graphics as well, so to ensure that none of fleet members lags
Thanks Witcher.
I like that idea to give the fleet boss more control over the environment.
Aurora
|
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 20:37:00 -
[19]
Originally by: Yuki Kulotsuki This would be more interesting if it actually solved a real problem. The main lag issue is not client side but server side. Graphical lag is client side....
So its not an issue when one of your fleet members d/c's because their computer either chokes on the cpu/gpu/memory/Internet limitations or bottlenecks they might be experiencing?
Originally by: Yuki Kulotsuki ...Being able to record the information a client receives so that it can have a top graphical settings playback is also a feature many want. That's essentially the idea behind the fleet fight recorder idea.
*nods*
I only mentioned as an afterthought, since I know how much the EVE Alliances enjoy posting FRAPS to YouTube. And given the idea of a simplistic graphical environment, playing the fleet battle back later at full graphics seetings only seemed reasonable.
Originally by: Yuki Kulotsuki Essentially there's nothing new here. You're trying to apply two old and well liked ideas to a problem they don't solve. Better luck next time. See you in F&I.
Oh well. I'll admit I'm not the most avid EVE player, nor do I get caught up in all the EVE zealotry regarding the game mechanics. My suggestion was just an idea to help cut down on some of the 'end-user experienced' game lag.
Once again, I'm not going to try to imply that I could do it better than the Devs.
Personally I think they've made a game with tons and tons of untapped potential.
Thanks for being constructive... now if we could just find a solution everyone could agree upon - even the Devs
Aurora
|
Breaker77
Gallente Reclamation Industries
|
Posted - 2010.07.28 20:45:00 -
[20]
Originally by: Aurora Aujii
So its not an issue when one of your fleet members d/c's because their computer either chokes on the cpu/gpu/memory/Internet limitations or bottlenecks they might be experiencing?
Thats why you should always be above the minimum requirements of any game, be it EVE or something else.
|
|
El Liptonez
|
Posted - 2010.07.28 20:55:00 -
[21]
Originally by: Breaker77
Originally by: Aurora Aujii
So its not an issue when one of your fleet members d/c's because their computer either chokes on the cpu/gpu/memory/Internet limitations or bottlenecks they might be experiencing?
Thats why you should always be above the minimum requirements of any game, be it EVE or something else.
I haven't heard anyone crying on the forums or ingame about it. Not a single one. Everybody accepts that his computer is **** when it slows down to two fps, when brackets and all effects are turned off.
Just so you know, I frapsed the fight in C-J6 yesterday (or the day before?). With "effects" off, but turret, missile and explosion effects on. Worked fine, constant, let's say, 15 fps. I turned brackets on, after a freezing client for 10 seconds I finally was able to view a 5 fps spectacular agglomeration of colorful squares. I don't know how laying a few squares over the ships I see anyway would slow my client down.
But that is not the issue everyone complains about. Why would the server show any interest in how slow or fast the game works for someone?
Fact is, the server simply does not respond to what you want him to do. You can have 1000 players duking it out on high-end machines, it will still lag horribadly. But from your first-hand experience, I guess you know it better anyway.
|
Cat Casidy
|
Posted - 2010.07.28 20:58:00 -
[22]
Edited by: Cat Casidy on 28/07/2010 20:58:59
Originally by: Aurora Aujii
When a fleet is formed, the game engine will automatically change ship graphics into a shadow mode. In this new fleet graphic, a ship will no longer tax the server resources/client resources to implement all the fancy bells and whistles that make EVE graphically stunning.
Aurora *deposits her 2-cents into the EVE Forums*
That can and is done pretty consistently client side, its not why theres lag
My two cents..... you owe me a nickel now btw |
Breaker77
Gallente Reclamation Industries
|
Posted - 2010.07.28 21:00:00 -
[23]
Originally by: El Liptonez
Fact is, the server simply does not respond to what you want him to do. You can have 1000 players duking it out on high-end machines, it will still lag horribadly. But from your first-hand experience, I guess you know it better anyway.
I know that, you know that, and many others know that. Aurora Aujii is the one that doesn't know that!
|
David Grogan
Gallente
|
Posted - 2010.07.28 21:07:00 -
[24]
part of the apileocrapia expansion that we all saw was lag reduction.........this coincided with the minimum gcard specs and single client type. so there was an element of client side lag due to ancient hardware before apileocrapia expansion was released.
sov mechanics changed in dominion which introduced lag again cos fleet fights concentrated around structures that too half the day to kill. also more people moved to 0.0 thus putting more load on normally unboosted nodes. thus server side lag
now the planets got shinied up for PI this lag puts some of the lower end gcards under stress when fleet fighters occur near planets. thus client side lag.
from what i can see 0.0 nodes (all of them) need to have the number of systems supported on them reduced with a few extra on standby for to dynamically boost nodes when fleet traffic is moving along a route. when the two fleets meet in a system the two tracking booster nodes used during each fleet's movement are used to support the node where the fight takes place. SIG: if my message has spelling errors its cos i fail at typing properly :P |
Yuki Kulotsuki
|
Posted - 2010.07.28 21:30:00 -
[25]
Edited by: Yuki Kulotsuki on 28/07/2010 21:30:17
Originally by: David Grogan stuff
Unfortunately there's no way with the current architecture to dynamically boost nodes. The allocation of resources is done during downtimes (which is why fleet fight notifications are needed the day before a battle). Once allocated those resources are locked in for the full 23 hours. The reason they can't be moved on the fly has something to do with an inability to seamlessly transition a system's resources, state and relation to the DB from one computer to another. It might be doable if they paused everything in a system and did a transfer but I don't think people would want that.
An alternative that has been suggested several times is running systems on VMs and dynamically allocating resources to the VMs that need it most. CCP has stated that they need as much performance as they can get from their hardware and don't want to slow things down to accommodate the overhead of running a hypervisor. And of course the reason they need as much performance as possible from their hardware is because the process that runs a single system cannot be multithreaded (something to do with stackless Python's global interpreter lock I think) and doesn't benefit from multicore/multiprocessor systems. Considering that eve was designed back when intel was promising 10GHz processors by 2011 that's not so unreasonable.
Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
|
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 21:58:00 -
[26]
Of course, I realize everyone here is right, and that I am wrong. I know this because they're the experts, and I am not.
Nevertheless, I'd be interested in having one of these experts explain the synergistic real-time server node response to a lagged, out of sync client, which is continually sending/receiving bad bytes of information (out of sync) and how this relationship directly corresponds to the game environment on the screen?
Explain this relationship with regard to a 20 vs 20 ship fight...
Explain how this effects a battle of 500 vs 500 ships...
Please tell us, how does a well managed game server handles 1000 vs 1000 ship battle when say up to 80% of the players in the conflict are out of sync or completely locked up.
Oh I know how easy it is to derail an idea, to tear down a persons' credibility, to arbitrarily comment without actually contributing an ounce of input or intellect.
Yes, in my experience, my computer has lagged out when I warped in on a fleet battle. Not the server, but rather, my computer.
(For those of you about to say, but Aurora, you've never been in a fleet battle - you are correct, the character Aurora Aujii has never been in a major fleet battle. But the player, that's me, has controlled characters which have participated/recorded and witnessed fleet battles..... So don't even go there).
With all these experts, you'd think someone would step up and give us the low-down on this issue and the fix needed.
For my part, I'm just re-hashing some old ideas.
Aurora
|
Suboran
Gallente Di-Tron Heavy Industries Atlas Alliance
|
Posted - 2010.07.28 22:08:00 -
[27]
any modern graphics card can handle the eve visuals unless its a really low end one designed for an office or media centre.
the problem is ccps lazyness to drive forward new technology to combat lag.
infiniband anyone?
|
Admiral Pelleon
White Shadow Imperium Reckoning.
|
Posted - 2010.07.28 22:42:00 -
[28]
LOL at graphical lag causing server lag. Absolutely adorable.
The client doesn't do anything more than splash **** on your screen and act as a dumb terminal to the actual server. ________ Chicago players channel: 'Windy City'
Originally by: CCP Navigator Confirming that I am the best poster.
|
Yuki Kulotsuki
|
Posted - 2010.07.28 23:26:00 -
[29]
Originally by: Aurora Aujii Nevertheless, I'd be interested in having one of these experts explain the synergistic real-time server node response to a lagged, out of sync client, which is continually sending/receiving bad bytes of information (out of sync) and how this relationship directly corresponds to the game environment on the screen?
Consider for a moment what information is stored where. The server is the final arbiter. It decides where a ship lives on a grid. Messages from the server consist of A ship is at B location with C velocity firing D weapon at ship E and similar. The client sends commands like shoot weapon A at ship B, move me in direction C. The server sends responses to commands about shooting with damage information or notices that you can't use that module because your target is out of range.
Consider module lag. You turn on a module and begin shooting a ship. The server receives this, calculates damage and sends that information to the damaged ship and anything that knows the HP of that ship. Now let's assume the server gets overwhelmed and cannot process all the requests it gets. The client will not deactivate the module until it is told to by the server. If you try to deactivate the module you are waiting for the server to tell the module to turn itself off (to stop hacking of cool down timers presumably). If the server is busy processing every other request that came before yours, while more requests stack up behind yours it can take a long time before your module gets the message that it's ok to shut down.
Now assume a client side lag. You attempt to lock a ship that is not there. You request for the ability to lock that ship. The server responds to your client telling it that there is no ship there. Any message that is sent can be interpreted by the server in context of what it perceives to be the correct state of events. Desync'd and caught on an asteroid? Your client shows you that your path is clear. You request to move in that direction. The server responds telling your client that you cannot and must bounce against the asteroid that you don't even know is there.
First rule of online gaming: Don't trust the client. Corollary: transmit as little information as possible. You don't let the client tell the server the clients position which could be hacked, you let it tell the server the clients direction and possibly velocity.
A lagged client will send correct information. It's just that the information will usually not be very useful and the response will be equally useless. Attempting to lock a target that doesn't exist is still a valid message. It doesn't adversely effect the state of the grid. It does adversely affect the one who is operating with that lag.
Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
|
Aurora Aujii
Gallente Genesis of Cosmic Grace
|
Posted - 2010.07.28 23:50:00 -
[30]
Originally by: Yuki Kulotsuki A lagged client will send correct information. It's just that the information will usually not be very useful and the response will be equally useless. Attempting to lock a target that doesn't exist is still a valid message. It doesn't adversely effect the state of the grid. It does adversely affect the one who is operating with that lag.
Thank you for that explanation Yuki... it does explain alot.
Aurora
|
|
|
|
|
Pages: [1] 2 :: one page |
First page | Previous page | Next page | Last page |