Game Optimization Suggestion

[hinkhenk]

As of building very large structures with the symetry build planes, if you are to copy very large areas the game chokes and if you have insufficient memory, the game will crash, this we all know.

My MAIN suggestion would be a Block Que.
How it works.

By default i think the game can handle 128 blocks her second as it creates it(not entirely sure)
With a block que, if building something bigger than 128 blocks, this will built in succession instead of all on the same time.
This way spawning very large blueprints into the server will not freak clients out and lag them out.

With this there is the fantastic oportunity to make an animation for spawning in a blueprint, such as adding "build ships" that with an ai, can "build" the blueprint as it is made.

If it takes a while for a blueprint to be built, i dont think anyone would complain if they see a ship flying around and is acually building it.

 

[Valiant70]

As of building very large structures with the symetry build planes, if you are to copy very large areas the game chokes and if you have insufficient memory, the game will crash, this we all know.

My MAIN suggestion would be a Block Que.
How it works.

By default i think the game can handle 128 blocks her second as it creates it(not entirely sure)
With a block que, if building something bigger than 128 blocks, this will built in succession instead of all on the same time.
This way spawning very large blueprints into the server will not freak clients out and lag them out.

With this there is the fantastic oportunity to make an animation for spawning in a blueprint, such as adding "build ships" that with an ai, can "build" the blueprint as it is made.

If it takes a while for a blueprint to be built, i dont think anyone would complain if they see a ship flying around and is acually building it.

I had a similar idea to deal with excessively large edits in build mode. With a queue, the amount of processing power build mode is allowed to use can be controlled. Then there won't be any real need to limit the selection/copy/paste size.

As for blueprints, I think when shipyards are fully implemented, the ships will be constructed over time anyway.

 

[Criss]

I wouldn't be surprised if it somehow already did this. Rapidly placing and removing blocks will place and destroy them in rows. Very much like what you described.

 

[Monchoman45]

This is doable, but it's not the be-all end-all you might think it is.

First things first:

Then there won't be any real need to limit the selection/copy/paste size.

There are tons of reasons for this, and they aren't all related to lag. For one, even if you buffer things as OP suggested, I should under no circumstances be allowed to try to place a 1mil x 1mil x 1mil cube of anything.

Currently, if I place a 50x50x50 cube, the game will place all 125,000 blocks in that cube within one frame in single player, or within one tick in multiplayer. OP is basically suggesting time throttling, which would mean that instead of placing all of those blocks in one frame, they would be split up over many frames. 128 per second is a pretty low threshhold; I don't know how much work goes into one block placement, but you should think more in terms of 4096+ per frame (depending upon how good your processor is). Picking a finite number is probably a bad idea anyway, ideally it would just do whatever it has time for; but in any case, you don't really gain anything.

Your only real leg up in this is that you won't ever freeze the window by placing a metric assload of blocks. That's nice, and it's a nice polish feature, but you still have to spend all the processing power to place those blocks, so you don't gain any time - in fact, you actually lose some time for relatively obscure technical reasons. You still have to render all of those blocks, so you don't save your GPU, and in the long run your FPS stays the same. You don't save any memory either, because to render all those blocks, you need to have them in memory.

You also introduce some problems, like a massive increase in messages sent between client and server each time the server finishes placing one line of blocks in the cube, or questions like what happens to people who move into the area of blocks I just placed before the server places them, or what happens if someone else places a block in that area.

Overall, probably not worth doing right now. Might be nice for 1.0, though. There are better optimization targets for now.

 

[aceface]

I wouldn't be surprised if it somehow already did this. Rapidly placing and removing blocks will place and destroy them in rows. Very much like what you described.

yeah i have seen simliar things

 

[Crusade]

It will visually place the new blocks, but if you notice your block count, it will climb slowly as it runs through calculations for every block. Try placing a 50x50x50 area then immediately hit 'undo'. You'll notice some strange block placement effects, that will probably break your 'undo'.

If you look in your server.cfg file, you'll find this:
NT_BLOCKUPDATE_QUEUE_SIZE = 127 //how many blocks are sent per update. Huge placements will shot faster, but it will consume more bandwidth and is subject to spamming players

If you are having trouble with large areas, lower this. If you have a beastly PC, make it a higher. Keep in mind this is a server setting, and if you are running a server it might not be a good idea to change it, as it might exclude some low-end hardware players.