open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Introducing Time Dilation
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: first : previous : ... 3 4 5 6 7 8 [9] 10 11 : last (11)

Author Topic

Vincent Athena
Posted - 2011.04.29 16:43:00 - [241]
 

Originally by: Bladacticus
I didn't have time to read through the entire thread, but I'm concerned by this. How can you dilate time in one place in the EVE universe, but not everywhere? There appears to be potential for abusing it. I warp in a large fleet of 'dummy' ships to slow down a target system, while in a neighboring system I prepare my real fleet perfectly fitted to kill the enemy fleet I've had some time to prepare for.



You can do that right now. Jump in sufficient dummy ships to lag the system out. TiDi does not increase the ability for this type of abuse to take place. If fact it may reduce it. By having the server degrade gracefully, it will handle high load situations more efficiently. Right now when the lag hits the servers behave very badly, like they are fighting with themselves, taking much longer to do tasks than is really needed.

A made up case: Lets say right now 1000 ships deploying and recalling drones can give tactically valuable amounts of lag. With TiDi, it may take 1500 or more ships to get the same effect.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.29 17:13:00 - [242]
 

Originally by: Bladacticus
I didn't have time to read through the entire thread, but I'm concerned by this.


you're obviously not.

yoni
Posted - 2011.04.29 18:07:00 - [243]
 

Cute!

Matrix Bullet Time...

Should be able not just to reduce gridlock but to produce really cool visuals on our clients Very Happy

Celfea Dur
The Flying Tigers
Posted - 2011.04.29 19:16:00 - [244]
 

OK, I'm sorry, but I skipped the last 4 pages of comments so I could get to my post!
First off -- Awesome Idea, I love the Time Dilation approach.


I think this needs to be addressed specifically since it was not mentioned and could weigh heavily on everyone's vision and understanding of what the TD game play experience might end up being. Specifically, how is my game client going to allow me to experience TD during game play?


In my mind, I envision my ship appearing on grid in the most extreme Time Dilation scenario, a major fleet battle the likes of which would make George Lucas, Steven Spielberg, Peter Jackson and all the dark forces of Mordor sob pitifully.

As the ship is appearing through the cyno jump, everything around me is slowed down to a crawl, I am able to see my ship materialize within the slowly pulsating jump effect. Ships are materializing on my screen, my overview is being populated one ship at a time in succession...rapier, hurricane, revelation, avatar, a cheetah...etc. Somebody named NotYoMomma in a legion is filling my screen as he flies by my point of view. As my FC reissues his orders that the fleet focus fire on "WicketySnicket in the damnation", I am watching my overview intently waiting for the designated target to appear... as soon as he does, I confirm his range and click to lock him in my overview. The ship responds with the familiar locking signal and my targeting reticle begins to hone in on my target. I activate all guns and lastly click my repper to go active...all systems go, I am in the fight!

Now,as the next few seconds have been dilated to last over the course of a minute or two, can I rotate my screen around so I can view the battlefield in all its amazing, fire-filled glory as ships slowly materialize and disintegrate all around me? Can I focus my camera view on the little rifter that is straking a nearby Maelstrom with autocannon fire in slow motion.... blap blap blap...blap blap blap!! And can I then right-click on my fleet's flagship and check the pilot's name just as my locking reticle hardlocks my target and my capital lasers erupt out across the battlefield to seek out the damnation that is rolling hard right to align to a nearby safe point?

If that's how CCP envisions TD, then not just Yes, but Hell YES! Ohhh hell yes! Sign me up, bring it on, make it so!


BUT...
If on the other hand, certain elements of my client are also locked to the same speed as the TD factor in-system, thus making the overall game non-interactive, then I'm essentially sitting there watching a slow-mo cut scene of an event that I can't interact with and I might as well go into the kitchen and put on some popcorn because it will be 3-minutes-30-seconds before I can cycle my guns again. Although my efforts in the game are playing their part, my entire fleet is just sitting there watching the next few seconds unfold until the FC calls the next target. Whereas in the first scenario, the FC is rotating the battlefield around, precisely looking at where he needs to position his forces and discussing battle tactics with individual pilots to intercept individual targets simultaneously as the big guns are lashing out with surgical precision against one target at a time.

