You just got to love the chunk system used on vehicles.

[Malacodor]

With docked reactors, you could put cores on one end and dockers on the other end. Then aiming for the nav markers was a guarantee not to hit the dockers, even with bad aim. Also, to avoid undocking you only had to protect the area with the dockers with armor, not the entire reactor. Additionally, instead of only a few blocks, each and every single block of an aux reactor is an Achilles' heel.

Taking all that into account, I think explosions in aux reactors should be reduced by a significant margin.

Does not the newly implemented system completely bypass the softcap?

Aux reactors are designed to have about the same efficiency as docked reactors. They are worse than regular reactors, but ignore the softcap. There is a softcap, but only per group, not per total block count.

 

[Gasboy]

I gotta love the way the OP is discrediting Schema's programming skills while making assumption about code he has no access to AFAIK
and STILL achieves to talk about a better way to do things w/o posting any kind of architecture nor code and using as an example a ship that most would consider a reason to ban someone off any server

I mean, obviously they know better than Schema for a game the OP has no vested interest in aside from playing it.

 

[Scypio]

he has no access to AFAIK

Srsly tho anyone knows how to decompile it if they want to. The only one downside to this is that you'll lost the name of the different variables to something like A, B, C and so on. That has been used a lot for mods developpers way back on minecraft for example.

 

[takethispie]

that's why I said "AFAIK" , he didn't say anywhere that he did decompiled the code nor does he uses some code snippets to support his arguments, also comparing an octree data structure wich is the most suited way to store data in a voxel world to ... to what ? what is a "group system" , no definitions and no explanations to get what architecture it usesor how it looks like...

 

[GRHayes]

Now you're just mincing words. It's a soft cap, but why build docked reactors? Because at the soft cap, the efficiency of the power reactors drops precipitously. Docked reactors gets around that by being able to dock perfect efficiency power to your ship. They allowed for large ships only if people were willing to have lower efficiency power. Diminishing returns and all that. They did not implement a hard cap, because if someone wants to build a large ship, why prevent them from doing so? They did not understand how creative people are, and did not foresee people using dozens of large docked power reactors.

And I have not said they did not want large vessels, they simply wanted to have an upper limit on them. Gigantism > large.

As for the aux system? No, the risk of a module decoupling is NOT worth the aux power exploding. That's a very selfish way to think. I'm going to subject people to horrible lag because I want my docked power. And the risks of losing docked power aren't as small as you seem to think. You know that people build weapons that penetrate hundreds of meters of stuff. A turret is very tempting target, but since everyone can see docked reactors, they are prime targets also. My 200m penetrating cannon is like going to shoot and decouple a few with each shot. Have you even seen titan combat? All it takes is a few shots after the shields go down, and it goes into super duper slideshow quality FPS. You wanna make a private server to do that on, good on you. You show up on a public server to do that? Shame on you.

You miss the point your 200m penetrating weapon would make even faster work of any ship using Aux Power. All you would need to do is strafe the ship lengthwise one time and it would be dead. It only takes destroying one block on an aux power group to destroy 70 to 80% of it. Considering how large power systems will now have to be to produce the same power that will put it past the ships structural damage requirement.

They could fix the lag issue with docked system far easier than fixing the other garbage I pointed out. All they need to do is not force the docked entity to become undocked unless the actual dock itself is destroyed. Second allow multi point docking. You don't have to put a rail docker near the ship core. With those to prior changes the chances of shooting a rail docker is much harder since it has no indicator on the cores do.

Either way getting tired of the game seems like every time someone comes up with anything smart the developers work at some way to restrict it. Beginning to wish I never spent the money on it.

 

[GRHayes]

I gotta love the way the OP is discrediting Schema's programming skills while making assumption about code he has no access to AFAIK
and STILL achieves to talk about a better way to do things w/o posting any kind of architecture nor code and using as an example a ship that most would consider a reason to ban someone off any server

