EVE General Discussion

It's not just a matter of "oh the code is old." It's not a trivial problem to successfully run fast simulations on the scale EVE does.

Trying to put operations whose results have to be assembled in exactly the right order every time in real time onto different threads causes problems. Namely that they either get assembled in the wrong order sometimes, or the main process has to wait for one of the other threads (for one of any number of reasons).

Large scale simulation aint easy. That's why most sane people do large scale simulations slowly, and just take a nap until the results are ready.
CCP, being known for their achievable goal setting, decided that it was more interesting to make sure everything happens fast enough that we think we're playing a spaceship video game rather than the 1 second per round play-by-post submarine simulation we're actually playing. Of course, the pretty GUI skin doesn't hurt that illusion.




Incidentally, I think the OP's proposal of a million character cap on each system is perfectly reasonable. At least for now.

I don't think it's that hard if you partition your sets correctly. The issue is you have to build your architecture around doing it. But more importantly, you shouldn't be doing each operation with a python script.

More to the point, if you can do a particle simulation like this with half a million points, in real-time, I don't see why you can't design an architecture to execute a game update for that many players in real-time. It's a 3 step process: (1) You queue operations bounded by a given time, you feed those operations in a useful form either to compute data structures, (2) You execute compute shaders to process the data, (3) You take your results and break them out into a suitable form for serialisation (database) and transmission (network).

The problem is that we're dealing with a several-thousand-will non-deterministic system that requires a lot of dynamism in how those sets are set up, and it's not hard to imagine a situation where the set-up takes more time than it saves to distribute the final workload among the sets.

It's no different to actual physical simulation. You split it into broad phase and narrow phase. How you do that depends on your rule set. The spatial subdivision (for collision checks) is obvious of course, but there are other classifications you could hash. Regardless, it's not an intractable problem or even all that hard to do, it's just that you have to have built your architecture around doing it and I don't think CCP have.

Copying the Pasta doesn't make it less spammy. Why don't you try actually addressing the fact that your proposal would guarantee a risk-free defensive victory every time?


Even if I can only muster an 800 man defensive fleet, your 1000 player cap proposal has guaranteed me a 4 to 1 advantage over the attackers. Just. For. Showing. Up.

Null Sec in its current state only benefits the select few at the top. Renter income is the only real reason why to fight to keep null / Sov going. There is no other group in the game that will tell you that fighting in Tidi/ node crashing fleet fights is ok. Its not..


CCP will not ever rewrite any sort of Code to fix tidi / node crashing. It can't be done sorry

By limiting the number of pilots to a system will make it so if you want that system camp it 24/7.

There are only a few people in the game that have any sort of benefit to any fight over 500 vs 500 anyway. Why do it ? because you have the toys too.

The longer CCP allows this type of game play to go on the worse it will get. People are not ganing less SP.

You see many many non zergy, node crashing/ laggy groups with EVE either renting in Null or wondering about how they too could gain SOV.


The days of Mega / Zerg fleet fights are dead the game can not handle it.


Again who is it that benefits from the mega Zerg / client crashing fights ?

What would be more fun 1000 different people with SOV or just 3 groups that casue the game to break in so many ways

How so? And how does limiting the presence in null to only those who can lock up a system in any way help resolve this supposed problem?

What do you base this on?

And what on earth makes you think that this is a good idea? It only means that it will be impossible to attack the incumbents in null, which doesn't seem to solve any of the problems you're seeing — only inflate them and make them systemic.

How do you explain the fact that they happen on a regular basis, then?

So, again:
• In what way is nullsec broken?
• How does giving large coalitions an unassailable stranglehold on all of null open up more of null?
• How do you propose to ensure that null is opened up without giving massive advantages to the established players?
• Why are you proposing a solution that lets fewer people play in null?
• What makes you think that anyone is benefitting from node crashes (where everyone loses) but won't benefit from poplocks (where one side automatically wins)?

Let me Break this down nice and simple for you, if it helps you can read it slowly and out loud...

Currently:
PL Titan gets tackled, pings start going out, fleets start forming. CFC is first on the scene jumping in with 250 megathrons, a bomber fleet and an overflow fleet, random lollygaggers/km whores galore, local is at 600.

PL brings their support fleet in, local is now fast approaching 900, N3 is on their way still 2 titan bridges out with a 200 man slowcat fleet + support fleet to save the titan.

CFC sees them coming and orders supers to log on, N3/PL respond in kind.

Slows arrive in system, CFC supers drop on them, N3/PL counterdrop. Gudfites are had, supers get blobbed, some supers die and then the node follows soon after.

Fight is over, people gradually log back on and get out of system/die to gatecamps etc etc. Fight was resolved as fairly as possible on a node that couldn't handle the fight.


With a 1000 player cap:
PL Titan gets tackled, pings start going out, fleets start forming. CFC is first on the scene jumping in with 250 megathrons, a bomber fleet and an overflow fleet, random lollygaggers/km whores galore, local is at 600.

PL brings their support fleet in, local is now fast approaching 900, N3 is on their way still 2 titan bridges out with a 200 man slowcat fleet + support fleet to save the titan.

CFC sees them coming and orders supers to log on, N3/PL see what's about to happen and scramble to do the same.

CFC drops 100 supers on field to lock the system, local is now at 1000.

Titan is screwed.

N3/PL go home rather than welp 250 at a time to the 700 CFC in system.

Truthfully, I think TiDi generally goes the wrong direction.

When time slows down in game, it gives pilots tons of RL time to organize more people and move them to the fight. This creates 1000v1000 battles, which is good publicity, but will always be abused and pushed to the point that the system breaks (node crashes, slow-ass game play, etc).

Instead, if it is possible, speed up time instead of slow it down. As time speeds up, the time to escalate a fight diminishes. This rewards players pre-positioned to escallate. This also is self-correcting, as faster time means more people die which means less pilots on the field which results in less demand on the server.

Unfortunately, this would be extremely non-trivial to optimize. Speeding up the server adds load on the server now with the intention that the server's load will lesson as things come to a conclusion faster. There also might be some exploits this creates (suddenly you can increase your fleets dps by bringing so many people). I don't know if this is at all possible, but it is a conter-intuitive approach that might result in better overall gameplay.

Confirming troll and/or just dumb, he's not even listening and just repeating the same garbage.