| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Ztrain
Evolution
Band of Brothers
   |
Posted - 2007.09.10 22:30:00 -
[1]
Edited by: Ztrain on 10/09/2007 22:37:33
Without going in to deeply in to CCPs architecture blunders will explain some of the basic issues. Through carefully examining how their client works certian things have been noticed and tested. Of the "techniques" used in lag combat of course I'm not going to explain most but man have they saved my ass on big jump in's many of times.
But just as an example, commands on the client are sent to the server whether it shows on your screen or not. In certain situations this allows you to issue commands to the server before your client shows or even registers your actions. When you initiate warp in a laggy inviroment that command goes to the server. The server responds to the reuest and tells your client that your going in to warp in X direction.
So your flying along in warp. What happens is well absoutly nothing. What SHOULD be happening is the server is starting to update your client with the grid of what your about to load in too. All of it. Not limited bandwidth at a fixed rate but as much of what your about to land in as your connection can handle. You arrive on grid, and now your client "visually" locks. I stress visually because operationally it is still working. At this point you can still issue commands and have them relayed to the server. Most people just sit there thinking they can't do anything. Why CCP does this I have no idea.
Mean while the server has registered you as arriving at your destination and technically you have. So everyone else sees you warp in to the grid but your client is artifically locked. Showing performance graphs on my machine has shown that the client is not thrashing the HD loading models or maxing out the processing power of the computer but mostly sitting idle waiting for the server to get around to sending all the information from the grid. When the client "thinks" it has the whole picture it unlocks and you start seeing your slide show. During this locked phase certian command can be executed if you think about it.
While in warp line up visually with where you want to warp out to. So you can see on your screen your warp out point. Use a mouse with a button assinged for double click. Then your command will be deliverd as a double click event and not be based on the timings of a locked up client. The client still sends that command to server and generally when my client unlocks in a super laggy situation I've found that not only am I alighted and full speed but have traveled a decent distance.
There are more ways that combat can be dealt with CCPs lack of experience. There are very simple way's to fix these software design issues. Such as pre loading on warp. As well as not locking the client interface so that people can at least see the part of the battle that the client has recieved from the server.
In small fights great lets see all the graphics. But in 50+ person on grid fights turn off beam effect updating between clients. That will free up bandwidth for more relivant updates. Borderline NDA breaking here but think streaming sever for client server updates hint hint.....
Having watched one of the EVE TV episodes with the new head designer over there though it would seem that adding more blob encouraging "features" and frivilious content such as walking in stations is more important then fixing what parts of the game people actually would like see fixed.
/wishes Infinity was more along in development. Ohh well till then EVE is the only game in town. Hopefully CCP will fix their blunders before it just doesn't matter anymore.
Z
*snip* Don't use your signature to troll. -Rauth Kivaro ([email protected]) |
Ztrain
Evolution
Band of Brothers
|
Posted - 2007.09.11 06:01:00 -
[2]
Edited by: Ztrain on 11/09/2007 06:01:29
The way to do it is to have dedicated high use nodes processors or whatever you want to call them. These need to be able to handle on particular grid. You then break up the grids in high local count system. So have like 5-10 nodes reserved for high density. When local passes the 100 player in system mark that node copies the template from the actual node dividing up the common grids such as moons, gates up amongst the different nodes in that special cluster. Then all traffic to that system would instead of going to it's regular node go to the high traffic cluster.
Everyone would almost appear to jump but then when they reloaded they'd be in the exact same place they were on the new node so other then a brief amount of lag like when jumping through a gate. When in the high traffic cluster the client server connection would be passed between the nodes mid warp. So if you warp from say a staging POS to the gate the server would pass you too the node on the gate. There by the traffic on that node would be only what was actually taking place in the battle.
Would that get rid of all lag. Well no. Pre loading and not locking the client during loads would also help with apparent lag. As well as limiting cosmetic information in high traffic areas. Unfortunately it is my belief that this is something beyond the capabilities of the current dev team. I'd love for them to prove me wrong with Rev 3, but I'm really not holding my breath.
Z
Dr. Ztrain or: How I Learned to Stop Mining and Love the Desync |
Ztrain
Evolution
Band of Brothers
|
Posted - 2007.09.11 17:04:00 -
[3]
 Originally by: Blazde
