Random Chitchat 2018

[xoft]

A global palette will also finally enable us to implement custom blocks in plugins.

Here, have a horse

[NiLSPACE]

I love those. There are quite allot of them


And

[tigerw]

So how are we going to implement block states?

class Block
{
 string GetName();
 JsonSomething GetProperties();

 bool operator==(Block lhs, BlockIdentifier rhs);


private:
 BlockIdentifier id;
}

class Piston : public Block
{
 int Facing;
 bool Extended;
 bool Sticky;

 string GetName() { return "minecraft:piston"; }
 JsonSomething GetProperties { return {{"facing", "west"}, {"extended", false}}; }
}

...in the protocol...

Block actuallyapiston = ...;
GlobalPalette::GetId(actuallyapiston.GetName(), actuallyapiston.GetProperties()); // returns e.g. 1547

Does this introduce way too much overhead? It certainly looks nice...

Block thing = World.GetBlock(State?)(Pos);
if (thing != BlockIdentifier::Piston) return;

((Piston)thing).Sticky = false;
World.SetBlockState(Pos, thing);

[NiLSPACE]

What would the 'BlockIdentifier' class look like?

Also, just to make sure I understand this right. Instead of two arrays containing the BLOCKTYPE's and NIBBLETYPE's of a chunk we'd have one array containing only these Block objects?

[xoft]

I think it'd be better to have each chunk's section contain an array of VirtualBlockType (a number) plus a Palette object that provides the mapping of VirtualBlockType -> BlockTypeWithParams class instance.
BlockTypeWithParams stores the block's type (piston / grass / torch / ...) and parameters ("facing=west, powered=true, ..."). So if a piston gets extended, it receives a different VirtualBlockType from the section's Palette and the section remembers the new number. This is much better than allocating a separate object for each and every block in the world.

The Palette class manages the mapping - if a new BlockTypeWithParams is to be set in the section, it is assigned a new number; rather than removing a mapping when all of its instances are removed (-> holes in the numbers sequence, would need defragmenting), it should cooperate with the section to provide a "garbage collect" operation that would clean up the unused numbers and re-sequence the rest.

This is a huge undertaking and will break things across all of Cuberite, no idea how to tackle that sequentially, so that it's reviewable as PRs.

[tigerw]

BlockIdentifier might just be a big enum of block types for ease of comparison.

In any case, we need a Palette for 1.13 chunk data. It just needs to be a big static lookup table mapping a BLOCKTYPE/NIBBLETYPE combo to a block state id. The vanilla server provides a mapping from block state ("minecraft:xxx" + properties) to ids as a json export, so somehow a mapping from BLOCKTYPE/NIBBLETYPE to block states is needed.

It looks like they've enumerated every possible block state and sequentially assigned ids to them, so presumably Palette won't need any fancy logic once the mappings are written/generated.

[tigerw]

This is a huge undertaking and will break things across all of Cuberite, no idea how to tackle that sequentially, so that it's reviewable as PRs.

Idea: request funding from Microsoft. 

[xoft]

I don't think they performed a static mapping, I think they make a separate dynamic Palette for each chunk section, both when saving to disk and when sending over network.

See: https://github.com/mrkite/minutor/issues...-372810068

[tigerw]

Sure you could do that... or just use 14 bits per block and trade memory for speed

Also I'm having a terrible time trying to get the world to at least render in 1.13 Cuberite. The client inexplicably (even its own error logs don't say more than NullPointerException) crashes when I send the chunk the player is in. Every other chunk appears to render largely fine, sans correct block state ids.

[Mathias]

I've updated the forum to MyBB 1.8.17.