EVE Information Portal

I am slightly confused. You started the devblog by asserting that the old system was bad, because it put clusters of connected systems on one node (and intra-node jumps are more expensive than inter-node jumps). Yet you end up with a system that puts even bigger clusters of connected systems on the same node? From the pictures it looks like instead of constellations, now huge chunks of regions share the same node. Wouldn't that lead to even more intra-node jumps?

I think that a way more optimal solution would be a kind of checkerboard-style distribution, where systems on one node are geographically close together (to save the poor trio of ratters in Solitude), but not directly connected to other systems on the same node. Several nodes could therefore share the load from people jumping in and out of a big fleet battle, and the majority of jumps would be inter-node jumps.

As others have already said, the new allocation could lead to even higher load being put on the nodes in battles, as it seems now that any sort of reinforcements or auxiliary fights will directly contribute to the load of the fleet fight node itself. And this will also happen with a pre-reinforced node - even if you take the contested system out of the picture, all the surrounding area still shares the same node. Whereas in the old distribution, it is rare to even find a system whose direct neighbors are all on the same node.

CCP Prism, how much history of node usage (e.g. in terms of days) is taken into account in the mapping to smooth out its decisions? For example, if there happens to be no major timers one day and an alliance doesn't have nearly as many people in its staging, and everyone logs in the next day, will the premapper still have the historical information about recent load in the system to have mapped it effectively? Also, how does information like reinforcement timers factor into these decisions - does the mapper get skewed directly by these timers, or do you generally hope it's handled by the recent load history of nodes and explicit node reinforcement requests from player?

In addition, now that you have a more systematic (heh) load balancing strategy in place, why have static rules that separate null and empire? If there are large chunks of null and lowsec that almost never have high loads, placing those into the same node might actually be a good thing, freeing up nodes for other systems.

I guess, the real question is what exactly are you trying to optimize, because if you don't know what you're really trying to optimize, it's hard to know if you're heading in the right direction.

That's starting to sound like a Colour problem. Ultimately you want to maximise the number of local nodes without them touching themselves, while minimising the global distribution of any individual colour. This does the best to maximise the high-performance transitions while keeping TiDi relatively local to its cause. Made that much more complex by the fact you also want to load-balance the systems onto nodes as well...

Well, for one, Dogma doesn't need to calculate anything about the movement of sentries, and notifications about their movements to any of the clients.

While FBs require AI (ok, you can laugh), physics and position notifications to everyone in grid.

I'd say a totally different workload.

I am not exactly sure why would you say that. Perhaps you think that sentries don't move? They do.

That's simply not true. I can pull up an overview with sentries on it, and they move, at 1m/s. That means the server has to update me constantly with the positions of all those sentries, same as it does with fighterbombers or any other drone. Fighterbombers, load-wise and on-grid, aren't really any different from warrior IIs. The difference only really pops in when you get them following you in warp, but on grid, they function essentially the same as drones. They're bigger, sure, but they don't have special AI that drone's don't have, and they don't create huge amounts of load that sentries or any other kind of drone don't.

Devblog states tomorrow (december 4th) as deployment date. Set a long skill ;)



Talking about sentries as one of the issues for this: would setting sentry speed to 0 (or immobile or w/e), taking their motion out of the data flow, solve part of the problem cause by the massive use of them?

Prism X you are such a nerd. Good thing I know what you are talking about ;)

By the way: What about packing up and moving overloaded solar systems during runtime to a set of reserved nodes? I know this is hard to code but it can be done.

Motion prediction is a big corner cutter in client-server dialog.

The client can easily predict the movement of a sentry drone, and just be confirmed about it from time to time. Not so much about a FB - whose trajectory can change at any time.

my god... f**kin read gawd dammit!