The group and or component based models can be modified just like chunk systems.
You create a group based on do they have a shared function or attached to an entity. An entity can have many groups.
Such as your power system could form a group, the shield system could form a group, a door, a turret....

if change is called via an event handler such as did a player put a block down attached to that group or remove one. Did the group receive damage, did the player modify the group with control V or Control C...

What is here is from a very basic system. It is possible to put in block orientation damage levels and so on while saving massive amounts of space. Lets just say their is a reason real time particle physics systems don't use chunks and can have many many more connections.

class block_set
{
string ID; //entity it belongs to
Uint count;
char *type;
Point position[2]; //relative to entity core start and end positions
//allows doing runs or blocks of them.
int value; //used for primary sum value of group e/sec or capacitance or anything else
//other values can be added as needed. Names of values determined by type.
}
class entity
{
string ID; //own id
string link; //any entity it may be attached to
block_set *group;
ifChange();
//create a values list here. That way even an entity can simply become a component.
}
Stuff like testing for hits and damage works by going backwards down the line of linked entities. And testing their bounding box. Which can be calculated to a spacial coordinate by simply determining the entities position and adding the offsets for the groups. Then if a block needs to be added or remove you then break that group into the blocks that make it up. Other wise a group never gets looked at unless something changes.

Frankly, I think his programming is quite good when it comes to this game. I might not agree with every decision they make in the game and I probably will be quitting entirely with the current change. I play games I enjoy when I am not working on my own development to relax not to get frustrated. At this point this game is more frustration than enjoyment.

Considering not every programming model is taught in college and there isn't a good way to cover which models is entirely best for what is being programmed the programmers here did awesome. Just saying it can be improved. Most things can be improved. There is next to zero software out there that couldn't be improved in some way. That doesn't detract from the programmer or there work. Part of programming is who you have contact with what books you read, what projects you are exposed to. If you are given more tasks over time you learn more ways things can be implemented.

 

[Winterhome]

Oh great. This thread's still kicking.
My patience wears thin these days.

Listen, mate. If every developer listened to backseat drivers/coders, then we wouldn't have functioning software at all. I don't care what credentials you claim to have.

 

[Keptick]

But it was intended.

It was definitely not. The devs have stated multiple times that the ability for docked reactors to be used to boost a ship past the power cap were never an intended feature. That's also why THEY WERE COMPLETELY DISABLED in the last update.

In any case, unless you're on a server that turned the docked entity power transfer setting back on, your ship is useless.

 

[Gasboy]

You miss the point your 200m penetrating weapon would make even faster work of any ship using Aux Power. All you would need to do is strafe the ship lengthwise one time and it would be dead. It only takes destroying one block on an aux power group to destroy 70 to 80% of it. Considering how large power systems will now have to be to produce the same power that will put it past the ships structural damage requirement.

They could fix the lag issue with docked system far easier than fixing the other garbage I pointed out. All they need to do is not force the docked entity to become undocked unless the actual dock itself is destroyed. Second allow multi point docking. You don't have to put a rail docker near the ship core. With those to prior changes the chances of shooting a rail docker is much harder since it has no indicator on the cores do.

Either way getting tired of the game seems like every time someone comes up with anything smart the developers work at some way to restrict it. Beginning to wish I never spent the money on it.

Your first paragraph just proves you don't know how to work with the new system nor have any idea how to implement it into your ship. The patch's announcement has a great clue as to how to use it in your build.

Your last paragrph is dripping with entitlement, not to mention it's hypocritical. You have very little idea as to why things are coded the way they are, so you have no clue if your "idea" is workable in the game at this point. Please don't pretend you know what's best for the game.

 

[takethispie]

The group and or component based models can be modified just like chunk systems.
You create a group based on do they have a shared function or attached to an entity. An entity can have many groups.
Such as your power system could form a group, the shield system could form a group, a door, a turret....

if change is called via an event handler such as did a player put a block down attached to that group or remove one. Did the group receive damage, did the player modify the group with control V or Control C...

