Player Features and Ideas Discussion

For fairness new ships coming into the grid should be put in a delay queue - stretch out that warping in effect and travel time.

If you do not -- ships that that should not have had time to travel to the battle (if the battle occurred at full speed) can totally reverse the balance of forces due to arriving during dilation. You could ambush an enemy with 3 times the ships in larger better quality fits but because the battle will take 15-20 minutes at high dilation...he might be able to call in huge numbers of ships from as far as 15 jumps away.

Basically the older the delay queue, the longer the delay for ships newly entering the queue. Roughly speaking the time in queue could be computed by adding the dilation clock fraction every second to arrive at a cumulative total time since dilation began (thus 2 minutes of 50% dilation equals 1 minute hung in queue or 4 of a mere time dilation ). This cumulative total becomes a delay timer for ships arriving at that instant. Time dilation factor shows how much real time was not simulated by the server each second (25% factor says all but 25% of real time was simulated and 75% time dilation says server fell an additional 75% of a second behind, i.e. only 25% of real time was simulated).


(I posted more extensive comments to Test Server area before deciding this forum was more appropriate despite the immediacy of topic connection to current test server focus. If someone can move them here....please do.)

The point would not be moot - just attached to the wrong object.

OK then the delay queue should apply to the whole system. But I was thinking they said fleet combat grids got their own server and that the time dilation effect only applied to that server. In any case the time dilation certainly does not effect people coming from other systems.

The point being that uncorrected time dilation can result in ridiculous amount of time for reinforcement and return to combat.

But of course larger corporations and alliances would favor that side effect of dilation on the theory larger alliances and corps should always win - even if ambushed or out maneuvered at the start. "let us bring our whole corp not just the ones in the local area".

Dead concept should be burried. It causes async actions for the players. Completely wrong idea.

For example: Sudden attack. Grid takes more than 2000 players. Responsible node slows down the time.
assume we have 5 percent of real time. So we have a greate benefit. While enemy warpin(it will take 30-40 minutes)
allied fleet is gather and waiting proceed.

Remember regardless of delay queue or none, time dilation slows the rate of fire, movement and reloading for folks once in battle. *** So get used to twiddling your thumbs!!!! ***


(1) Dirk I do not think CCP plans to start time dilation if just one side is in the grid. Not sure that lag lasts long enough for time dilation to turn on if 2000 ships fire at one target. I am fairly sure you must also have significant number of enemy/target objects (ship, drones, missiles) to slow the clock. But talk to CCP about that. I have no input for that aspect.

**** (1b) So no you will not see 2000 ships from your side just waiting endlessly on the first enemies to jump into grid. You can start firing as soon as first enemy arrives - before time dilation starts. Even with delay queue, most enemies from their initial warp in group should enter within 10 minutes in the worst case and usually within 2-3 minutes. (Explained below.) And your only advantage is extra time to think and observe -- because everyone's rate of fire are slowed too (including reload). ****


Walk through of how delay queue would effect things.

(2) OK say your 2000 ships are opposing the first 20 (or 100 or whatever the number is) enemy ships to jump in. Now CCP rules say that is enough enemies to set off time dilation. You can already shoot enemies present.

(2a) Assume that the time dilation fraction now jumps to 95%. Thus the CCP server only moves battle clock 0.05 second during the first second of time dilated battle.) Yes enemies waiting to jump in start to pile up. Those arriving during the 2nd second incur a 0.95 second battle clock delay in warping in. How long that is in real time depends on how fast the battle clock runs - less than a second at time dilation 0% or 19 seconds at steady 95% dilation. Remember regardless of delay queue or none, time dilation slows the rate of fire for folks once in battle so get used to twiddling your thumbs.

(2b) You really have to arrive late to be significantly delayed. Ships jumping in at x seconds into battle can at most be delayed until a bit less than X seconds on the battle clock. So if your ship arrives 5 seconds into the battle and the intensity has kept the dilation at 95% then you jump into battle 4.75 seconds later.

(2c) Most FCs like to think that initial group ships warp within less than 30 seconds of their command. Basically your tardiness in executing FC orders to warp are multiplied by how slow the battle clock is advancing. You have to wait in queue until the battle clock advances to 15 seconds. If time dilation was at 95% the whole time that would be 300 seconds. If time dilation averaged only 20% then you wait only 75 seconds.

Fairly certain you should do some research before posting. It was mentioned gazzilion times the smallest thing node handles is a system - if it is reinforced, otherwise it is multiple systems. Dividing processes going in one system so they could be handled by few nodes - or even separate processors in a multiprocessor system - needs fundamental rewriting, and it seems devs are even not sure where to start it.

idea is bogus for so many reasons.

Let me start with a simple explaination given me by a very patient and wise player. CCP once promised that fleet battles would get their own servers and that was just around the croner. That idea has been quietly dropped (perhaps too quietly for Flame) and time dilation has been substituted. This is not because hardware is unavailalble or CCP has not figured out how to detect a fleet battle (as Flame and others seem to think). Its because in nullsec were such battles can occur there are no uninvolved parties in the entire system. Moreover, no one can say a big fleet battle is or will be occuring in a specific grid until you also have meet the conditions for time dilation. By that time its basically too late to move the battle to another server, at least under Windows.

Moving fleet battles to another more powerful server node requires a session move for every ship involved going to the specail server and bring survivors and wrecks back to the system. Session changes are by far the most costly operation possible on a server as undock and gate jumps should make obvious to anyone. Once in time dilation no star system server node will ever have the power to perform either the initial mass session changes without crashing or handle moving later arrivals. Plus ships coming into the system for battle will essentially be jumped to or from the original system node two extra times because of the separate server node for fleet battle - thus creating more opportuntiy for a system node crash and totally negating any hypothetical benefits of offloading to another node. I suppose fleet battle detection could be keyed at 50-79% of ssytem node usage so that power remains to start making necessary sssion changes early in birth of battle. But frankly that is very likely to waste power server node resources on minor system raids (see belowe how nodes might be tied up for hours even if small battles).

Worse yet there is no session change defined yet for wrecks or drones and missiles of skirmishing survivors. So either the dedicated server is tied up with a fleet battle long decided ago, until the last wreck and survivor is gone --- or a huge major expansion has to be developed to provide new game features to implement a process that can never make the game work better. Simply leaving the fleet server tied up lasts at least two hours past the true end of the fleet battle and more likely hours longer for wrecks created during low level salvager skirmishes. God forbid should someone abandon a single drone or worse anchor a container for salvage and abandon it.

Finally let us take note that sessions changes are slow because each one flows through the critical and often overloaded CCP database servers. Now let us think about a moving a battle fleet to a more powerful dedicated server. The database servers would see a mass of synchronized (initial battle members) and sustained (later arrivals) session changes which would likely slow EVE system and very very possibly crash the databases servers and thus all of EVE.

For those like Flame who think a low or high sec battle with time dilation invoked might theoretically be possible --- thus causing issues for the uninvolved -- WRONG! My sources say unconfirmed but realistic rumor says that CCP is much more likely to simply code a time dilation alternative for low and high sec that has CONCORD step in -- probably a CONCORD secret weapon that locks down all weapon fire in that low or high sec system (i.e. bypass combat processing) until fleets disperse. Its just simpler to code such a quick rule at this time rather than worry further about a twice a year (generously) occurance and waste precious CCP development time.