I think anyone can agree, that Time Dilation has the possibility of adding so much more depth and immersion to the game that it's almost a given that CCP has to go down this path. If we're talking about the ability to turn a lag-infested, black screen of nothingness into a cinematographer's dream of the epic space battle on the scale of the deepest regions of the Eve universe itself -- then I implore you, CCP, please get it right!

Spyke BlackIce
Minmatar
Posted - 2011.04.30 06:15:00 - [245]
 

Originally by: CCP Veritas
Originally by: Vincent Athena
If we had some sort of anti time travel rule:

A fleet knows something is coming out of reinforced, so 3 hours early they jump to that system, time dilate it by a gamma of say 2 for 3 hours. The system is now 1.5 hours "in the past". Now after that 3 hours the defenders get home from work and try to come in to defend their stuff, but because of this "anti time travel" rule, they got to sit looking at a session change timer got an hour and a half while their stuff is blown up.

I think that we got to have it that when you jump into a time dilated system, you jump in just like any other jump.


I'm inclined to agree. Jumping in/out of dilation is a bit odd, I'll grant folks, but I don't see a way around it that's not more odd/exploitable.


I asked/suggested this back in post #169... To avoid all of the oddities, questions as to what should and should not be affected, possible problems, and anticipated exploits of TiDi, how feasible would it be to simply dilate the entire game when a fleet battle or other actions occur that trigger the effect?

Since the entire game would slow down, there would be no reason to load a system hours before a planned engagement so that the defenders couldn't jump in in time to fight back as has been postulated as an obvious possible exploit. In fact, since there would be no reason to purposely slow the entire game (at least I can't think of any off the top of my head), any engagements causing the TiDi effect to occur would probably not last long enough to be a detriment to anyone not involved in the actual triggering event, AND everything in the game would remain synchronized.

Also, as I suggested in my earlier post...
Quote:
Perhaps a small notification could pop up along with the suggested TD indicator(s) announcing that due to a huge hostile engagement in <insert system name here>, time has been slowed temporarily. Heck, it could even be tied into the backstory with something along the lines of -

Quote:
"Due to the enormous amounts of energy and technology, some of which is alien in nature and not fully understood, being employed in these huge fleet battles, the flow of time is affected, slowing down in direct proportion to the size of the fleets involved, but as the combatants begin to dwindle and thus the energies used die down, time begins to return to its normal flow."


Cosmoes
Minmatar
Posted - 2011.04.30 08:02:00 - [246]
 

Edited by: Cosmoes on 30/04/2011 08:08:28
Sounds interesting and looks like a pretty good solution two thoughts though.

You mentioned all systems on same node get time dilated. I'm not sure how it's currently set up but unless nodes are placed in systems based on physical location (neighbouring systems on same node) it could cause problems.... also what will this do to a system like Jita?


My second point is that players are the only place I see this going wrong. If you are slowing down the system waiting for commands to be done then we will see quite a long delay in responding to our commands. If we take 5 minutes to catch up on the initial calculations of warp in and launching drones and activating modules players are gonna freak out during those 5 minutes.

Even if you slow down the time so general calculations are slowed down how about player input? If you have 3000 players spamming the warp button non-stop for 5 minutes while you are catching up on the warp in command how is time dilation gonna deal with a massive build up of player input?


EDIT:
One more question about long fights, say we have some massive rr logistics drake fleet that would take 1 hour for a similarly sized fleet to take it down. If the speed is slowed down to say 5% then it's gonna take 20 hours to take down... most people would want some sleep or something if a fight is stretched out that much.

Cosmoes
Minmatar
Posted - 2011.04.30 08:52:00 - [247]
 

One more point, I'm not entirely sure about this one but keeping the client in sync with the server.

As I understand it the server just slows down doing less calculations so it is more like a slide show than bullet time. While it's probably not mostly about movement I'll use a missile traveling as an example.

Say a cruise missile is traveling at 2.5km/s for 40 seconds. If it's slowed down to 1/10th speed then it would go 250m/s. Easiest way to do this it would just update 1/10th of how often it normally would say instead of 60 fps it's 6 fps. You could implement an additional bullet time so it still goes at 60 fps but just slows down/breaks up movement (that would probably only want to be implemented client side).

The problem I see is keeping the TiDi rate in sync with the client. As I understand it the client is capable of calculating the continued position and movement of objects as well and regularly compares with the server to check that it's results and the client are the same. If the TiDi rate is jumping up and down our client is gonna be getting different results to the server which will cause objects to jump around (only on the client side) and possible other nasty stuff.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.30 08:58:00 - [248]
 

