Pages: 1 [2] 3 4 5 6 7 8 9 10 11 .. 11 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 14 post(s) |
Natalia Kovac
Minmatar Stimulus Rote Kapelle
|
Posted - 2011.04.22 13:30:00 -
[31]
Edited by: Natalia Kovac on 22/04/2011 13:31:35 How about you fix your sov system and 0.0 mechanics such as jump networks etc that encourages these 1500 man fights. Multiple smaller objectives would encourage smaller gangs instead of "timer's coming out, everyone derp into this one system".
I really don't trust that CCP can mess with code this much and not **** everything up completely in a region-wide manner.
Btw, if my nano gang happens to be on the same node as a huge fleet fight, will it travel at 1/10th speed too? That seems to rather defeat the purpose, particularly as it is not spelled out which constellations and systems share which nodes.
|
Mjana
Switzerland EVE Corp.
|
Posted - 2011.04.22 13:33:00 -
[32]
How will you handle the change of time dilation factor in regard to long-running modules (like Ice Harvesters and possibly Cynos)? With long-running modules, you will have to change the "speed" of the cycle during a cycle, and reflect this change properly in the UI.
Example: -TD-Factor is 10% -X starts Cyno field (assuming it's affected by time dilation, so cycle time will be 6000 secs/100 mins) -50 Minutes later TD-Factor changes to 50% -X should now be sitting there only for 10 more minutes, not another 50 and should see in the UI when the Cyno expires.
(From my experience, the change of cycle time while a module is active/repeating is not properly reflected in the UI at the moment. See repeating Ice Harvesters, when fleet boosting starts [reducing cycle time].)
Also, when deciding whether to include Cynos in time dilation or not: Don't forget about Black Ops Cynos with their 60 seconds cycle.
|
Wrathful Hawk
Caldari Warsmiths Warsmiths.
|
Posted - 2011.04.22 13:33:00 -
[33]
I love the idea but i'm just not sure I like it and I'm not even in these fights.
The concept behind it is fantastic, but there are alot of potential problems.
Scenario A - 1600 man fleet fight, even 800 vs 800. Reds bug out and split up into two forces of 400 each, both of these will have slight dialation, while the 800 man fleet in system loses the abililty to chase because they're more heavily dialated. Then reds set up a nice little trap because they can move more freely or use the 800 being stuck to rep up faster, get cap back faster, etc. Unfair advantage to whoever leaves the dialated system first.
B - Ok, so two 400 man fleets vs an 800 man fleet, the two 400 man fleets cycle in out of the system in alternation to allow the 400 in the adjacent to have virtually no dialation, rep up, recharge cap and shields, reload, and get back in, while the fleet of 800 is running at 1/3 speed because they're in a system with 1200 people in. The 400 man fleet has now had an advantage in that fight with the exception of the session timers.
C - Your POS is about to go out of reinforced in 3 hours, you need to defend it because it's so going to be a tech moon. You spam the entire alliance into this POS because it's also got 7 titans in. Time dialation his 70% and before you know it, the offensive force is on the back foot yet the reinforced timer expires as it's still running at 100%.
I dunno how valid these are, just some of my thoughts you'd want to address. [i]---------
Wrathful Hawk - CEO of Warsmiths
|
Darth Vapour
|
Posted - 2011.04.22 13:33:00 -
[34]
The mechanics for time dilation are fine and well but I'm not quite sure the server can be trusted to apply this correctly when it is overloaded and behaving weirdly. Why would it be any better at doing time dilation then, say, making a ship disappear after the agression timer wears off ?
|
Wrathful Hawk
Caldari Warsmiths Warsmiths.
|
Posted - 2011.04.22 13:35:00 -
[35]
Originally by: Mjana How will you handle the change of time dilation factor in regard to long-running modules (like Ice Harvesters and possibly Cynos)?
Ice Miners in pew pew? Pics or GTFO :D [i]---------
Wrathful Hawk - CEO of Warsmiths
|
Jupix
Minmatar MuroBBS United
|
Posted - 2011.04.22 13:36:00 -
[36]
Originally by: xttz
Originally by: CCP Veritas
I could see putting it in the monitor or some other such out-of-the-way place. I'm hoping that dilating certain UI elements (module animation, targeting spinny, things of the sort) will communicate it enough for standard uses so we don't have to do something ham-fisted.
I'd be happy to see a small hour glass on screen when time is running at below a 1.0 ratio to normal. Put it up next to where the session change timer lives and make it optional as a client setting. It could then take rotate and refill accordingly once per time-dialated second - just like the old windows mouse icon.
Perhaps use in-world graphics in addition to (or instead of) UI graphics. So engine trails / missile trails / gun flashes / etc. get longer/slower, moving the camera causes a very slight ghost image, "static" effect overlayed over the screen, or something along those lines.
|
Mjana
Switzerland EVE Corp.
|
Posted - 2011.04.22 13:45:00 -
[37]
Originally by: Wrathful Hawk
Originally by: Mjana How will you handle the change of time dilation factor in regard to long-running modules (like Ice Harvesters and possibly Cynos)?
Ice Miners in pew pew? Pics or GTFO :D
Well, Ice Harvesters just came to my mind as a long-cycling module (yes, I am a hisec-carebear )
But the question is still valid concerning Veritas's comment on affected systems:
Originally by: CCP Veritas First implementation will have all locations on the node dilated. For dedicated nodes that'll be only the system that's causing the load, but for shared nodes all systems on the node will be dilated. A couple other things need to fall into place before I can sanely have a per-system clock, but that's certainly desired.
It means that a hisec system with carebears enjoying their Ice(cream) might pretty well live on the same node as a (non dedicated) 0.0-system with an unexpected big fleetfight.
Okay, in such a case, I would probably find another system to mine, because mining at 10% rate would suck
|
Rainus Max
Fusion Enterprises Ltd Morsus Mihi
|
Posted - 2011.04.22 13:47:00 -
[38]
Sounds like decent fix for the mechanics of lag.
The question I've got to ask is, how is this going to fix the main problem of player boredom waiting for things to happen? It's all well and good being able to actually target the next primary but if I can go of and build a life size replica of the Eiffel tower out of matchsticks in that time its not really fixing/working around the problem.
|
Batolemaeus
Caldari Free-Space-Ranger Morsus Mihi
|
Posted - 2011.04.22 13:52:00 -
[39]
While I applaud the technical side being handled competently, what is still desperately missing here is something from game design.
You can not keep this up by technical tweaks, as long as the game design that causes the load is not reviewed and tweaked. So while you're doing a nice job finally tackling graceful degradation of service, I do wonder if the complete and utter silence from game design is supposed to tell us something..
|
Antihrist Pripravnik
4S Corporation Morsus Mihi
|
Posted - 2011.04.22 13:55:00 -
[40]
Ok... a quick question. How much time would we need to kill a Titan in dilated time?
|
|
Mashie Saldana
Minmatar Veto Corp
|
Posted - 2011.04.22 13:59:00 -
[41]
Originally by: Antihrist Pripravnik Ok... a quick question. How much time would we need to kill a Titan in dilated time?
That depands on the time dilation. ;)
Well if the node as mentioned in the blog is running at 30% dilation it will take three times as long from a module cycling point of view. However because things are dilated 100% of your fleet can bring damage instead of just the 20% not blackscreened.
|
Xaarous
Caldari Woopatang Primary.
|
Posted - 2011.04.22 14:01:00 -
[42]
Originally by: Rainus Max Sounds like decent fix for the mechanics of lag.
The question I've got to ask is, how is this going to fix the main problem of player boredom waiting for things to happen? It's all well and good being able to actually target the next primary but if I can go of and build a life size replica of the Eiffel tower out of matchsticks in that time its not really fixing/working around the problem.
Things happening slowly and predictably beats the pants off of things happening chaotically or not at all. If you're saying that "running at 10% for an extended period is le suck", you're right. The big question is whether this mechanic really allows the current big fights to run MOST of the time at at least 33% (arbitrary value, but 1/3rd of real-time is still pretty good for all but torps and arty :p).
|
BlankStare
|
Posted - 2011.04.22 14:01:00 -
[43]
Originally by: Batolemaeus While I applaud the technical side being handled competently, what is still desperately missing here is something from game design.
You can not keep this up by technical tweaks, as long as the game design that causes the load is not reviewed and tweaked. So while you're doing a nice job finally tackling graceful degradation of service, I do wonder if the complete and utter silence from game design is supposed to tell us something..
They're locked in a room with pizza and mountain dew until they come up with some gameplay for Incarna... One of the many faces of Mandrill @Mandrill - Website email |
Camios
Minmatar Sebiestor Tribe
|
Posted - 2011.04.22 14:03:00 -
[44]
Edited by: Camios on 22/04/2011 14:04:16 Let me write down a tentative list of things that could be affected by time dilation:
- Module cycling time (quite obvious)
- Shield/Cap recharge rates (quite obvious too)
- All physics stuff, like
- Speed
- Acceleration
- Warp Speed
- Warp Acceleration
- Scan timer delays (probes and onboard scanner)
- Session change timers
Is it correct?
Second, how often will the TD factor change? The less often it changes, the more we'll have risk of lag-related unfairness. Will it be in the scale of every seconds, every 10 seconds or every minute?
And as others have asked, how time dilation will affect long timers as siege/triage/cynosural field? To clarify my question, will the real time duration of these timers decided when firing them up or it will change to follow the TD factor changes?
|
Zi'Boo
|
Posted - 2011.04.22 14:12:00 -
[45]
Originally by: CCP Veritas
There are no plans to bring down time in any systems besides those with load. I don't consider the scenario you present to be any different than what happens today.
The main difference between jumping reinforcements into a lagged out system today vs a TD one is that today those reinforcements will most likely lag out on jump in and die before they can do anything (although it's been a while since I've been in a large fight so that may have changed), where as if your system works, and you know that you can jump out and you wont be a sitting duck for people that are already loaded in that system.
Quote:
First implementation will have all locations on the node dilated. For dedicated nodes that'll be only the system that's causing the load, but for shared nodes all systems on the node will be dilated. A couple other things need to fall into place before I can sanely have a per-system clock, but that's certainly desired.
Will there be any warnings for other systems sharing a node with a time dialated one? Imagine jumping a freighter to some system in empire and then taking over an hour to get out of there just because someone on the other side of the galaxy is having a battle.
|
Rainus Max
Fusion Enterprises Ltd Morsus Mihi
|
Posted - 2011.04.22 14:15:00 -
[46]
Originally by: Xaarous
Originally by: Rainus Max Sounds like decent fix for the mechanics of lag.
The question I've got to ask is, how is this going to fix the main problem of player boredom waiting for things to happen? It's all well and good being able to actually target the next primary but if I can go of and build a life size replica of the Eiffel tower out of matchsticks in that time its not really fixing/working around the problem.
Things happening slowly and predictably beats the pants off of things happening chaotically or not at all. If you're saying that "running at 10% for an extended period is le suck", you're right. The big question is whether this mechanic really allows the current big fights to run MOST of the time at at least 33% (arbitrary value, but 1/3rd of real-time is still pretty good for all but torps and arty :p).
Exactly, a dilation ratio of 1:2 or 1:3 is pretty reasonable but any more than that for any length of time is going to get tedious. Until we have a rough idea of how much time will slow down we need to be significantly aware that there is a player at the other end that needs to be entertained or they will just log off. Im not saying Gridlock dont think like that but there are some areas of CCP that do tend to (or at least appear to) miss that point.
That being said though a 3hr 'normal battle' (IE no lag etc) at 1/2 or 1/3 speed? Even that is going to wear thin very quickly.
|
Batolemaeus
Caldari Free-Space-Ranger Morsus Mihi
|
Posted - 2011.04.22 14:17:00 -
[47]
Oh by the way:
Logoff timers need to be properly prolonged too. And, while you're at it, fixed so that ships actually DO disappear once their timer is up.
|
|
CCP Veritas
|
Posted - 2011.04.22 14:17:00 -
[48]
Originally by: Camios Second, how often will the TD factor change? The less often it changes, the more we'll have risk of lag-related unfairness. Will it be in the scale of every seconds, every 10 seconds or every minute?
Probably somewhere in the 1-10 second range (wallclock-wise). Not real sure...it'd depend on how the synchronization needs to be, and I haven't gotten even that far yet~
Originally by: Camios And as others have asked, how time dilation will affect long timers as siege/triage/cynosural field? To clarify my question, will the real time duration of these timers decided when firing them up or it will change to follow the TD factor changes?
They'll change to follow TD factor changes. Essentially they're all "Do this a X time" and all that matters is if it's X-o'clock yet or not. Doesn't matter how curvy the time was to get there.
|
|
Meissa Anunthiel
|
Posted - 2011.04.22 14:21:00 -
[49]
Originally by: Camios Edited by: Camios on 22/04/2011 14:04:16 Let me write down a tentative list of things that could be affected by time dilation:
- Module cycling time (quite obvious)
- Shield/Cap recharge rates (quite obvious too)
- All physics stuff, like
- Speed
- Acceleration
- Warp Speed
- Warp Acceleration
- Scan timer delays (probes and onboard scanner)
- Session change timers
Is it correct?
Second, how often will the TD factor change? The less often it changes, the more we'll have risk of lag-related unfairness. Will it be in the scale of every seconds, every 10 seconds or every minute?
And as others have asked, how time dilation will affect long timers as siege/triage/cynosural field? To clarify my question, will the real time duration of these timers decided when firing them up or it will change to follow the TD factor changes?
Also locking timer, recloak and target after decloak timers, missile velocity, explosion velocities (depending on whether they're "instant" with a speed factor taken into account or if there's a lead-up time to explosions catching up with you, I never tested), booster duration, ECM duration,
Session timers could be excluded (ship change in station and whatnot, unless they're identical to the redock timer) ----- Member of CSM 2, 3, 4, 5 and 6
|
Jason Edwards
Internet Tough Guy Spreadsheets Online
|
Posted - 2011.04.22 14:24:00 -
[50]
Do capitals get processing priority? If so it sounds like capitals will become nasty op. I say this because right now capitals do seem to have priority.
ex. Have 2 clients open, both docked same station, 1 carrier and 1 cruiser. 2 screens plox. hit undock on subcap and then relatively quickly hit undock for the cap. Carrier undocks faster each time it seems.
------------------------ To make a megathron from scratch, you must first invent the eve universe.
|
|
Xaarous
Caldari Woopatang Primary.
|
Posted - 2011.04.22 14:25:00 -
[51]
Originally by: Rainus Max That being said though a 3hr 'normal battle' (IE no lag etc) at 1/2 or 1/3 speed? Even that is going to wear thin very quickly.
This is the billion-ISK question right here. How much "game time" (dilation is not perceived) will be saved because now everything's working vs. how much extra "real time" (player wall-clock) is spent? It's fairly easy to imagine both extremes - the fights actually go FASTER because the effective damage output from both sides jumps up, OR everything's so slow that nothing happens (reps can actually get queued up before a primary alpha-strike because both sides have so much time to react, and downtime happens before the fight is resolved), and of course, more likely, somewhere in between.
IMHO no-one (including CCP) can predict where it's going to land; we HAVE to see this in mass-testing. What I will predict is that this will be the most popular (in terms of attendance) mass-test to date. I say throw in some test-server-SP rewards anyway! (so the 2nd and subsequent rounds will have more capitals )
|
Sino Sarn
Sick Tight Controlled Chaos
|
Posted - 2011.04.22 14:26:00 -
[52]
Originally by: CCP Veritas
Originally by: Trebor Daehdoow UI suggestions: there should be a readout of the current TD factor, and perhaps a running graph (ala the frame-rate graph). If you want to get crazy, red-shift the nebula background based on the TD factor.
I could see putting it in the monitor or some other such out-of-the-way place. I'm hoping that dilating certain UI elements (module animation, targeting spinny, things of the sort) will communicate it enough for standard uses so we don't have to do something ham-fisted.
Let's use color codes! >75% of normal time = green 25%-75% normal = yellow <25% = red
Consider it a property of the system the pilot is current in and place accordingly.
|
Bienator II
|
Posted - 2011.04.22 14:26:00 -
[53]
Edited by: Bienator II on 22/04/2011 14:30:17 i already see wormholes with +50% time bonus :P
good work guys, but i am a bit disappointed about the multi threading statement. I suppose the cluster is all built for single thread throughput hardware wise, thats why no high gains are expected. Nodes with 64 parallel threads are not that unusual today so perf increase of 4x could be easily beaten. (but of course talking about it without looking at the code is a bit difficult for both sides :))
btw being a OpenCL guy i see lots of potential for gaming servers. sky is the limit :P
|
Nouhou Malio
|
Posted - 2011.04.22 14:31:00 -
[54]
This strikes me as a powerful solution to an unsolvable problem. It doesn't make the problem (lag) any better, but it makes the symptoms of the problem more manageable and predictable.
I suggest having the starmap present Time Dilation as a statistic (updated every 10 minutes or something) like pod/shipkills, and perhaps an autopilot option to avoid dilated systems. This would prevent many of the "I entered a system and couldn't get out for 15 minutes!" problems.
Originally by: Zi'Boo
Will there be any warnings for other systems sharing a node with a time dialated one? Imagine jumping a freighter to some system in empire and then taking over an hour to get out of there just because someone on the other side of the galaxy is having a battle.
This is the most interesting aspect of this idea technically. As far as I know, a player can't currently know what other nodes reside on the same server as the node he's on right now. Assuming those nodes don't change all that much (say, Youl, Pashanai, and Tar are on the same machine for months), you could conceivably use time dilation to snoop those associations. This makes me uneasy for some reason I can't articulate right now.
On the other hand, if a solar system can run at 100% up until the point where there are 200 ships in local all launching and retrieving drones, maybe it's not a huge problem: It would take so much manpower to trigger the effect, it wouldn't be practical to do extensive snooping.
|
Camios
Minmatar Sebiestor Tribe
|
Posted - 2011.04.22 14:34:00 -
[55]
Edited by: Camios on 22/04/2011 14:35:54 Edited by: Camios on 22/04/2011 14:34:27
Originally by: Meissa Anunthiel
Also locking timer, recloak and target after decloak timers, missile velocity, explosion velocities (depending on whether they're "instant" with a speed factor taken into account or if there's a lead-up time to explosions catching up with you, I never tested), booster duration, ECM duration,
Session timers could be excluded (ship change in station and whatnot, unless they're identical to the redock timer)
I realize that I forgot a lot of things. BTW explosion velocity is just a number that enters the formulas, it has nothing to do with a "delay" in the time an explosion needs to get to you. The only thing that matters is the ratio explosion velocity vs target nominal speed, and nominal speed would not change (only real speed would).
Actually, most of these changes should follow automatically fomr a change in destiny's tick rate (right?), but some other's won't.
Quote: Essentially they're all "Do this a X time" and all that matters is if it's X-o'clock yet or not. Doesn't matter how curvy the time was to get there.
Oh fine. Do all module cycling (Dogma?) works in the same way? And what system is responsible of the targeting process?
|
J Kunjeh
Gallente
|
Posted - 2011.04.22 14:38:00 -
[56]
Great blog and a great idea. I'm very interested to see the dialogue on this one and to see how the test runs come out. Innovative solution for a vexing problem.
~Gnosis~ |
AnonyTerrorNinja
Minmatar Atomic Geese
|
Posted - 2011.04.22 14:39:00 -
[57]
I for one think that it should be such that if a system has its time dilated, all systems within x jump range (that is to say, system to system gate jumps) should be dilated in a bubble fashion.
If the range is as far as 5 jumps, then the primary system has 100% dilation, 1 jump out has 90%, 2 jumps out has 75%, 3 jumps out has 50%, 4 jumps out has 20%, 5 jumps out has a 'entering x anomaly' warning and no dilation, the anomaly being whatever justification could be provided for story purposes to create this time lag, such as a giant gravity well created by the blob of ships, which transverses through the gates somehow.
The purpose of this, though CCP Veritas disagrees, is to gradually slow people down to the dilation extreme for the purpose of 'smoothing' their rejoining the fight. This should happen because if they can get to the system next door at 'normal speed', you have a scenario such as this:
1. Several bombs got launched in a fight and a good few dozen people died 2. They 'respawn' 10 jumps out 3. Their average warp speed is ~3au/s and the distance per system that needs to be warped averages 30au. Align time is ~9s average, so if we round things a bit I think that should translate to around ~30s per system at best for covering each, taking into consideration in-warp accel/decel 4. Taking the above into consideration, 10 jumps worth of travel (keeping in mind that jump bridges are on the table for removal or have already been removed, and not everyone and their uncle does truly have access to a titan's jump bridge) would take approximately 300 seconds, or 5 minutes. 5. With the dilated system running at, as provided in the example, a third of its normal speed, that means that during those 5 minutes worth of travel, only ~1.5min worth of actual combat has occurred. Assuming heavier load as would likely occur when even more people flow into a fight thanks to dilation making it possible, we can (safely) assume that the average could extent to as severe as 1/5th of the normal speed, if not worse. This means that 1 minute of actual combat has transpired for the 5 minutes of travel spent by the group rejoining the fight
I don't know about the rest of you, but I don't like how that would look. There's then the issue that a jump bridge would mean that people could still instantly enter a system unless a slowing mechanic were implemented for that, creating a time funnel slowing those entering down (in terms of time till they actually appear in system). Besides all of this, you just might be reading my signature. |
Trebor Daehdoow
|
Posted - 2011.04.22 14:44:00 -
[58]
Originally by: CCP Veritas
Originally by: Trebor Daehdoow UI suggestions: there should be a readout of the current TD factor, and perhaps a running graph (ala the frame-rate graph). If you want to get crazy, red-shift the nebula background based on the TD factor.
I could see putting it in the monitor or some other such out-of-the-way place. I'm hoping that dilating certain UI elements (module animation, targeting spinny, things of the sort) will communicate it enough for standard uses so we don't have to do something ham-fisted.
There will definitely have to be at least a text display of non 1:1 time dilation, otherwise people will get confused, and won't know if it's client lag, TD, network problems, etc.
I would also suggest adding it to killmails.
|
Marlenus
Ironfleet Towing And Salvage
|
Posted - 2011.04.22 14:47:00 -
[59]
Edited by: Marlenus on 22/04/2011 14:50:43 Edited by: Marlenus on 22/04/2011 14:47:44
Originally by: Sino Sarn Let's use color codes!
NO! Let's not!
This game is already enough harder for those of us in the 8-10% with insufficient or non-standard color vision. There are aspects of the interface that are completely broken because of color (Like, the red/green colored running lights that used to be the only way to tell from outside scoop range whether an anchorable can was anchored; then they redesigned the can models and now I can't tell, or get anybody to tell me, whether there's still a difference; or how about the color-coded ECM module icons in indistinguishable shades of delicate pastel?)
Color should never be the primary (worse yet, only) way to access important game info. There should always be a color-insensitive visual indicator.
The spinny hourglass proposed above would be fine. However, screenshots are an important enough part of this game that I think some sort of numeric indicator visible on screen would be preferable from the player perspective (though I can see why CCP might prefer that the degree of dilation not be visible in epic screenshots.) ------------------ Ironfleet.com |
Adunh Slavy
|
Posted - 2011.04.22 14:51:00 -
[60]
Edited by: Adunh Slavy on 22/04/2011 14:52:23 In the GUI there should be some something that says dilation is in effect and to what degree. Not only will this let players know what is going on, and what to expect, but it will also allow players to properly anticipate what they need to do and when. Eve has become rather twitchy in its way, and timing is important.
Also the description in the blog, of how quickly the amount of dilation can change may be rather disconcerting if it is jumping around from say 10% to 90% here and there. May want to consider not allowing time to return to normal (100%) quickly, while allowing lots of dilation (5%) to occur quickly.
The Real Space Initiative - V7
|
|
|
|
|
Pages: 1 [2] 3 4 5 6 7 8 9 10 11 .. 11 :: one page |
First page | Previous page | Next page | Last page |