-Validated-

http://starmadedock.net/threads/block-count-is-off.21446/
You can find the ship here. And image proving the count is off before saving. Second ship worse. off 12%.

-Confirmed-

-Confirmed- in Dev.
Create a core and build up. pay attention to the height dimension. I built using 10 at a time and thirty. If i remove the blocks the difference is left, with nothing to remove.

Apparently, if you restart the game it fixes itself, and if you save it to Blue Print it also fixes itself. tab-f6 will also fix it.

Appears to be fixed.

In T753#53404, @lancake wrote:

-QA Testing-
Tried the steps to reproduce and failed to do it, fix confirmed.

Agreed. Good for me too.

Just tested it myself still exists in current version. If you need I can provide screen shots or video as proof.

We will most likely need the exact steps to reproduce written down as step by step list.
Getting a way to reproduce it, will usually lead to a way to fix it.

• Andy

I set the block size you can set down at one time to being 100 length. I then set down 100 blocks attached to the core. I then set down a second set of 100. I ran along it checking with the yellow box to see if and where the blocks could be place about 20 or so blocks from the end the yellow box disappears and you can't connect any blocks to the power blocks that are visible.

The part of code that handles the visual part of the block is working the part of code that initializes the block data seems to be what is failing. In short you can see a block you just can't connect to it.

Well, there is a quite large range where you can see and connect blocks, but not see the purple boxes (for performance reasons).
Then there is a range, where you cant connect to, except with shift + v by going through a group recursive.
The idea is to prevent accidental links to blocks very far away and you may not even notice.

I'll see if I can give a better description. I put down the first row of 100 power blocks and move to extend that row. I put the second set of power blocks down and it places them you can see them. But if you try to connect another block to the end you can't it doesn't give you the build indicator box(yellow). Instead if you go down along the row of blocks flying beside it you will see some place around 70 for example the build block disappears. However. I found if you attach a block to that number 70 it will fix the remaining blocks as well. So what I end up doing is connecting a block on the side of the last one I can and remove it then go to the end and attach the next segment of blocks.

To make it clear I am referring to the yellow build indicator and only being several blocks away.

That said, the distance or range check you are using could account for a number of other issues I seen in the past. I haven't checked if they still persist or not. I put a bug report in on an issue with large weapon systems recalculating chunks when the camera moved or I went to fire it.
I also put a suggestion in precisely because of this type of stuff to abandon the chunk system and use a grouping system it is more efficient and less bug prone for stuff like this.

Considering that you are doing this range test and the issues in the past. It would appear you are recalculating chunks not just when a change is triggered but pretty often or regularly. If it was me the only time a system would be rechecked is if an incident or event happened that could change it. Such as someone adding a block, removing blocks, damage, regrouping. Other wise it is wasted CPU time.
It would be a million times faster to pre-calculate the group to a given shape and determined output and store it rather than recalculate continually.

The range test is only for the build mode focus, and allowing a defined sphere of influence. Plus limited total amount of those purple boxes.

See, there are other things coming in that build box position and block placements.
If you place a number of blocks, they get placed immediately on your client side, the server then processes a queue of those block operations in reasonable (work-)chunks and updates those placements.
You may notice this in an extreme form, whem you place 2-3 chunks of 10x10x10 in full symmetry.
You notice all block appearing and then after roughly 2.5 seconds they vanish and pop up in small groups.

The same thing happens in small scale, to prevent building operations from lagging the server and influencing the overall response time, so rapidly building does for sure put your client and server partially out of sync.
But that is not really an issue, unless you hit the case where you remove blocks on your client, that do not yet have been placed on the server side.

I think I remember the other bug with large re-grouping and suggestion.
Its not that easy, groups have then a scaling issue, in theory we have a fast grouping system, this is used for most general access methods, but while building or fighting, its absolutely needed to have a special care to keep the "shortcut lists" that only work with the controller and module index, to be in perfect sync at all times, and this is indeed done only on change/edit actions on the raw-blockdata.
There are additional checks on loading ships from blueprints or other sources to prevent various ways for exploits.
This is however completely leaving the frame of this bug report.

So if your camera moves beside blocks and they change, the camera is for sure not the cause for the change.
There may be a newer state on the server, that has not yet been synced for various reasons, and then sync as "closer = higher priority for update".
Looks pretty much like this is the real cause, or some corrupted client cache, but this should possibly only happen once and is not reproducible.

The current bug with the power being placed in rows doesn't change with the camera movement. The state of the blocks that won't allow placement doesn't change until I set a block on the nearest blocks to the ones that won't work.
In short I put down a row of 100+ another 100 blocks.
At about block 170 and above I can't attach anything else to them.
So I connect a block to 169. That triggers the system to look at what else is attached and initialize blocks 170 to 200.
I can now connect to the blocks 170 to 200. I can set it so that I am 1 block away from these blocks when I place them down and it still happens.

I can understand the issue the server only updates so many blocks at a time. However it is like it simply forgets to ever bother updating those.
The closest I can figure is that in this case you created a number of tasks to initialize the blocks. Some how the final one isn't ran.

You just mentioned it only is in effect in build mode.
Only one issue with that. Lets look at the shift V issue. You hit shift V and it keeps changing stuff adding stuff in taking stuff out because of range and simply moving the camera during this time changes range.
If it can't get the correct set of blocks entirely linked in build it won't be linked when it comes out of build mode either. I saw that issue first hand in the past.

I'm assuming the "shortcut list" is used for stuff like determining damage faster and so on. There isn't a reason that can't be done with a group based system. Honestly, even a vector could be used and you could still maintain a shortcut list.

If you are wondering what a performance difference you could have.
https://www.youtube.com/watch?v=J62z_7JaYMw&ab_channel=AtomontageEngine
His engine doesn't use a chunk based system. I talked to the developer himself and asked. Pretty open guy.