Edited by: GeeShizzle MacCloud on 30/04/2011 09:00:50
Originally by: Cosmoes

Sounds interesting and looks like a pretty good solution two thoughts though.

You mentioned all systems on same node get time dilated. I'm not sure how it's currently set up but unless nodes are placed in systems based on physical location (neighbouring systems on same node) it could cause problems.... also what will this do to a system like Jita?


My second point is that players are the only place I see this going wrong. If you are slowing down the system waiting for commands to be done then we will see quite a long delay in responding to our commands. If we take 5 minutes to catch up on the initial calculations of warp in and launching drones and activating modules players are gonna freak out during those 5 minutes.

Even if you slow down the time so general calculations are slowed down how about player input? If you have 3000 players spamming the warp button non-stop for 5 minutes while you are catching up on the warp in command how is time dilation gonna deal with a massive build up of player input?


you have obviously:

1) not been in a laggy fleet fight before
2) not read and understood the dev blog
3) not read even the last few pages of the discussion

i would suggest u acquaint yourself with the principle of TiDi and the discussion before embarrassing yourself.

Jonaaz Dsz
Gallente
Posted - 2011.04.30 10:16:00 - [249]
 

how do u catch up on time

now say 2 ppl stacking crates

at normal time they can stack 6 crates

but now 1 person is dilated to 30%, so he will only stack 2 crates.

Time is still progressing, so the person dilated comes out of dilation and has stacked 2 crates while the other has stacked 6 crates.

Say for a 30min timeframe, rest of eve has done 30min of mining, hauling, whatever.
But the dilated ppl has only done 10min battle (during the same 30min mining, hauling, whatever).
Meaning the 10min battle ppl have lost 20min game time as they come out of dilation.

Meaning if mining and battle starts at 10:00, the clock on the miners say 10:30. But the battle ppl say 10:10.

Or am I missing something??

Yes I know it's a rather crude fixture, but see the thoughts behind it.

Cosmoes
Minmatar
Posted - 2011.04.30 10:48:00 - [250]
 

Originally by: Jonaaz Dsz
how do u catch up on time

now say 2 ppl stacking crates

at normal time they can stack 6 crates

but now 1 person is dilated to 30%, so he will only stack 2 crates.

Time is still progressing, so the person dilated comes out of dilation and has stacked 2 crates while the other has stacked 6 crates.

Say for a 30min timeframe, rest of eve has done 30min of mining, hauling, whatever.
But the dilated ppl has only done 10min battle (during the same 30min mining, hauling, whatever).
Meaning the 10min battle ppl have lost 20min game time as they come out of dilation.

Meaning if mining and battle starts at 10:00, the clock on the miners say 10:30. But the battle ppl say 10:10.

Or am I missing something??

Yes I know it's a rather crude fixture, but see the thoughts behind it.


As I understand it only systems that are expensive and heavily used during mass fleet fights are slowed down. Things like clock, learning skills, market trades, manufacturing etc. will all continue as normal.

This is either done by having a certain section of the CPU dedicated to deal with these tasks that's always available or having them on a different server to the space pew pew.

GeeShizzle MacCloud
Caldari
Posted - 2011.04.30 10:50:00 - [251]
 

yes you are.

if mining and battle starts at 10:00 in those 30 minutes (dilated or not) both groups of people will see their clock at 10:30.

people need to get away from this misconception that TiDi dilated everything. it doesnt.. theres no requirement to catch up time, cause theres no 'lost' time.


the only possible exploit that TiDi might create is the possibility of a fleet to jump out of a system affeted by TiDi via gates and be able to rep shields/armor/hull faster due to a more restored module duration.
but even in doing that it presents a tactical disadvantage of having to load the system and grid again when jumping back in.
Plus having a fleet leave a system would mean load is decreased so the advantage of jumping out and repping is reduced merely by trying it, as the enemy fleet in the system you've jumped out of will have its TiDi effects reduced and be able to rep faster too.

MoarMining
Posted - 2011.05.01 06:07:00 - [252]
 

