Blob buff
Also, opens the system up for creating lag, to slow the fight down, to have more time to bring reinforcements.
Sometimes in eve, you want to get the fight over and done with as soon as possible, sometimes you simply CANNOT stay on the field and you are desperate to get it done with before the blobby backup arrives - this just allows that blob to catch you while you're still stuck fighting
Originally Posted by teds :D
I'm more excited by this development than the upcoming incarna release. And I don't live in null and never have. I wanna say well done CSM6 for having an influence on CCP already. Have you considered having CSM sigs made to assist championing your spotlights?
So about 6 months until we can potentially see this on TQ. Looking forward to it.
Generally speaking, more conflict is good for all of EVE's health. More battles that actually result in shit blowing up isn't just good for the game's reputation and 0.0 players, but it means better press and a more vibrant economy, faster political developments, more opportunities for awesome shit to happen.
Status of Babby: 100% Formed
Except, the way I read it, time would dilate because the blob was already there doing their blob thing - it wouldn't be a factor to you unless you were unable to do your objective before they arrived, which is pretty similar to how it works now but with a lower chance of blackscreening >.>
errrr....
noone having an issue at the prospect of 10x more time on a blobbed node...? with inties behaving like BS and BS ending up with 1.5 minutes of align time (with MWD trick, that is...)? 2.5h of aggro time...?
what about cynos? and titan bridges (four bridges for the entire evening)?
will docked people in that blob'ed station system enjoy 300sec session timers when changing ships....?
what about downtime when it hits during a 0.1x mutiplier.... while stuff is onlining? what about reinforce timers? can the NC blob a system by themselves for a few hours and shift a station timer away from/towards prime time?
a battle at 0.1x speed while dead people reship and return within the equivalent of ~3 minutes will drag such battles out even further.
sure, i suppose any band aid has to be welcome.
alas, the ^n problem persists and considering nodes currently die with <500 in local, i wouldn't be surprised if we had to endure the 0.1x multiplier with 1k peeps already. and if that's the hard cap (there is a hard cap, right...? RIGHT....?) the node would still die...?
but hey... CCP can say they did 'something' and will use that 'justification' to not deal with the inherent problem for another 3+ years (example: technetium).
so... sure, it'll take the edge off a bit, but it won't solve all that much. definitely not as much as this PR campaign of CSMblog, devblog, mumble-session and whatnot tries to sell us.
and as rudolf said: the "sooo sloooow" feeling will not be pleasant. starcraft:brood war on speed 5 (ladder speed) instead of the common 7 could test your patience, yet this factor will be much much worse - and eve is certainly not as action-packed as SC:BW to begin with -.-
all this just so bombs can explode properly?
(and it wouldn't be CCP if they actually did, amirite?)
:bittervet:
This concern was already addressed:
Not sure what I think about this, but tbh, I don't think I like it. I guess we will see how it turns out. Considering this is Eve, and CCP, I imagine it will go poorly.
They actually talked about a lot of that in the blog, that things certain game mechanics would have to be exempt from time dilation in order to avoid being exploited.
Session Change Timers will probably be subject to TD. Aggro timers, possibly as otherwise logoffs would become much easier. Cynos yes because otherwise if things were slowed down enough no one would have time to actually cyno in before it closed. Online timers, possibly - wouldn't want people onlining tons of POS guns while your ROF is reduced by 90% I figure.
The blog suggested something like 20x time dilation would be the furthest they would go before the user experience becomes just as bad as dropped server calls and blackscreens.
Status of Babby: 100% Formed
[quote=a mitten]you make a bunch of whiny posts on this forum and on eve-o about your precious elite pvp nanogang, while everyone else enjoys themselves[/quote:1s915pz5]Great, so if I happen to be on the same node as a stupid derp fight, my gang travels at 1/10th speed?
Shall I quote the post where you are crying about lag in fleet fights being so unfair
I think "slow motion" is important to keep in the description, because that's exactly what it is. Let's say that your guns cycle every 2 seconds. So, in a fleet fight, your EVE client will attempt to activate the guns every 2 seconds until you turn them off or unless the server is overloaded (in which case it will wait before trying again, which is what we see as lag). You can imagine that 1000 pilots activating their guns every 2 seconds generates 500 requests per second, more if the guns are ungrouped.
Time dilation is slow motion that the EVE client and server agree on ahead of time when the node gets overloaded. Under time dilation, cycle times are increased for everyone with the goal of bringing server load below 100% (the magical threshold at which all requests are processed). So in a heavy fleet fight, your guns cycle maybe every 5 seconds. For 1000 pilots, that's only 200 requests per second, something that the server could potentially keep up with. It will look like slow motion because the module cycle timers will actually progress more slowly, in accordance with the amount of dilation.
What is unclear is whether Destiny itself will be correspondingly slowed; if you may end up in a situation where you have a 30s cycle time on a MWD with no physics slow motion, carrying your ship out of the fight before your requests for navigation can be processed, etc... but I'm sure they will figure this out and there will be no problems at all!
Veritas has stated that EVE scales at something less than n^2, so going to a tau of .1 would more than triple node capacity.
Realistically, time dilation lets you deal relatively gracefully with overloads, but the long-term fix is gameplay changes that organically limit fights to sizes the nodes can handle without time dilation (by making it strategically and tactically the best move). One of the unintended consequences of time dilation may well be taking the pressure off addressing that reality, when in fact it should be used to buy the time to grapple with it.
Someone mentioned that this would be good for artilleries...
Isn't it quite the opposite.
I might be wrong here, but here it goes:
- Seem to remember someone saying that artilleries was the better one in high lag due to it`s long cycle-time and easier to deactivate.
- Artilleries have a ROF ~23sec (abaddon+2gyros), imagine what that would be when in time dilation....
- Lasers have 4,6 sec on pulse and 7,3 sec on beams. Thats 5 shots from the pulse and 3 from the beam in the same time it takes 1 shot with artillery.
If you have 1600 man fleetfights, it`s doesn't matter if you are getting shot by artillery or lasers when there are 100+ BS shooting you. You will die.
And now, when every command will be registered and taken into account...
imagine artilleries with 25% speed... Thats a cycletime of over 90 seconds...
Versus beams with 30 sec...
Or pulse at 19 sec.
Will session change timers be dilated? Battles taking place on both sides of a gate between 1 dilated and 1 undilated system would be pretty weird. Dilated session change timers could also become universally un-fun when you're forced to do a few session changes in a row. Imagine docking, leaving your ship, clone jumping, boarding a ship, and undocking, at 20x dilation.
How about structure anchoring/onlining? If you're trying to raze some system and the anchoring timers aren't dilated, they'll be setting up dickstars faster than you can warp from one to the next.
My :CCP: prediction: transversal will still be calculated based on real-time, resulting in everything always hitting (stealth dread buff).
Skill training online: Daesis Wrack
Everything else: Cosmic Osmo
Bullet time on its own is fine, as long as it doesn't become the norm. Which it will, unless long-distance travel is also nerfed so it becomes harder for such stupidly large blobs to form up to begin with.
Destiny should be fine. Physics engines are just big equation solvers at the hearty. You put a bunch of variables in, do some number crunching and out pop a bunch of position and velocity numbers. One of those input numbers is the time increment from the last time the physics engine was run. As such, it never uses the system clock directly for calculations, so slowing down time will never be a problem for it, (unless CCP have reallyWhat is unclear is whether Destiny itself will be correspondingly slowed; if you may end up in a situation where you have a 30s cycle time on a MWD with no physics slow motion, carrying your ship out of the fight before your requests for navigation can be processed, etc... but I'm sure they will figure this out and there will be no problems at all!the implementation).
Physics engines are really susceptible to the length of that time delta. A big time increment can make a physics engine become extremely unstable - the smaller the delta the better. Most of the time the way a game gets around this problem is to run the physics engine at a faster rate than the user interface. Say your UI is running at 30FPS, the physics engine may be running at 200FPS (or more - 10:1 physics to graphics is not uncommon). Of course, CCP may not have done that, but given what they were talking about with the nano stuff and how extremely high speeds lead to the physics engine breaking down, I'm pretty confident that the two are no coupled tightly. I certainly don't forsee any major issues with the physics engine in a very slowed down state or even dealing with the game clock dynamically changing speed relative to the wall clock.
In theory ships should handle better in time dilation.What is unclear is whether Destiny itself will be correspondingly slowed; if you may end up in a situation where you have a 30s cycle time on a MWD with no physics slow motion, carrying your ship out of the fight before your requests for navigation can be processed, etc... but I'm sure they will figure this out and there will be no problems at all!
First, what is the whole point of it, server will receive your inputs and process them, and secondly player (in real time) will have more (real) time to react. MWDs should have their (dilated) cycles at 10s, so (from your example) what from players perspective will take 30s, ingame be done in only 10.
You guys are all thinking too small.
Dilating large fleet fights to combat lag is one thing, but once you have gone to the effort of coding all that shit in, why not make it an environmental effect.
WH systems with 2.0x time dilation could be HILARIOUS.
Time dilation is such a retardedly stupid concept, it's not entirely surprising that somebody at CCP dreamt it up.
It is actually a really bloody clever idea, if you "get it".Time dilation is such a retardedly stupid concept, it's not entirely surprising that somebody at CCP dreamt it up.
When nothing goes right, go left.
I stand by my original analysis. This is far from a cure, in fact it's solidifying a problem.
I'd rather have a fucked up sandbox that made it impossible for BFFs to exist than time dilation to become a solution.
Posting Permissions
Reply With Quote
Bookmarks