EVE Information Portal

As good as this would be, I've never once seen an actual system proposal where the correct answer isn't still to blob up and hit each group of defenders/attackers one at a time if they split up.

The question is, could people create a "bonus lag" fit with 15 drones? Call it crawlcat and slowdown the node more?

You still need an objective to shoot and it will have a timer to prevent people from using the other side's weak TZ to plow through countless systems...

How about many battles over a long timeframe? This system switches if over the last 72 hours (or 1 week) X number of objectives points have been gained. You attack your opponent's weak timezone, and they defend in their strong timezone.

Again given the right setup this is a possible solution.

It had been stated in a previous devblog that carriers were supposed to be anti-subcap machines. I.e. IN current balance sentries. Removing normal drones is all well and good if you make fighters not completely useless against subcaps and not die when sneezed at by bombs.

Unavoidable O(n^2) things don't exist. Certainly not in a game. You can always optimize and compromise to avoid them.

So what can you do to avoid these n^2 problems? How about turning off collision detection (except with POS force field, for example) when TiDi is above some limit? I'm assuming you do not do collision detection with warp bubbles already unless warp attempt is actually initiated.

Everything else in EVE is not O(n^2) complex since there are limits - lock limits, watch list limits, etc. Because those limits exist, interaction complexity should not be O(n^2). Network traffic may still scale at O(n^2), but that can be managed and optimized at other nodes, not grid node (for example, I don't care if ship at 100km updates its position as frequently as a ship at 15km)

The only event that a client needs to be told is when the ship dies. Player X does not care that a drone is orbiting player B, especially when drones are not visible to player B! Sort and compromise so things scale. Send aggregate updates to clients that actually need to know about sum of events, not specific event. Player X does not care that Drone 123 hit for 5 dmg and Drone 154 hit for 20. It only cares that Player X sustained 25 damage in a given tick *iff* Player X is either locked by player B or is in Player B's watchlist. If Player B does not lock player X (and not in watch list), then Player B does not care that player X sustains damage.


There is no need or reason to be able to see (or be notified of) drone fire, laser fire, nos effects, etc. when there is TiDi on a server. Simplify and compromise algorithms so you do not have O(n^2) under TiDi.

No not a single deployable. Basically everything stays the same, but they just lose the 1 m/s movement attribute they currently have. This means a whole lot less calculation work for movement + all the broadcasts of said movement to every client connected.

Essentially this turns them into stationary turrets (which was the designed purpose I think), nobody is going to miss 1 m/s movement. Turning them into deployable structure would be nice because they can benefit of the new code (and devs that actually know how that code works), but that wasn't part of my initial brainfart ;)

I would like to ask a question regarding drones- Is one players group of drones treated as one entity or 5 individual entities (25 bandwidth?

If the latter, then wouldn't it be better to rework the drone system in a way that only allows people to launch 1 drone but maintains the performance of a group of drones?

Allright, post-nap replyathon!


To someone already on grid, nothin'. They hurt a bit to someone coming on grid, which is why massed container spew on Jita 4-4 is unhappy and we hurt people who do that.


Yeah, a separate drone setting for that makes sense to me. I know I'd use it as a player for sure.


Yes. Removing their desire to approach and orbit would reduce the amount of messages they generate.


I haven't tested it specifically, but if there is an increased load due to their inventory I doubt it'd be directly because of multiple bays. Under the hood it's just one inventory with stuff identifying which bay it's in.


No, it doesn't. The modifiers from skills and such are already set up they just get picked up by the new module. I don't expect refitting would cause much load but I haven't tested it.


Two reasons:
- We've only got one machine of that kind, so 4 nodes to use. Jita takes one, so there's 3 left for handling reinforcement requests
- A vast majority of days have no requests, so our most powerful machine is 3/4 wasted.

Fixable things of course. The second is yet another thing to prioritize vs everything else on Gridlock's plate ;)


I honestly don't know. It's entirely possible that the node would have needed to be nearly paused in order to keep up with all the non-time-scale load, which is Kinda Bad. Also, when the tick finally did advance, there'd be one helluva lot of processing to do for both clients and servers. That would not be fun.

Thanks for the answers. I think it might be worth looking at the refitting issue as it does seem to cause lag (and that would be increased due to the mobile depot being very popular) just to confirm. But I appreciate all the work you're doing on this issue and that you're taking the time to answer all these questions.