What is here is from a very basic system. It is possible to put in block orientation damage levels and so on while saving massive amounts of space. Lets just say their is a reason real time particle physics systems don't use chunks and can have many many more connections.

class block_set
{
string ID; //entity it belongs to
Uint count;
char *type;
Point position[2]; //relative to entity core start and end positions
//allows doing runs or blocks of them.
int value; //used for primary sum value of group e/sec or capacitance or anything else
//other values can be added as needed. Names of values determined by type.
}
class entity
{
string ID; //own id
string link; //any entity it may be attached to
block_set *group;
ifChange();
//create a values list here. That way even an entity can simply become a component.
}
Stuff like testing for hits and damage works by going backwards down the line of linked entities. And testing their bounding box. Which can be calculated to a spacial coordinate by simply determining the entities position and adding the offsets for the groups. Then if a block needs to be added or remove you then break that group into the blocks that make it up. Other wise a group never gets looked at unless something changes.

Frankly, I think his programming is quite good when it comes to this game. I might not agree with every decision they make in the game and I probably will be quitting entirely with the current change. I play games I enjoy when I am not working on my own development to relax not to get frustrated. At this point this game is more frustration than enjoyment.

Considering not every programming model is taught in college and there isn't a good way to cover which models is entirely best for what is being programmed the programmers here did awesome. Just saying it can be improved. Most things can be improved. There is next to zero software out there that couldn't be improved in some way. That doesn't detract from the programmer or there work. Part of programming is who you have contact with what books you read, what projects you are exposed to. If you are given more tasks over time you learn more ways things can be implemented.

I am working right now, I will get back to talk about your code later, wich btw is exactly the contrary of good or efficient.
and you dared to talk about basic understanding of programming, god.

 

[Tunk]

Wow would you look at that, I predicted the next gripe was going to be the fragility of docking two days ago privately to several people
Anyway onto what I was going to post yesterday but reconsidered, but then got convinced to post again:

I'll be brutally honest,

Though you think you are being clever here, its a subject most builders have known for literally years and any experienced admin will give the ship a good whap with destroy_entity_dock and hope the server survives (if you manage to load it in in the first place).
Like everything moderation is key.

Additionally please stop talking down to us, we can do the math (and have done more than enough testing), we've already done masses of testing, we know the mechanics, etc, and we know that yeah chunks occasionally get corrupt and fucked up, especially under extreme conditions.
Some of us have far more insight into the internals than we let on (as much as you like to brag about your credentials in all sorts of areas), as takethispie said decompiling isn't all that painful and quite a few of the alpha testers have enough chops to sort through the obfuscated code.
It seems you've only really recently discovered or considering this style of generator, considering I've been on hiatus for several months and it was a thing for several months before that you are pretty slow on the uptake.
Hell I remember when you were literally fumbling around the power calc and mechanics, and wouldn't take both experimental or mathematical proof of how it works and kept screwing up your experiments to try and figure it out yourself.
You might want to consider that in this instance that yes, you are doing something slightly stupid again and being pig headed about it.

Honestly you remind me of several customers I deal with, oh the system does X, lets take X to the extreme and do a completely retarded amount of X and complain when we completely nuke a server (not the reality since client instances are isolated, but you get the idea).
Then sit there going

when it screws up.

There's a good reason you don't see extreme ships like this on servers, that's because people like to play the game rather than crash the game.

 

[Gasboy]

Why can I not click more than one option...? Like, informative, friendly, creative, agree... they all work in this instance.

 

[takethispie]

class block_set
{
    string ID; //entity it belongs to
    Uint count;
    char *type;
    Point position[2]; //relative to entity core start and end positions
    //allows doing runs or blocks of them.
   int value; //used for primary sum value of group e/sec or capacitance or anything else
  //other values can be added as needed. Names of values determined by type.
}

class entity
{
   string ID; //own id
   string link; //any entity it may be attached to
   block_set *group;
   ifChange();
   //create a values list here. That way even an entity can simply become a component.
}

