EVE General Discussion

*ping*

hu?

Stop blobbing and you'l do fine.

Blobbing demands punishment and you are getting it.

This is why highsec is for the win

CCP are well aware of this and have devoted coders trying to ease this but thanks for telling everyone.

What you are doing is not PVP




TLDR; Die in a fire

The problem, surprisingly, isn't when we're actually fighting. CCP fixed that part, mostly. It's the switching systems that still sucks.

And shut the hell up about blobbing. People are not going to stop flying in fleets just because "oh, look, we already filled up 256 slots, guess I can't go--" That's ridiculous and you're an idiot if you think that.

Yep, there's some terribly expensive stuff going on at that event, and we do know what it is. There's even a plan for how to fix it. It requires changing some very touchy, fundamental bits, which means it won't come quickly, but it's a known thing.

Just how much does the idea of moving the processing of each client (ship, damage output, missiles etc) to a pr user model instead of a pr solar system model make you wail in panic?

(I'm assuming a lot due to sync issues etc)

Your tears and butthurt are what sustain us

It's something I keep in the back of my head 'cause it's the ideal way to scale this thing called Eve. For instance, the proper fix for jumps being crazy expensive is to move the processing that's going on during that away from the location binding. That's what I'm hoping to do, ya know, some day.

There's different amounts of feasibility for different aspects, however. For instance, moving the physics simulation of each individual ship to a per user computation unit calls into question how collisions are resolved, since it would be two independent simulations agreeing on exactly the same event. I doubt that would be an easier problem to solve than just having a unit of space be the computational unit for physics.

Damage application and such rides the middle ground. I could see it being possible to split that up such that each unit is responsible for the simulation of its things and it passes messages about to get things done. The communication overhead of that would need tight analysis as would the exposed interfaces. For instance, in order to display the health status of all of your targets and everyone in your watch list at the same time you'd now need to be querying possibly 20 computation units instead of one. You might still come up positive in the tradeoff, but it's not clear.

In a 'ideal' EvE Universe with absolutly 0 lag (server + client), a fight of that size would ended in a very few minutes. Logistics ships wouldn't have any role to fill.

Imagine the DPS of 100 BS in a 0 lag world... would be crazy. 150 ships destroyed in few minutes

Not sure if iracing is all that applicable, since I'm asuming the physics tick is still done for all cars on the same thread, or at least with a much higher granularity than EVE's 1 second. The lag is mostly between server and client, where the server is master.

Actually, the main problems I kept thinking of was first of all syncronization between players, and resource usage/context switching. I've no idea how much memory one user would use if one user = one process, but I can only assume it'd be a lot more than today's structure. I also have no idea how many context switches this would entail pr second, or how much that would waste percentage-wise. It's at this point that I began thinking maybe lump, say, 50 players together in one thread, and spread them around on servers that way, but I'm thinking that might be premature optimization, and doesn't solve the problem of syncronization. Having said that, if it's all structured well, hardware-wise as well as software-wise, I'm hoping that it would allow the servers more than enough spare CPU time to be able to keep each other reasonably synchronized.

As long as the synchronization issues are handled properly, I think you'd end up with it all being a net gain. I kind of wish I could actually test this. Oh well, I'd have to actually not suck at programming first, I suppose.