|
Author |
Thread Statistics | Show CCP posts - 6 post(s) |
Korizan
|
Posted - 2008.09.18 02:44:00 -
[1]
Edited by: Korizan on 18/09/2008 02:44:55 YEh based on this alone.
10 ships each with in say 50 meters would cause ALOT more causality bubbles THen say 10 ships 50 km apart.
And it can be scaled up with no issues. BUt the denser the population in one area, say a fleet in formation under z (momentum) would create a bigger problem then the same number in a fleet spread out over greater distances.
IF drones use the same mechanism and are treated as ships then you can see how it compounds the issue.
Also a fleet warping on to a grid would have a huge numbers of possible causality bubbles compared to singles. but that would also depend on your procimitly of other ships on warp in.
Very interesting none the less. WOnder how many mathamatitions worked on it or would be interested in looking @ how it works.
At least that is how I interpretate it. Probably wrong though.
Signature is too large. Please resize to a maximum allowed file size of 24000 bytes. Navigator |
Korizan
|
Posted - 2008.09.18 02:54:00 -
[2]
NOw that I think some more about it.
IF they are using a ships potential for movement in thecausality bubble equations then...
A fleet of intercepter would actually create more bubbles then a a fleet of same numbers in a carriers.
So with that you could actually say that the faster ships go the more bubbles you get and the greater the problem.
So it is not only numbers but speed that also causes the problems.
Interesting even if it is pure speculation. Signature is too large. Please resize to a maximum allowed file size of 24000 bytes. Navigator |
Korizan
|
Posted - 2008.09.18 20:51:00 -
[3]
THere seems to be a lot of mentioning of weapon systems in the replies. The original post by Faife is in essence a way of handling ships and like items in a 4 dimensional space (forth being time) and predicting there locations.
SO what we are talking about is bumping to put it simply. This system also allows for a smooth looking invironment when multiple people are on the same grid. Other wise you would have people jumping around to random points when your client gets an update.
Recently some people have seen desync's. This is what happens when this system gets overloaded. Your clients predictions of what is happening compared to the servers are not in sync.
Now weapon system might use some of the numbers crutched by the system for damage modifers but they will run on there own algorithms. Keep in mind weapons sytem have there own tags such as target and lock and fire and set time cycles for each one. To some extent that are actually much simpler to deal with as they are most likely delt with after the fact then actually dealing with prediction of motion.
THis can be seen by the instant pop. or blown up before loading is complete.
Basically you are seen and fired on and those are sent to the server the server crunches and sends it all to the client who is still trying to load system and other items and gets the damage given all @ one go.
SO end up in your pod.
|
Korizan
|
Posted - 2008.09.18 23:11:00 -
[4]
Originally by: PirceHat Edited by: PirceHat on 18/09/2008 22:18:48 That actually explains why fighters lag the shit out of stuff. Because they can follow people in warp there causalities bubbles include a whole set of events that generally don't exists for other ships.
CCP should consider halving the number of drones carriers can drop and giving them a double damage bonus, same with Motherships.
Also I doubt its exactly "on line" of code, a for loops are at least two :p. It is probably however, very short.
I would rather love to see what equations he uses, dynamical systems are fascinating :p.
Although fighters and drones could and would use these functions I am not inclined to believe the base functions are the root of the problem. THe rationel behind this is that both fighters and drones are essentially controlled by the computer and inherantly should have less bubbles. ANd secondly I believe drones should be causing the same issues.
IF the lag is only in certain instances, ie when fighters warp I would suspect a problem with the coding, not with with the base thoery controlling them.
So it is a question of a design flaw or a flaw in the implementation (a bug in the code). If it is a design flaw then you have to ask do you change the design or remove the feature.
BUt more of a concern is if it is a bug in the coding, what else could be effected by it. By reducing fighters you could be masking a bigger issue.
Never a easy answer and as always pure speculation based on the info we have which is very little
|
Korizan
|
Posted - 2008.09.19 13:23:00 -
[5]
Originally by: Bartholomeus Crane OK, spamming this thread a bit, but another thing I noticed was the apparent sequentiality of the server frame. It looks like this is some kind of sequential loop for all ships involved. Very useful obviously from a time-keeping point of view, but I wonder if in 'times of lag' it wouldn't be useful to loosen the synchronicity of this loop. Basically give each ship his own private loop and allow for some asynchronicity between them. It would mean loss of causality between ships, basically desync again, but it would make it easier to farm out these processes among the cluster (or to Destiny).
Assuming you don't do this already, which would be a bit surprising honestly.
Yawn... morning Barth, sorry still drinking coffee. Well this thread started off as a disscusion about movement and has progressed to lag in general. Now it appears we can say the when a client gets desync'd that is when the system has failed. but the question is why. Is it just shear numbers or is it the pluthra of other data that the client has receiving or the pluthra of data the server(s) are having to handle or communication between the servers and I can guarentee I have missed some other points. I would say all of the above. For every little bit of code that happens it adds to the list till it reaches the breaking point. Why when CCP optimizes one thing you don't always see a change but it might help say a 1000 more players run lag free. It is simply a chain reaction.
So I submit it is not the root of all the lag in EVE, but rather a small issue that adds to the whole. But then again every line of code every calculation adds lag. THat is the real magic finding the balance and a non static world.
And I did find this thread very interesting just seeing and speculation on the theory and principles behind it. A functional block diagram of the coding and server structure would be very interesting to look @ however I understand why CCP would definitely not want such a thing released. But thanks Faife for bringing us this pleasent conversation and to all those who participated in it, to include (surprisingly) CCP.
|
|
|
|