This basically means, that sectors won't load in right when you change it, but you will be always surrounded by preloading sectors. You will be able to see the objects (even moving ones) of adjacent sectors from your position. This feature will mark a milestone for the engine's core.
After lots of hours of work, the new version is finally in a releasable state. There might still be some bugs from the countless performance improvements and optimizations, which I might not have accounted for, so please send in reports whenever your game crashes, or you see something odd.
However, it's very complex and complicated to implement. Here are some of the problems I had to solve:
Every player effectively now loads 27 (3x3x3) sectors.
This means a lot more memory used per player on the server (not a client problem).
a lot more sectors and objects have to be able to load in at the same time.
a lot more data has to be transferred to clients, since the simultaneous "available" objects by player is much bigger. Most of the data is only one time data (e.g. not moving objects don't need updates, and the number of moving objects won't increase from this).
every object loaded has be updated, which will beat on the performance.
Clean up functions: the clean up has to be done a lot more often since more sectors get inactive at once.
Object positions have to be calculated relatively
As floating point (even double precision ) values are by far not big enough for the StarMade Universe, the sectors are used to represent a relative system. This means every sector is handled around the absolute zero, which allows for the virtual infinity of the universe. The function that has to be the most robust for the new system is to calculate the positions of objects in the surrounding sectors on the clients. For the server the relative positions don't play any role, since each sector has their own context.
relative positions also influence sector requests by the client.
Physics dilemma: To keep StarMade as modular and extensible, the sector system described above is used. Every sector is using it's own physics context to handle scalability and number limits (float/double problem).
There has to be a function for secure transitions of objects from one in the next physics context. This is one of the most complex procedures (although it sounds easy at first): Bigger Objects can intersect the sector border: what sector does it belong to? The sector that has the bigger part of it of course. But now what happens if another object in the sector which the big object doesn't belong to collides with it? ... I basically have implement some kind of "bubble" which is formed around near objects to make sure they are in the same physics context.
Here are also some bugfixes, that are included in the new version:
- fixed recycler exploit
- fixed shop sell exploit (sell negative)
- fixed credits overflow
- fixed gravity block bug
- fixed negative ship cost bug, when a saved ship gets too expensive
- fixed overflow in shield and power
- fixed that own explosion blocks are saved by shields
- fixed bug that caused for docking not to be terminated when deleting thecorrespondent docking block
- fixed 2 cores for 1 bug
- implemented more scalabe method to do inventory modifications