Currently, the available WorldProvider interfaces only allow blocks to be updated one by one.
The WorldProviderCoreImpl class has two setBlocks functions for batch updates, but these haven't been implemented yet.
Updating blocks one by one led to performance issues with the CA Liquid system. The CA Liquid system commonly updates a large number of blocks in a small area. With the normal setBlock function, Terasology will place a block, recalculate lighting, place another block, recalculate lighting etc.
I solved this issue with a hacky batch block updates that just ignores lighting altogether. This decreased the CA update times by a lot (factor 100 IIRC).
A proper implementation that runs the lighting update once, after all blocks have been placed would of course be preferred, but I ran into a few problems with this.
When a set of block updates is provided to the system:
I also would like to propose general setData functions to accompany the setBlock, setLiquid and setLight functions. These setData functions would take an extra argument to specify to which data layer the data will be written. My guess is that this would make it easier to implement the batch updates for all layers and would also pave a way for additional (mod specific) data layers in the future.
The WorldProviderCoreImpl class has two setBlocks functions for batch updates, but these haven't been implemented yet.
Updating blocks one by one led to performance issues with the CA Liquid system. The CA Liquid system commonly updates a large number of blocks in a small area. With the normal setBlock function, Terasology will place a block, recalculate lighting, place another block, recalculate lighting etc.
I solved this issue with a hacky batch block updates that just ignores lighting altogether. This decreased the CA update times by a lot (factor 100 IIRC).
A proper implementation that runs the lighting update once, after all blocks have been placed would of course be preferred, but I ran into a few problems with this.
When a set of block updates is provided to the system:
- what should happen if one of the updates fails?
- Just continue with and return failed updates?
- Stop further updates and return failed + remaining updates?
- Revert all changes made and return false.
- how would you tell the lighting system to update a set of blocks/region?
I also would like to propose general setData functions to accompany the setBlock, setLiquid and setLight functions. These setData functions would take an extra argument to specify to which data layer the data will be written. My guess is that this would make it easier to implement the batch updates for all layers and would also pave a way for additional (mod specific) data layers in the future.