your code is missing so many things it will be very difficult to talk about it
but even without thinking two thing instantly came to my mind: frustum culling and LOD
basically you code is so freaking bad that it would be a PITA to make LOD or frustum culling work efficiently WICH IS EXACTLY WHAT PREVENT THE GAME FROM BEING A FU**ING SLIDESHOW

the fact that an octree (or it might be chunk paging, I don't remember the exact name) structure is a hierarchical subdivision make it "easy" to implement LOD :
block being subdivision of a chunk, at long distance you just take chunks of the same block and apply a texture for the whole chunk and done.

the worse part is frustum culling, with the weirdo linear list of block_set in your code (I'm not even sure *group is a pointer to an array ?) it will be absolutly awfull performance-wise because you will have to go through ALL block_set to get the blocks which are in the view cone

I can't say muchmore because there is not enough "material" to talk about...

 

[GRHayes]

class block_set
{
    string ID; //entity it belongs to
    Uint count;
    char *type;
    Point position[2]; //relative to entity core start and end positions
    //allows doing runs or blocks of them.
   int value; //used for primary sum value of group e/sec or capacitance or anything else
  //other values can be added as needed. Names of values determined by type.
}

class entity
{
   string ID; //own id
   string link; //any entity it may be attached to
   block_set *group;
   ifChange();
   //create a values list here. That way even an entity can simply become a component.
}

your code is missing so many things it will be very difficult to talk about it
but even without thinking two thing instantly came to my mind: frustum culling and LOD
basically you code is so freaking bad that it would be a PITA to make LOD or frustum culling work efficiently WICH IS EXACTLY WHAT PREVENT THE GAME FROM BEING A FU**ING SLIDESHOW

the fact that an octree (or it might be chunk paging, I don't remember the exact name) structure is a hierarchical subdivision make it "easy" to implement LOD :
block being subdivision of a chunk, at long distance you just take chunks of the same block and apply a texture for the whole chunk and done.

the worse part is frustum culling, with the weirdo linear list of block_set in your code (I'm not even sure *group is a pointer to an array ?) it will be absolutly awfull performance-wise because you will have to go through ALL block_set to get the blocks which are in the view cone

I can't say muchmore because there is not enough "material" to talk about...

Not like I am going to paste an entire engines worth of code in here.
Consider this. You are bitching about LOD when the system above can already reduce the number of vertices and polygons down.
Lets see a 100x100x100 set of the same block. I can store by providing 2 positions opposite corner to one another in relation to the core of the entity. Total vertices need 6.

Which is faster to display a single box with repeating textures or the 1,000,000 individual boxes. Even if you stuff 1,000,000 boxes into a VBO after reducing to just visible boxes then surfaces you are still going to end up with greatly more to handle.

If you are wondering how damage is dealt with.

Consider the same 100x100x100 block. Well just assume an explosion on one side destroyed 10 blocks in the center of the face as an example.
You divide it into new blocks using basically an Oct-tree. Yes, as damage increases your stored data increase but it never ever gets close to the size of what the current system uses. That is without using any compression.

As for your comment about weirdo linear lists and frustrum culling.
You missing to big points. The first is as I pointed out above I am reducing vertices and so on and taking advantage of what hardware allows.
Secondly, even if I did use the linear box system it would allow for the use of triangle strips and that will greatly improve performance.
Triangle Strips (Windows)
Primitive - OpenGL.org
That is especially true since shaders where introduced.

But let me know how simply keeping a list of blocks and representation of them that uses far less vertices is so much slower.

Not sure *group is a pointer to an array. Hmmm. It allows for the option of an array, allocation of space or preassigned space reusable space.
I did however leave out the counter for telling how many potentially are there.
Like I said I'm not posting an entire engine on here and any programmer worth anything can figure out what needs to be added and the advantages of it. I actually use that in testing people when hiring. It is a good measure of a programmers ability to understand code intuitively.

Maybe, this explanation will help. The point is you turn a ship like this into a standard model like you would see in pretty much every video game on the market. The only time the ship is looked at block level is when a change occures. Then it is simply a matter of following the change down the tree of the entity. It takes a very complex object and turns it into something much simpler and much faster to display.

 

[Crusade]

I wonder if schema can help out with this, but my understanding of it is (And i could be totally wrong);

Starmade rendering calls are done per visible segment/chunk, now I understand that Generate strips would work, however you could end up rendering extra stuff offscreen, and occlusion culling would not be usable, especially on large ships with simple geometry, also, having to recalculate an entity with complex geometry during heavy battles would be a nightmare, it would guaranteed be slower than the current system, as it has to generate the mesh for the GPU to display on the cpu, essentially recalculating a mesh every time a block is added or removed. Now scale that up to hundreds or thousands of blocks being removed every second in your average Starmade battle and imagine the performance overhead required.

Ships will only get more complicated to 'generate' with this method when you get interiors involved too, adding more geometry to account for interior spaces.

And what of damaging a ship if the entire side of it is 2 faces? What blocks would be damaged? How can you accurately and quickly get an impacts location?

Now there is some merit to using GS, however from experience, Starmade already has one of the most efficient rendering systems out there.

I did a comparison, viewing a 1500m star trek ship in Starmade gave me easily 120+ fps. With 256 textures, 200,000 segment limit and all that fun stuff.

I then exported the model from Starmade, and imported it into blender, even with backface culling on, and running in openGL mode, it was hovering around 7-11 FPS.

In short, the current chunk/rendering system is good. If you're having issues, increase memory assigned to the game, or lower some memory intensive settings. I recommend a 2gb or greater video card for Starmade, and 4gb or more of ram assigned.

Peace out!

 

[GRHayes]

Your first paragraph just proves you don't know how to work with the new system nor have any idea how to implement it into your ship. The patch's announcement has a great clue as to how to use it in your build.

Your last paragrph is dripping with entitlement, not to mention it's hypocritical. You have very little idea as to why things are coded the way they are, so you have no clue if your "idea" is workable in the game at this point. Please don't pretend you know what's best for the game.

You have figured out it takes about 9900 blocks to get 193 per block with the the Aux system right? Verified today just before writing this.
If you make smaller groups you won't get as much power per block and will waste much much more space.
You know explosions from the chain detonation are proportional to the size of group?
If you want to protect the rest of your ships internal structure the cube shape provides the least amount of risk over any other shape.
You understand why that is right?
I even worked out the block spacing, armor ratings and so on needed to protect other structures and groups.

Best of all destroying one block in each of two groups today testing resulted in only 2,222 left over from 19,800 blocks.

My favorite part came when i made 3 groups and only shot one. When it was destroyed mostly but the other two groups were intact the ship overheated with 66+% of its structure still intact. Even better was I couldn't reset the core. While it is still visible it appears to count it as destroyed. You could even move through it. However, if you went to other parts of the structure you couldn't pass through and it followed its visual shape exactly.

block count / Power on
1000 / 38715.6
2000 / 115220.9
3000 / 237103.6
4000 / 407887.5
5000 / 626804.2
6000 / 886500.3
7000 / 1170925.1
8000 / 1456055.4
9000 / 1715461.8
10000 / 1929032.9
9900 / 1910060.1

explosion size proportional to the size of group you make groups below 3000,6000,12000 blocks

[doublepost=1474525214,1474523140][/doublepost]

I wonder if schema can help out with this, but my understanding of it is (And i could be totally wrong);

Starmade rendering calls are done per visible segment/chunk, now I understand that Generate strips would work, however you could end up rendering extra stuff offscreen, and occlusion culling would not be usable, especially on large ships with simple geometry, also, having to recalculate an entity with complex geometry during heavy battles would be a nightmare, it would guaranteed be slower than the current system, as it has to generate the mesh for the GPU to display on the cpu, essentially recalculating a mesh every time a block is added or removed. Now scale that up to hundreds or thousands of blocks being removed every second in your average Starmade battle and imagine the performance overhead required.

Ships will only get more complicated to 'generate' with this method when you get interiors involved too, adding more geometry to account for interior spaces.

And what of damaging a ship if the entire side of it is 2 faces? What blocks would be damaged? How can you accurately and quickly get an impacts location?

Now there is some merit to using GS, however from experience, Starmade already has one of the most efficient rendering systems out there.

I did a comparison, viewing a 1500m star trek ship in Starmade gave me easily 120+ fps. With 256 textures, 200,000 segment limit and all that fun stuff.

I then exported the model from Starmade, and imported it into blender, even with backface culling on, and running in openGL mode, it was hovering around 7-11 FPS.

In short, the current chunk/rendering system is good. If you're having issues, increase memory assigned to the game, or lower some memory intensive settings. I recommend a 2gb or greater video card for Starmade, and 4gb or more of ram assigned.

Peace out!

There are already methods developed to deal with rendering and not rendering visible parts of a ship. See Binary space partitioning or BSP trees and Oct-trees.

Lets take a weapons hit and look at it.
Both systems would determine direction and point of impact. There is no difference there.
The current system would look at what block is there and get its data.
The discussed system is under a much lower load. It has a minor amount of work to do that is one time generate a list of the blocks in the group. It is essentially for or while loop. Then both systems calculate damage against the block and if there is any punch through and if any other blocks are damage. At the end the discussed system would rewrite the blocks storing the new shape.
The difference comes in the discussed system doesn't have millions of continuous checks to do on all the other stuff and other blocks and any issue handling them for movement because it only needs to deal with the much smaller data of the representative model. So it has plenty of time to do those small fast tasks need to expand the data and restore it.

First off blender isn't fast for an engine it isn't meant to be. It is more about precision and it holds all the data in value. Secondly the exported object from this game has all the faces and vertices which blender continues to track even on cubes that are inside of blocks of cubes. If you are in the render it is using ray tracing to display the object. Depending on how man rays you cast the quality changes and how fast it renders.

If you want better comparison. Take the object you exported to blender. Clear off all the invisible vertices (I mean get rid of them and those faces. Turn all those faces that make up a single plain of one type of object into a single face. Then set the texture to repeat along it. When you are done you will have a ship with far less faces than you currently do. Then render it in a game with an engine like unreals.

This was the second model I made in blender.

Spoiler

 

[Crusade]

The preview window(s) does not/do not use raytracing, It uses openGL, and this was with backface culling enabled, face display set to solid (not rendered, textured, material or x-ray)

 

[GRHayes]

Wow would you look at that, I predicted the next gripe was going to be the fragility of docking two days ago privately to several people
Anyway onto what I was going to post yesterday but reconsidered, but then got convinced to post again:

I'll be brutally honest,

Though you think you are being clever here, its a subject most builders have known for literally years and any experienced admin will give the ship a good whap with destroy_entity_dock and hope the server survives (if you manage to load it in in the first place).
Like everything moderation is key.

Additionally please stop talking down to us, we can do the math (and have done more than enough testing), we've already done masses of testing, we know the mechanics, etc, and we know that yeah chunks occasionally get corrupt and fucked up, especially under extreme conditions.
Some of us have far more insight into the internals than we let on (as much as you like to brag about your credentials in all sorts of areas), as takethispie said decompiling isn't all that painful and quite a few of the alpha testers have enough chops to sort through the obfuscated code.
It seems you've only really recently discovered or considering this style of generator, considering I've been on hiatus for several months and it was a thing for several months before that you are pretty slow on the uptake.
Hell I remember when you were literally fumbling around the power calc and mechanics, and wouldn't take both experimental or mathematical proof of how it works and kept screwing up your experiments to try and figure it out yourself.
You might want to consider that in this instance that yes, you are doing something slightly stupid again and being pig headed about it.

Honestly you remind me of several customers I deal with, oh the system does X, lets take X to the extreme and do a completely retarded amount of X and complain when we completely nuke a server (not the reality since client instances are isolated, but you get the idea).
Then sit there going

when it screws up.

There's a good reason you don't see extreme ships like this on servers, that's because people like to play the game rather than crash the game.

The so called power issue I had was in relation to a bug that was verified by more than 1 orange on here. It was with the beams missing the 5th tick which was why the beams systems couldn't reach 80% using two beams.
Not exactly my fault when the issue is a software bug.

Or maybe you are talking about when I first tried the new Aux Power and had to do a complete reinstall because I never got the Power on Power at all. Again a bug.

Which seems to be a shit load of what I run into but hey I expect that to some extent because this game is in Alpha right.

Here is 2 more bugs I seen today.
Putting down 9900 power blocks attached to a core the values where inconsistent. You know power on Power off. 4 out of 5 they were the same. I checked the block count and they were the same.
Another bug was when I removed a large block of Aux two random ones where left behind.
Put down a block of 10x10x10 and it only showed 996 of them 4 shy.

You know what I didn't do a bug report on them. Why because in general I am sick of the attitude around dealing with bugs.
One report was simply deleted. The bug still exists 100% repeatable.

But hey tell me what you think of this bug. Can you spot what is going on by looking at the sequence of images.
Hint the only thing I did to cause those change was move my camera angle.
Maybe you can explain to me why it is necessary for the game system to reevaluate a group simply because the camera angle changed.

 

[Groovrider]

I think your ship is too big.

 

[schema]

Hey, I usually don't do this, but I have to clarify some things.

There are some things assumed in this thread that are simply not true. The chunk system is just one part of the engine and there are a lot of other systems (including group systems) layered for the game to work.

First of all: The chunk system. Why is it a good system and why do 90% of voxel games use some form of it:

• Clear Segmentation of data: A chunk is a clear part of memory. That makes for a lot faster access because you can reference it with static indices in an array. You can make assumptions to it's size and apply several data structures to it for optimization I'll mention below.
• Fast and memory efficient region systems by just indexing empty chunks, and not actually give them any real data.
• Fast referencing of single blocks needed by several physics systems as well as damage and state changing systems like logic.
• It allows for a unit of requesting and sending so that networking can be throttled to not stall.
• It is necessary for drawing, i.e. frustum culling. Else you end up iterating through stuff that is not in camera view. That is one of the biggest pitfalls in draw performance
• Lighting functions can be calculated threaded per chunk, which would be impossible with a group system.
• Fast generation and modification of octrees for rendering and physics.
• Saving and loading can be done per changed chunk.
• Physics: without the chunk system, several optimizations would be impossible. The engine makes use of octrees and Axis sweeps to minimize the problem of comparing millions of cubes to each other in milliseconds.

I'm not entirely sure which alternative is proposed in this thread, but from what I read, it's some kind of grouping system where you would combine equal blocks with equal orientation into groups. If that is the case there would be several game breaking problems with that:

• Logic: activation states change for individual blocks, and it happens often. That would trigger a group change and would need major CPU load to recalculate those groups.
• Ship battles: Again, groups are only changing when blocks are added/removed. In ship battles that happens thousands of times of a longer time period. Keep in mind that a damaged block already counts as a changed state and would invoke a group update.
• Building Style / Generation / Ship Battles: A grouping system's advantage would depend on a player's style to build. It would be strongest when doing big boxes of the same blocks. While some players do that for their system, others prefer other shapes rendering a possible grouping system slower and more convoluted. Worst case would be small system blocks of a few cubes that would be speckled across a ship. Ship battles will generate these kind of worst cases very very quickly. And using a group system would also affect the generation, because it too can generate worst case patterns.
• Comparing the rendering system to an engine that doesn't have complete editable voxels is a fallacy. Add back all the thousands of light sources of a ship into such an engine and then we will see how well that performs. The lighting is stored in the vertices and if you actually removed the vertices for rendering all lighting information in the vertices is lost. It can be solved by deferred lighting but that also has a limit of 50-100 lights which isn't enough. Deferred lighting will be added on top of the current rendering system for the closest lights to the camera in the future

If you can convince me of a better alternative that would have major performance boosts, I will use it no doubt. But I can tell you already, that it will be hard since you would probably need to know all requirements that are needed to process the game, and that is kind of impossible without looking at the code. There are a lot of things at work in this game you wouldn't assume are necessary, and all of this has to work for several situations.

But now to what it seems is being talked about: Connections (C+V) and Logic:

First of all, if a chunk isn't drawn because some kind of bug it doesn't mean it isn't loaded. It could be loaded on server and still function perfectly fine. It could be that just the lighting engine had problems processing it, so it would be on client as well as server. It's im possible for me to tell without looking at the ship itself reproducing the error.

Now, it is assumed that connections are tied into the chunk system. That is actually NOT the case. Connections is a separate data structure which actually uses a grouping system in some respect! Reason being, because it makes sense here, since there is only one state per connected block.
Logic not working can have different causes, but I'm working on improving it. I could just wait for all connected blocks to be loaded. Then you have the same effect as any other system which would ensure logic to fully work. The grouping also comes in handy when sending the C+V data to clients. The grouping system here also has several modes to minimize any worst case by also for example being able identify lots of long "sticks" and optimizing for those. There can still be some things done to decrease their size in memory, but they actually don't consume almost any processing power as is.

There is also a misconception on how power/weapons/shield/etc works. Believe it or not, but this system ALSO uses a group system. The nice thing about this system is that it can have any algorithm for calculating data. The most common one is just detecting touching groups, there are complex ones that have several requirements like shipyard, but there are also simple ones that just count the connected blocks, which goes extremely fast obviously.

It also only changes when a block gets added/removed. The process is being done by multiple threads, so you hardly notice it. It can still be notices when two capital ships with huge blocks of systems destroy each other for the reason I mentioned above on why I use the chunk system for the "basic" data of blocks.

Basically when you add or remove a system block that has any meta-value like power, an update is scheduled for the worker threads to pick up. Then the groups for the power system are changed according to that. The only thing that could be done to speed that up in the beginning is to actually flat save those groups, and load them as is, instead of doing a full reconstruction of all groups at load time.

The downside would be larger file size, and problems when unloading/saving a ship that still has ongoing threads that would have to finish first (but that's solvable). The real reason why I don't do that already is because I want the base system to be as fast as efficient as possible, so I kind of want it to do a lot to identify bottlenecks, and over the years I found plenty and made the systems at least a thousand times faster already. These problems wouldn't be obvious if I would save and load it.

There is no "iteration over every block" per tick when processing any system. After having the groups the system just accumulates and calculates all the values like power, powercap, shield-regen, weapon power, combinations, etc. These values are then used for the updates per tick making the time taken for it O(1) or in other terms, constant!
Iterating over each block of a system per frame would be insane and end up in a slideshow with not even one frame per second, so I'm not sure why anyone that played the game would assume that I would do that...

The bugs of this system are still present when sometimes a signal gets fired while these groups are still in the process for first generating, it is possible for it to be "eaten". This was the case for the rail speed controller for example, where even if you put a rail to 0 speed, loading the structure up would move the docked ship that was placed on that 0 speed rail. This is because when checking for that rail's speed, the attached group would not be done calculating and report that the rail actually had speed (the default). This bug is however solved in the last version by just waiting for the group before making any decision.

There may still be similar bugs left, but those are solvable in the same way.

By they way, the reasons why planets are currently loaded slow is because of some missing optimizations on it, but I can't get into detail too much about it, because that would reveal too much about planned stuff in progress.

The reason why shift+v looks like it does is purely to calculate the touching blocks, and it is done on client. It has no impact whatsoever on how the game works.

If you have a bug, please report it. I'm not sure why your previous report was deleted, but usually there is a reason behind it.




I hope this clears up things a little bit.