This sounds like a great idea, but I have a question that arose right after hearing it. I guess my initial thoughts go into how can I break it to use this to my advantage... First thought is of the slow system is that everywhere around it would have a pretty strong advantage wouldnt it? Example, if Someone has 800 people in a middle system "i'll call it x". And i have 400 people in a nearby system picking off straglers and smaller fleets, the bigger fleet will never catch the smaller fleet. It's like a game of chess where one players moves take twice as long as anothers to do.. If i see a white pawn slowly moving to a spot where he can get one of my guys.. I can just move my guy out of the way because i'm moving twice as fast. So in the end smaller groups are going to be incredibly stronger than huge fleets, because while the Giant fleet is stuck in some system moving at 25-50% speed I can be one system over blocking anyone trying to reach them Fairly easily because i know its going to take them 2-4 times longer to be able to respond than normal. So honestly i think the time dilation should work for an entire arena. Say in System X your running at 50% speed, one jump out it should be 60% then two jumps out 70% three would be 80% and so on until you get to max speed. Because then the Load is spread out even more than relying just on that one system, and players wont really have a time advantage. Because sure it will take you a while to get the the fight.. But it will take twice as long to get there.. but its also lasting twice as long anyways... It shouldnt turn into a fight of who can come back from the dead and join back in where you left off fight. Because if the fight is one jump out of a huge station system where all of one side has their ships.. The other side dosn't stand a chance.. If you die, you hop one jump out and grab a ship AS your ship is blowing up...

Orgell Evaan
Minmatar
Tax Avoidance Through Alliterative Syndication
Posted - 2011.05.01 14:58:00 - [253]
 

Originally by: Hyperforce99
Love the idea, as an alternative to soul crushing lag, i'd rather have bullet time.

Also, i'm curious how the role players are going to explain it, should be interesting Laughing


A new combat drug, probably Jovian, that alters temporal perception. However, the drug is very difficult to manufacture (at undisclosed locations) and hard on pilots' bodies and psyches, so its use is limited to very high risk situations, where near-certain clonedeath is likely...

/puts away RP-shovel.

Vigo Plesh
Posted - 2011.05.02 03:32:00 - [254]
 

So let me get this straight. If there's a massive fleet battle consisting of enough players that the physics engine on the server(s) can't keep up, the game play will lag (like it does now) but it will be a purposeful lag so disconnects don't occur and game play can continue albeit, slowly?

The example given is 1600 users in a single battle.

Has it occurred to anyone that if 1600 users are in a battle, that's the computing power of at least 1600 CPU cores?

If the issue is one of computing power why not distribute the CPU load to client machines? Older/Slower machines can be exempt from participating.

The only issue would then be making sure the distributed system didn't get hacked. You could have computation spread out among all players in the game so some User in Jita for example could be computing missile damage of a battle in Null sec somewhere. Additionally, because of the sheer number of cores made available you could send the same physics computations to 3 or 4 nodes simultaneously and compare results.

The computational engine could be a separate install to the main game and users could choose to participate. I would bet you could easily add 10-20,000 additional cores for computation in this way.

Forget about slowing the game down. Just add more Powa!

GeeShizzle MacCloud
Caldari
Posted - 2011.05.02 11:52:00 - [255]
 

Edited by: GeeShizzle MacCloud on 02/05/2011 11:54:49
well as much as cloud based computing would be just epicly awesome for Eve, theres sooooo many important factors and hurdles to consider before even trying to plan something like that out.

not only is there the security issues, the bottlenecking and throughput problems and lag caused by sending information all over the world from iceland and waiting for it to come back, to only send it out again, you couldnt guarantee the computers opted in are not doing it maliciously, or trying to degrade gameplay for some advantage, whether game related or even as a rival business in the same industry.

The one thing i absolutely LOVE about Eve is the fact its soooo robust in comparison to other games. theres very little if any cheating that happens in eve. some may say metagaming in eve is a form of it but in comparison to other gaming titles out there eve is almost surgically clean of hackers and exploits!

the cloud computing thing is a perpetual minefield to be fair and i doubt CCP as a business would want to open itself up to that level of multi-pronged attacks. itll be like running into a packed stadium, standing legs apart and pointng at ur crotch shouting "hey everyone, kick me in the nuts!"

