- Dynamically generated all solar systems in the universe using actual supercomputer-run disk accretion models. This means every solar system was formed the same way actual astronomical ones are, and no system is artificially held together by anything that would not work in real physics.

actually this is not true.

there are inconsistencies in the planets types / size / orbits vs the stars (the stars themselves are not valid in fact, between their actuall size vs type).

if you stick to the model, physics say NO (wrong orbit for a temperate vs the size of the star and / or star type for ex.)

if you stick to the datas, physic also say NO (or some planets should then be INSIDE of the star they are orbiting)

so, while i agree to believe they actually used a valid model, the datas associated, whether used for modeling, or in the various infos are not coherent with said model

This is why not:

http://oldforums.eveonline.com/?a=topic&threadID=876274

Pasted here:

The key point is a chaos-theory equation system of potential spheres of influence for every actor in a space. Essentially the algorithm goes something like this:

1) Begin server frame.
2) For each ship, calculate a sphere of possible client interaction based on the ship's dimensions, weapons systems, visual range, etc.
3) Using chaos theory equations of possible changes in a ship's behavior before the next time slice, fractally extrude out a set of event cylinders (with hemispherical caps) of the ship's possible influence before the next frame, within the 3D space.
4) Loop through the generated event cylinders and look for intersections. Lump intersecting masses together as "causality bubbles." Sets of events that could potentially influence one another.
5) Rapid cache out the causality bubbles as separate sets and defer the simulation of each bubble out through microtasklets in Stackless Python.
6) Send only the information relating to a player's intersected causality bubble/matrix to that game client. (Dump client's simulation state from pervious frame in lieu of the server's state if they disagree.)
7) Allow the client and server to run the simulation of that causality bubble in parallel. Continue the simulation on the client to make it appear seamless.
8) Yield to other causality bubble simulations in DESTINY and Sleep() for 1000ms.
9) Download any input changes by the ship's pilot from the client at the end of the server frame. As ships do not respond to inputs instantaneously in EVE, this is fine.
10) Push that input into the force equations in the physics simulation for next frame.
11) Push the causality bubbles' simulation result to TRANQUILITY, the actual server Main() process.
12) End server frame, loop while the execution context has not received a shutdown signal.

This prevents you from encountering a runaway O(n^y) algorithm of every ship in a solar system potentially acting on every other, and by only sending updates to clients based on that client's ship's causality bubble, it allows the game to be played on only dial-up modem speeds.

The only downside is in large space battles, in crowded spaces. In these scenarios, the intersection of extruded causality cylinders tends to encompass the entire system. This ship can influence this ship which can influence these ships which influence... etc. So the partitioning of simulation afforded by causality bubbles goes away. They tossed out some similarly awesome-sounding ways to fix this, that are in development, but I'm not allowed to talk about them.

Other really sweet things they did:

- Dynamically generated all solar systems in the universe using actual supercomputer-run disk accretion models. This means every solar system was formed the same way actual astronomical ones are, and no system is artificially held together by anything that would not work in real physics.

- Originally, the random seed to generate the EVE universe was taken from the server's Epoch Time at the start of the universe generation. The guy in charge decided, the night before launch, to regenerate the entire universe at the last minute with the seed "42."

- The location of solar systems relative to one another were modelled after cellular cohesion equations - the same thing that makes gold deposits form, blood vessels to grow in your body, and sets the pattern of the universe filaments as seen in the Cosmic Microwave Background Radiation.

For people interested why this is very complicated math without understanding all the terms mentioned here it is very nice to read up on the N-Body Problem.
It is actually quite fascinating that simple gravitaional interactions start becoming unsolvably difficult just past 3 objects and simulation systems need to develop quite elaborate algorithms to do approximations.
Adding bodies can increase actual complexity quite a lot quicker then just O(n^2).
Doing the same thing twice as often though is quite trivially twice as much calculation per unit of time.

Doubling the calculation frequency is a linear progression... Pay more attention in class.

I definitely agree this should happen for non-giant population systems. Drone control since the AI patch has been a ***** because it takes a second for your drones to react.

not only drones, it happen more and more often that you activate a module and it take a second more to actually activate.

when this happen on a gate, where you try to point something, you succesfully ock, you are in range, but the module just doesn't start....... or some odd times, it cycles, but you don't have agression and the tgt still warp out .
no stabs involved, talking about shuttles or hictor focus point, also occurs with regular point vs regular ship but then, the wcs is a possibility so hard to tell (well, i'd say if cycle + aggro timer => wcs, if not, server fail).

tbh, this is infuriating, to actually point something and see it go anyway because of this tick crap

point should apply on same tick as lock if preactivated, you lock it with preactivation, point is applyed 100%

Have you noticed this more since Rubicon 1.1? I remember thinking that there was a twofold delay although the module was preheated ... maybe it wasn't "just me being tired."

The resulting calculations are not. When you have to relay the information (say a change in a ships vector due to a double-click in space) you have to transmit that to every other ship on grid. It is precisely n^2 increased communication over the network.

Also; drop the attitude.

Have you noticed this more since Rubicon 1.1? I remember thinking that there was a twofold delay although the module was preheated ... maybe it wasn't "just me being tired."

Porting from Python to something that can do multi-core work a la Red Hawk would basically be Eve 2.....they would be starting from the ground up with a completely different environment.

That's if you increase the number of pilots / entities on grid. Not if you double the frequency of calculation.

Doing the same calculations for one tick now, and then doing it again in .5s or in 5 minutes will use the same amount of processing power for the tick.

Python can do multi-core processing just fine if that's how you program with it.

CCP has said this is impossible.

without a complete base code rewrite.

ftfy.

Nothing is impossible. It either isn't worth the effort/money or we simply don't know how to do it yet. In this case, not worth the effort to dedicate the entire staff for the year or so required to make it happen.

Python yes.... There still working largely with slack-less python. While in there server cluster they have anywhere from single core to multi core and multi cpu systems, Slack-less python runs everything single threaded... You can spawn micro threads inside of a slackless python environment which is what Tranqulity does but its still running off one core of any given system literately the system would burn out a single core of a processor without touching any other core. During Incarna they were and did Carbion engine and were working on carbon io to address slackless python issue's and allow the servers to run on true multi thread and multi processor hardware.. No idea how far they are into this when you take old code and re write it into newer eco system programming differences crop up stuff that used to work will have issues.

Even if they were to migrate to a new version of slack-less that supports Multi core multi threaded or PyPy you still have the issue alot of your code needs completely re written. Even if its the same software... Newer versions bring great features sometimes quality of life but older stuff does break.. That is the nature of programming.

The resulting calculations are not. When you have to relay the information (say a change in a ships vector due to a double-click in space) you have to transmit that to every other ship on grid. It is precisely n^2 increased communication over the network.

Also; drop the attitude.

Just Google slack-less python. and read about it :P Fundamentally its actually really good.. CCP's issue is there still running largly versions that dont have multi cpu and multi threaded support.. (hardware level)

Cheers for all the informative replies! Learned alot from it.

The answer to the thread title is ugly. Bugs would be introduced, performance would degrade, for a marginal improvement that only insta-locking legions and thrashers would notice.

It is stack less not slack less...