I'm not so sure session changing people midwarp wouldn't create more lag and you may have to lose stuff like scanning/probng between grids which would suck. I don't wanna see the mechanics of battle change, especially in an abrupt artificial way. We could just go into 1-hit kill mode, no drones, no reloading, no cap regen but it wouldn't be eve. For the same reasons I don't wanna see any hard limits on people per system/grid.
I see what your saying. Although I don't think it would be too much of a problem. The client would not need to be reloaded in that instance just te connection hand off and condition hand off between the server. The client wouldn't reload like a jump or anything. It is kinda like how other games have proven to work very successfully to move from node to node in the many seamless game environments used today.
Like I said before I don't think this alone would reduce all the lag. But what it would do would be eliminate the lag from completely unrelated events compounding. For example the recent 25s engagements. I was in rr- at a SS. The order was given to jump. It took me two minutes to get in to warp just from my SS. My alt 2 systems over also experienced the lag spike. So it's not even down to the system level on a node basis. It really needs to be divided up a lot more.
Z
Dr. Ztrain or: How I Learned to Stop Mining and Love the Desync |
Ztrain
Evolution
Band of Brothers
|
Posted - 2007.09.11 17:30:00 -
[4]
Originally by: Svetlanna
Signed on original post here.
1) is costs too much money for CCP to invest and try solving the issue, therefore refusing and keeping ignoring the complaints
2) CCP has no clue.
Which one is it?
By my observations of how it works. Definitely 2.
Z
Dr. Ztrain or: How I Learned to Stop Mining and Love the Desync |
Ztrain
Evolution
Band of Brothers
|
Posted - 2007.09.13 19:56:00 -
[5]
Edited by: Ztrain on 13/09/2007 20:09:11
Originally by: Chib
ccp have stated a zillion times that they are working with 7yr old code
things are set to improve with the new engine
ofv it will take time to get right after patch 
TBH I really hope it does fix it. But what I have seen over the past year about what they say they want to do and what CCP actually produces are two completely different things. Well we did this but it will be okay when it's balanced with that. But that never manages to materialize etc. I remember them claiming they hate blob warfare. Yet nearly every major change they've made since Rev 1 has done nothing other then encourage and make a blob a near necessity.
Bombs - Dismal failure
DD - For most putting a 60B investment on the line is not worth the risk of using one of the best anti blob tools. Just it's mere presence on the field preventing people from bringing in too big of a blob just for blobing sake since it was more of a all at one loss on a successful DD hit.
Station services - Encourage gangs to disable opponents stations. One of the dumbest idea's in any MMO I have ever seen I might add. On the defenders side takes hours and hours to rep up. Lets see Friday night movie or stare at a station being repped for 3 hours..... hmmmmm On the attackers if they do it with small numbers like Frege tried for a couple weeks they'd spend night after night with relatively no results. We'd rep the station up with alts in between ops while chatting away on TS and reading forums and such. But if you actually want to kill the services in anything resembling something reasonable. Yep you guessed it need a blob.
But wait!!! It wont be a problem because stations will have sentries to protect them....... Oh Rly? When? Why not wait to put the whole feature in at once?
CCP wants to encourage small gangs to go in an disable POSs they claimed LOL. OMG had to pause typing to chuckle for a moment there. Yeah go trying brining a small gang in to disable a cyno jammer or other such item. Yeah you guessed it. They released a blog about the lock speed of the guns. Then they changed and then said oops we gotta change it again. They truly do seem to push stuff out the door without even trying it themselves let alone anything resembling quality control. Hell look at the Siege module bug lol. "Hey Ovur I got this procedure done you wanna check it?" "Nah just throw it in some place it'll be fine."
The list goes on. Those were just the first off the top of my head. But I have found that what CCP claims they want to do ether through them blatantly lying about what they want to do with the game in the future. Or they have no idea how or what it takes to design content to reach their goals.
So pardon me when I am a little skeptical when people say ohh don't worry lag and this and that will all be fixed in the next patch or with the new engine. Just think about it for a moment. If it's a whole new engine with all new code. Then why are they writing a blog about trying to fix 600 of the current bugs? Why wouldn't you just work on the new engine since it's probably going to have all new issues to work out. Unless all that is getting updated is the graphics engine. Which if that's the case their server lag, resource allocation, and networking issues are going to remain unchanged. Not to mention their inability to create game mechanics that achieve their stated goals.
Will be very interesting to see what does in fact happen in November.
Z
Dr. Ztrain or: How I Learned to Stop Mining and Love the Desync |
| |
|