i would add that i do love that idea... (not the kick me in the nuts one! but Vigo Plesh's) just wish the real world wasnt soo much of a c**t about these things.

Vigo Plesh
Posted - 2011.05.03 04:55:00 - [256]
 

@GeeShizzle MacCloud

Just a few comments on the subject...

It's not Cloud Computing but distributed computing. And there are numerous frameworks which already exist for handling distributed clusters in a secure fashion.

It all comes down to a single question. Are the calculations complex math based upon small amounts of data? or are the calculations based upon huge datasets?

If the answer is large datasets, then you can totally forget everything I am proposing.

Dav Varan
Posted - 2011.05.03 13:54:00 - [257]
 

Originally by: Vigo Plesh
@GeeShizzle MacCloud

Just a few comments on the subject...

It's not Cloud Computing but distributed computing. And there are numerous frameworks which already exist for handling distributed clusters in a secure fashion.

It all comes down to a single question. Are the calculations complex math based upon small amounts of data? or are the calculations based upon huge datasets?

If the answer is large datasets, then you can totally forget everything I am proposing.


Please point to one example where cloud or distributed computing is used for a Realtime application.


Cedori
Shiva
Morsus Mihi
Posted - 2011.05.04 12:19:00 - [258]
 

Originally by: Vigo Plesh

If the answer is large datasets, then you can totally forget everything I am proposing.


Bear in mind, I have no "real" idea about what's going on, but I'm 90% sure it's this.

The way EvE was coded, requires numerous pages to the database, particularly for some events (e.g. shipdeath). Though now awesomely-RAIDED-SSD'd and RAMSAN'd, this is still the slowest step.

Matalino
Posted - 2011.05.05 21:18:00 - [259]
 

Edited by: Matalino on 05/05/2011 21:21:57
Originally by: Vigo Plesh
If the issue is one of computing power why not distribute the CPU load to client machines?
This has already been answered: the Eve simulation is single-threaded, making it multi-threaded at this point does not offer the prospect of sufficent gains for the effort. Using multiple CPU's requires multi-threading.

When Eve goes multithreaded it will still be run server side not client side. The overhead in distributing the load to the client machines would be worse than simply running the simulation locally. Distributed processing is not a viable option for Eve anytime in the forseeable future.

Even when the Eve simulation is rewritten as multi-threaded, it will still be able to benefit from time dialation. TD is a sensible next step in the war on lag.


Lederstrumpf
Posted - 2011.05.06 13:06:00 - [260]
 

Did anybody of you funny guys at CCP ever measure the total cost of yielding in your round robin scheduler?

And reading you already know about ship death and modules yielding often -- maybe your general round robin approach is just crap? Ever thought about using different/multiple types of schedulers for different tasks?

[Multithreading]

"We'll get there some day 'cause, well, we'll have to, but for today it's way more work for the benefit we'd see from it to be worth attacking."

If you're well aware you'll have to, there's no reason not to start right away. But get a book about scheduling first.

Lederstrumpf
Posted - 2011.05.06 15:27:00 - [261]
 

Edited by: Lederstrumpf on 06/05/2011 15:39:59
Edited by: Lederstrumpf on 06/05/2011 15:31:37
http://cdn1.eveonline.com/community/devblog/2010/part%201%20-%20figure%201.png

[Sending an update to each client]

"Further investigation showed that this is mainly expensive due to the time required to serialise each update message."

So about 50% of total ballpark pre-tick time is spent serializing update messages to be sent to clients, which is blocking Evolve and post tick phase, right? There's no way to offload and parallelize parts of it?


http://cdn1.eveonline.com/community/devblog/2010/part%202%20-%20figure%201.png


^ according to this you managed to optimize sendtoclients ... does optimization blur your vision? Optimization is good but you shouldn't get fooled by limited test scenarios into believing it's not about scalability.

The first graph shows about 1/3rd of a second total. Where's the rest of the tick second? Ballpark idleing?

OSGOD
Posted - 2011.05.09 06:43:00 - [262]
 

just another patch to try to keep us happy ,i`ll put money on it that it just ****s up everything as usual ,i have been on since 2007 and lag was bad then it got better and better but now lags just as bad if not worse than 2007.Instead of adding candy how about adressing the problems that have been ignored for years,as i have said manytimes before you pay peanuts you get monkeys.

Mithrasith
Posted - 2011.05.09 12:43:00 - [263]
 

Interesting approach.

One thing I would add if I were creating this would be a graphical precentage representation at the top left hand of the screen stating that Time Dialition is in effect, and at what percentage.

This will allow people to have the proper expectations as to the time it takes to do a particular action.

The representation should be dynamic, meaning as the time dilation changes, so should the readout in the client displays.

Rockin RicciBobbi
Posted - 2011.05.09 18:24:00 - [264]
 

Quote:
"Here's how I envision this working for a large engagement (say, 1600 or so). When the attacking fleet warps in, the server gets extremely overloaded - warp-in and other setup tasks like drone deployment are quite expensive - so the game clock gets dilated extremely, down to 5% of real time or something."


Some of my toons have been in large fleet engagements that lasted 4 hours. Even a 50% time dilation is not feasible in many cases and allowing time dilation down to 5% is just plain idiotic. Here is why: Players will find ways to exploit and manipulate the game mechanics to maintain such time dilation to their side's advantage. To use one example from the dev blog: by continuously warping a large fleet around and deploying drones. So now we have the possibility of what would otherwise be a 1 hour engagement stretched to 20 hours. Or a tower being attacked with plenty of time to reinforce before downtime/server reboot except the defending fleet can just dilate time instead of actually engaging to keep that from happening. That is ridiculous. I know more complicated scenarios about exploiting time dilation have already been mentioned, but just think of the very simple unpreventable ones. We need fewer exploitable game mechanics instead of CCP creating more and more. Crashes and disconnects and desyncs suck, but that is better than adding a time dilation mechanic. How is all that added code to make time dilation work going to make Eve more efficient overall? It's not. It's like claiming that you're making the Boston Marathon shorter by making everybody run slower.

The game has become a victim of its own success and most easy fixes have been tried. Time dilation would fix some of the symptoms associated with large fleet fights instead of making Eve work as promised and as advertised. A real solution will be difficult but we don't need another work-around bandaid. Given CCP's ever-increasing willingness to concentrate on their internal metrics instead of the user experience, I am not surprised at this proposal.

GeeShizzle MacCloud
Caldari
Posted - 2011.05.09 21:28:00 - [265]
 

Edited by: GeeShizzle MacCloud on 10/05/2011 07:26:09
Originally by: Rockin RicciBobbi
Quote:
"Here's how I envision this working for a large engagement (say, 1600 or so). When the attacking fleet warps in, the server gets extremely overloaded - warp-in and other setup tasks like drone deployment are quite expensive - so the game clock gets dilated extremely, down to 5% of real time or something."


Some of my toons have been in large fleet engagements that lasted 4 hours. Even a 50% time dilation is not feasible in many cases and allowing time dilation down to 5% is just plain idiotic. Here is why: Players will find ways to exploit and manipulate the game mechanics to maintain such time dilation to their side's advantage. To use one example from the dev blog: by continuously warping a large fleet around and deploying drones. So now we have the possibility of what would otherwise be a 1 hour engagement stretched to 20 hours. Or a tower being attacked with plenty of time to reinforce before downtime/server reboot except the defending fleet can just dilate time instead of actually engaging to keep that from happening. That is ridiculous. I know more complicated scenarios about exploiting time dilation have already been mentioned, but just think of the very simple unpreventable ones. We need fewer exploitable game mechanics instead of CCP creating more and more. Crashes and disconnects and desyncs suck, but that is better than adding a time dilation mechanic. How is all that added code to make time dilation work going to make Eve more efficient overall? It's not. It's like claiming that you're making the Boston Marathon shorter by making everybody run slower.

The game has become a victim of its own success and most easy fixes have been tried. Time dilation would fix some of the symptoms associated with large fleet fights instead of making Eve work as promised and as advertised. A real solution will be difficult but we don't need another work-around bandaid. Given CCP's ever-increasing willingness to concentrate on their internal metrics instead of the user experience, I am not surprised at this proposal.



your arguments are soo full of holes along with your knowledge of the subject that its rediculous

Rockin RicciBobbi
Posted - 2011.05.10 07:27:00 - [266]
 

Originally by: GeeShizzle MacCloud
Edited by: GeeShizzle MacCloud on 02/05/2011 11:54:49
The one thing i absolutely LOVE about Eve is the fact its soooo robust in comparison to other games. theres very little if any cheating that happens in eve. some may say metagaming in eve is a form of it but in comparison to other gaming titles out there eve is almost surgically clean of hackers and exploits!



I really like how delicately you sanitize botting "some may say metagaming..." Some may say the hordes of mission running and mining bots in highsec, the trade-bots in Jita, and rat-bots in nullsec, are a violation of the TOS.

Originally by: GeeShizzle MacCloud
your arguments are soo full of holes and knowledge of the subject its rediculous


Not at all, I read the dev blog multiple times and I do have a pretty decent theoretical and working-knowledge background on this subject. I worked as a real-time programmer for a couple of years. But it's not just about the technical aspects. It's about the players.

Players in eve who compete with other players for resources and dominance will use every tactic they can to achieve victory. They always have-it's just human nature. Huge megablobs like the northern coalition fleets and the drone russians would be most capable of and will most certainly manipulate time dilation to their advantage. Currently, the Mcblob strategy is to put so many ships on grid they either crash the node, or de-sync the opponent. Either way, the opposing fleet coming in stands no chance. Time dilation gives the McBlobs another tool-make the engagement last longer so that the opponent can't achieve their objective. This is painfully obvious to anyone who has a clue.

Lag is caused by shortcomings in latency, system resources, and programming efficiency. That is what must be addressed. Time dilation does not address or fix this, it just tries to make lag sexier. Lag is still lag, and implementing code for time dilation will increase system overhead and add lag. This is yet another example of how CCP wants to put a bandaid on something that requires open-heart surgery.

GeeShizzle MacCloud
Caldari
Posted - 2011.05.10 11:27:00 - [267]
 

Very Happy excelent! time to get into some good arguments once more!

Originally by: Rockin RicciBobbi
Originally by: GeeShizzle MacCloud
The one thing i absolutely LOVE about Eve is the fact its soooo robust in comparison to other games. theres very little if any cheating that happens in eve. some may say metagaming in eve is a form of it but in comparison to other gaming titles out there eve is almost surgically clean of hackers and exploits!


I really like how delicately you sanitize botting "some may say metagaming..." Some may say the hordes of mission running and mining bots in highsec, the trade-bots in Jita, and rat-bots in nullsec, are a violation of the TOS.


if you'd bother to actually read that conversation i was refering to the combat orientated side of eve gameplay here so stop trying to derail the subject and quote out of context, go read up Quoting out of context

Quote:
Lag is caused by shortcomings in latency, system resources, and programming efficiency. That is what must be addressed.

Well please tell us and ccp how to bend the laws of physics to make a zero-lag MMO reach across the entire globe. ohh and while ur at it u can build that quantum computer uve been sketching down and rewire every country in the world's communication infratsructure to be ultra efficient and hyper fast.
Yes i was overexadurating and it was to prove a point. CCP and Eve online have to live in the real world with real world problems both in terms of technical ability and financial capability. yes we'd all like CCP to have the world largest and fastest servers and data throughput but unless they get a blank cheque thats guaranteed not to bounce they have to look to more real world fixes for these problems.

some could say that there is a way to go for programming efficiency and you'd be right... but its a slow and complicated process. Veritas has already estimated that going multicore 4 wide from a single cpu with the servers may only achieve between 2 to 3 times increase in speed. and re-programming eves servers to do so would take a collossal amount of dev time.

Originally by: Rockin RicciBobbi
This is yet another example of how CCP wants to put a bandaid on something that requires open-heart surgery.
Time Dialation is the equivalent of putting a pacemaker on a person heart. where as what you want is the heart to be totally replaced. yes ideally that might be the best choice but CCP have made a decision to persue the avenue that provides the best performance to development time, and TD clearly is it. if you dont think so then ill give you a demonstration....

GeeShizzle MacCloud
Caldari
Posted - 2011.05.10 12:05:00 - [268]
 

Edited by: GeeShizzle MacCloud on 10/05/2011 12:22:34
Time dialation as you should know is designed to reduce the amount of incoming requests to the server so to keep a buffer between the used CPU %age and its maximum. the reason for this is so that other higher priority requests that are not explicitly combat related (such as jumping in and out etc..) can be handled promptly and immediately. Veritas has said somewhere that even with TD on it may not have the effect of reducing requests by half when at half speed. TD is more likely to only be half as efficient as originally hoped. so the number of clients a typical server will be able to handle may only increase by 50% when the server halves the playing speed.

say an average server can cope with 400 to 500 players in one system dualing it out without time dialation coming into play. with TD slowing the pace to half speed as more fleets jump in (with jumps and grid loading happening immediately) that 500 player no-lag server can now accomodate 750 without visable lag.

Say more come into the fold again and TD increases to 1/4 of the speed it was originally. the same server can now accomodate 1125 relatively lag free with jump ins and grid loading happening immediately... we carry on and add more... TD halfs the speed again so its running at 1/8th the speed originally. The same server can now cope with 1687 players.
By half again means 2531 players relatively lag free but as a much reduced speed.


Now... coding the eve servers to use multicore CPU's will yield an increase of at best between 2 and 3 times current. taking 2.5 times as a conervative estimate means that same 500 player server will be able to perform to 1250 players before module lag, de-syncs and no-load grids etc... and i do believe many people in null sec have seen and been in fights larger than that before. Meaning people will still complain even after eve goes multicore about the fact they lost their super unfairly cause they had a grid that didnt load or their ship didnt align or jump out when it was possible to.


With TD you could say that at 1/16th speed, a 1 hour battle can technically last 16 hours and that compared to where we are now that isnt any form of improvement. saying that though shows ignorance to this situation in the real world. no fight is going to start at 1/16th speed with 2.5k pilots in 1 system waiting in optimal for everyone both friend and foe to be ready, fights like this escalate over a course of time and amazingly enough, people do die and the numbers are reduced somewhat.

Even so, the problem with fleet fights of that scale currently is the lost requests meaning clients rage and log and re-log.. causing more requests and more lag. TD means expensive requests like loading grid and jumping into a system woould be handled immediately.. meaning no rage and no relogging.

the argument that FC's will use tactics that are expensive to the servers CPU is valid, but has been argued about waaaay before this. i even asked veritas himself about the ability to monitor requests sent by individual clients that are above normal. specifically to keep an eye out for these tactics and he's assured me that he'll have something evil and terrifying for people who do deliberately overload the servers, if it occurs.

you could ask why something like that hasnt been created before and thats because module lag has always been an issue. many pilots dont realise that spamming a module activation when its unresponsive only adds to the problem. with TD in place and active its extremely unlikely you'll ever see module lag again. so the genuine spammers wont be raging and spamming and saying eve is broke blah blah blah. keeping an eye on server requests by client ID on a server with TD running will quickly show up the users deliberately trying to overload the server. so if you are one of those super pilots spamming ur 30 or so fighters to attack then return to orbit and so on, expect to be noticed and expect repurcussions

GeeShizzle MacCloud
Caldari
Posted - 2011.05.10 12:18:00 - [269]
 

tbh i for one want to see eve servers go multicore, but i seriously believe TD is more beneficial for fleet fights and would be quicker to code and implement than going multicore.

so TD > Mulitcore, but we have to make sure after TD is done and working well that veritas and his team gets to work on getting the servers running on quad cores, after all a quad core server runing with TD has epic stats!

taking that typical multicore server i postulated in the post above, being able to handle 1250 players with no lag and slapping TD on it means at 25% speed (1/4th of original) itll be able to handle 2812 players!! thats very close to the largest feetfight in eves history, at a quarter speed but LAG FREE!!

Rockin RicciBobbi
Posted - 2011.05.10 20:09:00 - [270]
 


Quote:
if you'd bother to actually read that conversation i was refering to the combat orientated side of eve gameplay here so stop trying to derail the subject and quote out of context, go read up Quoting out of context


Context has no bearing when make blatantly false statements to make your point. You are the one who got on the derailing track by gushing about how you "LOVE" Eve's robustness and how clean, hacker and exploit-free it is. Talk about the pot calling the kettle black...

GeeShizzle, you and I both know that the players who will benefit the most from time dilation are the ones in huge sov McBlobs who can most easily manipulate td to their advantage. I have participated in solving complex technical challenges, so I am sympathetic, from an academic point of view, to the problems that CCP faces in delivering an enjoyable user experience.

However, from the perspective of a paying, playing customer, CCP's internal metrics do not interest me, nor do the complexities of the challenges they face, because I am not getting paid to deal with them. They are. What matters is not their metrics or their perception of their game. It is the customer's perception that matters. This proposed solution does not and if implemented, most likely will not improve many of their customers' perception of the game. Additionally it does not carry out CCP's promise to deliver the experience they advertised.

Blindly repeating a software developer's blog as if it were gospel does not change that either.


Pages: first : previous : ... 3 4 5 6 7 8 [9] 10 11 : last (11)

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only