Pages: 1 2 3 4 5 6 7 [8] 9 10 11 .. 11 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 14 post(s) |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 13:14:00 -
[211]
Edited by: GeeShizzle MacCloud on 28/04/2011 13:20:43 i think people need to realise TD will have a marked impact on the DURATION of activation... not the delay between pressing the button and seeing the result. in actual fact the last part of that sentence is exactly what TD solves!
it amazes me how feral people get at changes and its effects to the point that they loose sight of the initial principles of the design brief!
if you're in a dilated system for 7 hours guess what... your clock at the bottom left should and will be the same as everyone elses, even people in jita etc...
POS timers should run separately from TD's effects, in fact its vastly easier to rule out what shouldnt be affected by TD than what should. The list for what will be affected will quite obviously be much larger than the list of what shouldnt. CSM Prop 1 CSM Prop 2 |
|
CCP Veritas
|
Posted - 2011.04.28 13:38:00 -
[212]
Reckon you two fells are correct.
TiDi (it's catching on Trebor) aims to maintain responsiveness under load by expanding durations of things, not by queuing up actions to be done later.
|
|
StuRyan
|
Posted - 2011.04.28 14:01:00 -
[213]
I grasped it then lost it grasped it again and lost it:
What you are saying is that Under heavy stress the serveer will time dilate, does this mean playing eve will be like playing on a spectrum? I shoot - guns cycle - then what?
my eve cloak slows down, everything is done in slow motion aligning BS's take 5 minutes to align? What does this mean for game play?
|
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 14:38:00 -
[214]
im not too sure what u mean by spectrum.. unless u mean the sinclare one!
bt yahh think the matrix, think max paine etc... everything runs slower and because of that smoother. technically people could record the fights and then in a video editor speed it up to normal speed with ultra smooth movements!
the effects of TiDi are even and all encompasing in terms of ship movement, combat module cycle time etc... basically everything to do with navigation weaponry and the like. because of this gameplay is still completely fair and unchanged in terms of balance.
if you want i could try brainstorm a list of stuff that would be affected by TiDi? tho it will be pretty long! CSM Prop 1 CSM Prop 2 |
Joshua Cy
|
Posted - 2011.04.28 15:25:00 -
[215]
Edited by: Joshua Cy on 28/04/2011 15:25:49 What it would look like:
Firing a gun with a 10 second cycle time, and with equally bad lag and TiDi:
With lag: You click the gun, nothing happens for a minute, then the gun fires and 10 seconds later is cycled.
With TiDi: You click the gun, it fires right away, then cycles very slowly, finishing the cycle in 70 seconds. (This example would be for the case where Gamma = 7 ).
Aligning with lag: You hit align, nothing happens for 2 minutes, then your ship turns and aligns.
With TiDi: You hit align, your ship starts turning right away, but does so very slowly, completing the task in 2+ minutes.
Edit: oops, posted with my alt. Im Vincent. |
Firiya Boomsloop
|
Posted - 2011.04.28 16:42:00 -
[216]
I'll geek out a bit :)
I think folks are missing part of the point of TiDi. Going back to Veritas' dev blog, there are certain aspects of fleet fights that cause massive storms of activity (jump in, deploy drones, ship death, jump out). The normal slug fest from my understanding once everyone is loaded is largely OK and tolerable on a dedicated node. The problem is that the system never gets to that state and worse off, you get weird, emergent behavior when the task queues get overloaded that f's up all sorts of things.
If I had to hazard a guess, here is what would likely happen: - Fleet A of 1k is already in the system, TiDi feels a bit of a pinch and puts things around 90% of normal with a few scattered Fleet B dudes - Fleet B fellows light the cyno and Fleet A's 1k ships bridge / jump through said cyno - The system sees that, says, ZOMG, TiDi drops down to a 10x dilation - Fleet A's ships appear, they deploy their drones, modules, etc. and the 10 second process takes 100 seconds - The ships are now in the normal fleet fight state with the expensive switch systems / etc. calls out of the way and dilates up to 75% of normal (1.5x) - The system chugs along between 50-75% of normal, typically dipping as ships are destroyed / etc. - Fleet A gets whomped, sad they their grid overloading failed, FC orders GTFO. The system again sees, ZOMG, I'm dying, dilates down to 10% - Fleet A escapes with 40% of their fleet, the remaining 30% is trapped by bubbles and slaughtered at 80% of normal speed
The bottom line is that most of the time, the system should cruise at something akin to normal speeds (10-50% slower, i.e. 1-2x). You just would likely see the burps come during the massive movement changes (jump in, jump out, etc.).
The trick is going to be determining what factor of TiDi to apply, balancing flow of the game (close to real-time as possible) versus predictable behavior (avoiding the random glitches from overloading). Most likely, the TiDi will have to be overly aggressive (i.e. overcorrect, slow down too much) as it is better to be predictable and then recover rather than messing things up and adding non-deterministic behavior.
Very interesting real-time and control theory too that one could apply to it as well. Wicked cool CCP, wicked cool.
|
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 17:24:00 -
[217]
Originally by: Firiya Boomsloop I'll geek out a bit :)
...The trick is going to be determining what factor of TiDi to apply, balancing flow of the game (close to real-time as possible) versus predictable behavior (avoiding the random glitches from overloading).
thats where the testing on sisi and duality will come in i think.. but tbh i can see veritas applying TiDi on every server apart from he jita node.
in terms of TiDi as a tool for veritas to use, he could balance it so that he keeps 15 to 20% of the servers CPU for calls that TiDi doesnt affect. that way the calls will be processed faster without too much of a noticable difference on grid.
in essence use TiDi as a buffer. CSM Prop 1 CSM Prop 2 |
Bobro Koromyslov
|
Posted - 2011.04.28 18:23:00 -
[218]
Originally by: CCP Veritas
Originally by: Bobro Koromyslov The only possible exploit of "anti-time travel" rule that I see is intentionally slowing-down a system, so that the opponents have to quit the game due to RL business before the fight ends. This may be solved by restricting the possible time difference to a reasonable amount of time.
That leads me to believe you didn't grasp Vincent's post. It boils down to being able to shift a timer forward, which is Not Cool. Allow me to put some numbers on it.
Alliance A owns a station which is under attack by Alliance B. Its reinforcement timer comes out at 20:00. Alliance A calls a CTA for 19:00 so they can clear out baddies before the timer comes out.
Alliance B, being clever and nasty and all things dishonorable, shows up at 12:00 and does silly things to overload the server, dilating time down to 50% of normal time. They're a very determined bunch of people, so they keep this up until 20:00.
At 19:00, Alliance A's fleet jumps, expecting to arrive an hour prior to their timer expiration - plenty of time. However, since the server's been running at half time since 12:00, a total of 7 hours, your idea would have them waiting to jump for 3.5 hours, completing at 22:30. That allows Alliance B to have two and a half hours wallclock of time to take down the station completely uncontested.
In order for Alliance B to arrive in system at 19:00, as they expected to do, they would have had to initiate that jump at 16:40, effectively moving their reinforce timer up by a few hours. This is Not Cool.
You've forgot that I'd suggested to slow-down all the timers, including the reinforcement one, this is actually the key point of this approach.
Returning to the situation you've described:
At 12:00 there is 8h of real time till reinforcement comes out. Here the 50% slow-down starts and, since reinforcement also starts to come down twice as slow, the presumable point of de-reinforcment is shifted twice as far - to 12+8+8 = 4:00 Assuming that the slow-down is kept at 50% all the time, at 19:00 there is still 9h of real time to defend the station. Now defenders try to jump in and, since the target system is late, they have to wait until the clocks are in synch, i.e. when the time of jump in (on the destination system clock) is greater or equal to the time of jump out (on the source system clock). On 19:00 the destination clock is at 15:30 - 3.5h till 19:00, but since the system is still at 50% slow down, the clock will reach 19:00 only after 7h - this is the amount of real time the defenders will have to wait. So they are in only on 2:00 but they still have 2h of real time to defend the station.
2h of fight in 50% slowed-down system are effectively the same as 1h under normal conditions, so neither side gains advantage of pre-overloading servers.
The only problem here is how it correlates with real life. Not all of the defenders may have the ability to wait till 2:00am and attackers may use this fact (and vice versa).
|
|
CCP Veritas
|
Posted - 2011.04.28 18:51:00 -
[219]
Originally by: Bobro Koromyslov You've forgot that I'd suggested to slow-down all the timers, including the reinforcement one, this is actually the key point of this approach.
Ah, indeed, I did miss that. That too is Not Cool for exactly the same reason though - it allows people to move timers, just in the other direction.
|
|
Noillia Durmot
Thundercats RAZOR Alliance
|
Posted - 2011.04.28 19:06:00 -
[220]
+1 that there should be some indication of the dilation factor on the UI. Other than that great idea. Implement it soon please. ================================================ ...any persons living or dead are entirely coincidental.
Noi. |
|
Furb Killer
Gallente
|
Posted - 2011.04.28 19:13:00 -
[221]
Quote: It's often said that the War on Lag cannot be won because our players can always bring one more ship. This is fundamentally true, and embracing that truth is important to the work we do here on Team Gridlock.
I still think this is a bad idea, because it is not a solution to the problem. And no the problem is not that blobs lag down the server (granted dynamic load rebalancing + multicore support would be awesome for that), the problem is that blobs are the only way to take sov, dominion sov is just flawed, fix that.
|
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 19:22:00 -
[222]
Originally by: CCP Veritas
Ah, indeed, I did miss that. That too is Not Cool for exactly the same reason though - it allows people to move timers, just in the other direction.
fully agree and support veritas on this! CSM Prop 1 CSM Prop 2 |
Bobro Koromyslov
|
Posted - 2011.04.28 20:01:00 -
[223]
Originally by: CCP Veritas
Originally by: Bobro Koromyslov You've forgot that I'd suggested to slow-down all the timers, including the reinforcement one, this is actually the key point of this approach.
Ah, indeed, I did miss that. That too is Not Cool for exactly the same reason though - it allows people to move timers, just in the other direction.
Well, OK, it was just my opinion. But plz don't forget that if you make time travel possible, the mentioned time-travel exploits will soon become a part of the common tactics for some corps and you need to make sure that time trips and their effects are easily predictable, so that they don't become a kung-fu, available for the elite only. This all must be very well thought-out before the implementation phase begins.
|
Anij
|
Posted - 2011.04.28 20:50:00 -
[224]
i think eclorc made an interesting point a few pages back though, regarding players issuing commands. as players brains are not time dilated, a player is still capable of issuing commands to his client at full-speed, meaning that if the system is slowed to 50%, during the course of 1 dilated second, the player would be able to issue twice the amount of commands that he would during a non-dilated second.
this may not be an issue at all. i dont know exactly how player commands are handled by the server, or people might just actually control themselves and not go click-crazy, but it would be interesting to know Veritas' thoughts on this
|
|
CCP Veritas
|
Posted - 2011.04.28 21:03:00 -
[225]
Originally by: Anij this may not be an issue at all. i dont know exactly how player commands are handled by the server, or people might just actually control themselves and not go click-crazy, but it would be interesting to know Veritas' thoughts on this
We have some mechanisms in place already to deal with our click-happy brethren. If need be, we can do more on that front. As usual, I like to see that we have a problem before solving it =)
|
|
Cybele Lanier
Amarr Viziam
|
Posted - 2011.04.28 21:07:00 -
[226]
If this means that player skill and coordination matter more than server roulette in a fleet battle, then I will be back in null in a heartbeat. --------------- ""Minimum collateral damage" and "Entire star system" do not belong in the same sentence." |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.28 21:07:00 -
[227]
I think the spamming of commands to move here n there, activate this and that, when its genuine and not malicious, stems from when as a player your client doesn't respond.
This should alleviate this aggravation, and yes you are right that people will be able to still spam as much as they do now. the server tick/second isn't being extended btw. so it wont increase the spam.
It'll just be blatantly obvious who's being a d**k to veritas and his hamsters.
CSM Prop 1 CSM Prop 2 |
Darek Castigatus
Immortalis Inc. Shadow Cartel
|
Posted - 2011.04.28 21:58:00 -
[228]
Originally by: Furb Killer
Quote: It's often said that the War on Lag cannot be won because our players can always bring one more ship. This is fundamentally true, and embracing that truth is important to the work we do here on Team Gridlock.
I still think this is a bad idea, because it is not a solution to the problem. And no the problem is not that blobs lag down the server (granted dynamic load rebalancing + multicore support would be awesome for that), the problem is that blobs are the only way to take sov, dominion sov is just flawed, fix that.
Doesnt address the fact that sov change or no sov change you still have 2 coalitions with close to ten thousand pilots between them going head to head, you will get stupidly huge battles developing anyway. I think its better theres some sort of system in place to deal with that before they start playing around wuith the sov issues again.
http://desusig.crumplecorn.com/sig.php |
Commander Predator
UNITED STAR SYNDICATE
|
Posted - 2011.04.28 23:42:00 -
[229]
I would assume locking time would be dilated too correct? otherwise while running at say 10% the incoming damage would be reduced by 90% timewise making logistics very easy.
|
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.29 00:00:00 -
[230]
Originally by: Commander Predator
I would assume locking time would be dilated too correct?
yes it would
Originally by: Commander Predator
edit* also what about missile boats even though i hate them, wouldnt time dilation essentially slow the time it takes missiles to reach point a to b and slow the activation timer down?
missile boats have a fair few time based variables. module cycle time would be lengthened, missile flight time would be increased inversely proportional to missile velocity. so the missile will still travel the correct distance, just at a slower pace but for an extended length of time. explosion velocity would also decrease in line with ships reduced velocity so to keep the original game balance/mechanic intact. CSM Prop 1 CSM Prop 2 |
|
Inanna Zuni
Minmatar The Causality Electus Matari
|
Posted - 2011.04.29 01:09:00 -
[231]
"The players in the fleet can tell that's happening because many of the HUD elements are animating slowly and the explosions in space are slow-mo too."
er .. no. Sometimes* that happens already and is a problem with the machine at my end. If I can't tell that this is affecting *everyone* then intentional dilation won't seem any different. Use an indicator (flashing?) on screen somewhere please.
Inanna Z
* too often, in fact!
|
Inanna Zuni
Minmatar The Causality Electus Matari
|
Posted - 2011.04.29 01:21:00 -
[232]
oh, and forgot to query the main idea but I see a massive problem in the implementation as described.
Space is not one system!
The description of time dilation details it working on *a* server serving *a* system. But most of the time you'll jump into a system via gates or cyno and unless you know *before you jump* that the time on the other side is different you will get stuck and, in the seven hour delay example used earlier, you'll probably not be able to just wait and wait without knowing how long (a 'difference clock' somewhere?) and can't reverse yourself out either so you'll likely lose your ship.
Gaming the system will be simple if you can dilate a system enough.
IZ
|
Heavy MG
Paxton Industries -Mostly Harmless-
|
Posted - 2011.04.29 02:57:00 -
[233]
I don't see the difference between everything moving slowly or being stuck frozen. Either way things take forever to clear out.
Why doesn't CCP implement a system that automatically loads a node onto an empty cluster/server when the users reach a certain limit? This system would always be dedicated, and you could have more than one. That way things would work normally, call it "automatic" reinforcement.
|
NekoKitten
Gallente Dawizz Mining Corp Inc LEGIO ASTARTES ARCANUM
|
Posted - 2011.04.29 06:04:00 -
[234]
I recon you run this software on *one* CPU .. Isnt it possible to use dedicated hardware for this stuff like nVidia Tesla cards running mad over these things .. Is it possible and wont it improve performance dramatically if implemented right ?
|
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.29 07:46:00 -
[235]
Originally by: Heavy MG I don't see the difference between everything moving slowly or being stuck frozen. Either way things take forever to clear out.
difference is with TiDi your ship and actions will start happening pretty much immediately, showing that your button mashing hasnt been in vein, and that you dont need to keep button mashing for the next 2 or so minutes. this = better server performance = better gaming experience for all!
Originally by: Heavy MG
Why doesn't CCP implement a system that automatically loads a node onto an empty cluster/server when the users reach a certain limit? This system would always be dedicated, and you could have more than one. That way things would work normally, call it "automatic" reinforcement.
because currently thats not possible unless you disconnect every client/player on that server and swap it over before any1 rejoins the game. CCP believes that to be immersion breaking and in some way unfair. so if you know a fleet fight is going to take place in a system and between now and then there is downtime you can fill in a Fleet Fight Notification Form, which will swap that system and a few of the surrounding systems onto a dedicated server.
to be fair ive been in that situation coming out of downtime on a non-reinforced server and lag became unbearable with everyone in system trying to rejoin a variety of fleets, along with loading grids and starting fights. it was absolutely appalling.
joining fleets in that situation i believe caused sooo much lag on the server... could be another important area to make server requests more efficient btw! CSM Prop 1 CSM Prop 2 |
Ralitge boyter
Minmatar
|
Posted - 2011.04.29 10:58:00 -
[236]
Im sure I'm not the first or the last to say this but what about Jita??
I mean time slowing down there because it is always over loaded is maybe not such a good idea... how will this be caught and dealth with before people end up with slide show Jita going in slowmotion ------------------------------------------- Should you disagree with me, well I guess that is because I disagree with you. If you have a problem with that please feel free not to tell me. |
GeeShizzle MacCloud
Caldari
|
Posted - 2011.04.29 11:42:00 -
[237]
Originally by: CCP Veritas
Any location node (server running space stuff) will be capable of being dilated. That said, Jita hasn't come close to 100% CPU since we changed inventory to use sets. Sooo...Jita will continue to be just fine.
CSM Prop 1 CSM Prop 2 |
Cybele Lanier
Amarr Viziam
|
Posted - 2011.04.29 12:46:00 -
[238]
Originally by: Heavy MG I don't see the difference between everything moving slowly or being stuck frozen. Either way things take forever to clear out.
The problem with lag isn't commands taking a long time to happen, it's commands getting lost in a fashion that may as well be random--so skill is irrelevant if your fleet can't respond after jump-in, but the enemy can. If responsiveness is there, then skill becomes a factor once more, which will hopefully make a big difference to enjoyment. --------------- ""Minimum collateral damage" and "Entire star system" do not belong in the same sentence." |
Drake Haywire
|
Posted - 2011.04.29 16:12:00 -
[239]
Have you guys looked into using your Random Access Memory as storage? It's being used to great success in experiments. Obviously, if most if not all of the database is no longer necessary the information will be more readily available optimizing those tasklets that require information, not to mention it will make your servers more energy efficient.
|
Bladacticus
SOL Industries Black Thorne Alliance
|
Posted - 2011.04.29 16:15:00 -
[240]
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.
|
|
|
|
|
Pages: 1 2 3 4 5 6 7 [8] 9 10 11 .. 11 :: one page |
First page | Previous page | Next page | Last page |