Bush growth / block family issue seen with fruit bushes in JS in multiplayer

[Cervator]

Converted this to a full issue while doing follow-up testing for #3886 which fixed some block id issues / invisible blocks in certain cases (#2516) - but not everything, so we still have excitingly quirky bugs to hunt down!

The issue: When planting a seed in plain JoshariasSurvival (get with give joshaberryseed) multiplayer as a connected client the small bush starts out invisible (lower right window) yet a host player (upper left) can see the bush fine. After one growth stage passes both players can see the fully grown block-bush.

I am wondering if #3491 is related (plenty of good notes in there at least!). The BushAuthoritySystem in SimpleFarming is responsible for the logic and is set to RegisterMode.AUTHORITY which is as it should be. Works fine on a host/client session - which might also make sense. But something is failing to get back to a pure client. Even a 2nd pure client can't see the half-block bush as it exists right after being planted by another player.

If you try to plant then walk over the half-block as a pure client it feels like the client and server are disagreeing about what's there: the client attempts to simply walk through the block as if nothing is there, but then gets corrected by the server which knows there's a half-block in the space and moves the client's proper location up by a half-block.

Being that only the first growth stage is using a half-block maybe that's why? That's a different shape than the rest of the stages. So maybe that state is an issue, which could be more linked to #3491. In fact I can trigger the same behavior by simply doing give stone 15 halfblock from a client (given cheat rights) then attempt to place that block. In the world the block is invisible to the client (still fine for host) yet oddly in the inventory and hand it is fine.

Actually, yes, there's even logging to go with this! This snippet is from the client that attempted the above screenie. Maybe I shouldn't have started writing this issue until I was done researching, but I kept thinking up new things to try 😛

11:37:11.822 [main] ERROR o.t.w.b.internal.BlockManagerImpl - Missing id for block CoreBlocks:Stone:engine:halfBlock in registered family CoreBlocks:Stone:engine:HalfBlock
11:37:11.822 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Registered BlockFamily[freeform,CoreBlocks:Stone:engine:halfBlock]
11:37:11.822 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Failed to register block CoreBlocks:Stone:engine:halfBlock - no id
11:37:11.822 [main] INFO  o.t.logic.console.ConsoleImpl - [CONSOLE] You received 15 blocks of Stone

[askneller]

Hello @Cervator I believe I've found some info that might be useful.

When the Joshaberryseed is placed on right click, the block family at that point hasn't been loaded so it gets loaded by the block manager, and is then sent to the client (via NetworkSystemImpl.update line 319) for it to register the block family. Logs from the server:

18:46:07.756 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Registered BlockFamily[freeform,JoshariasSurvival:BerryBush:engine:HalfBlock]
18:46:07.756 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Registered Block JoshariasSurvival:BerryBush:engine:HalfBlock with id 191
18:46:07.757 [main] INFO  o.t.n.internal.NetworkSystemImpl - Component class org.terasology.entitySystem.entity.internal.EntityInfoComponent added to EntityRef{id = 13613, netId = 775, prefab = 'engine:blockType'}
18:46:07.757 [main] INFO  o.t.n.internal.NetworkSystemImpl - Component class org.terasology.world.block.typeEntity.BlockTypeComponent added to EntityRef{id = 13613, netId = 775, prefab = 'engine:blockType'}
18:46:07.757 [main] INFO  o.t.n.internal.NetworkSystemImpl - Component class org.terasology.network.NetworkComponent added to EntityRef{id = 13613, netId = 775, prefab = 'engine:blockType'}

When the he ServerImpl on the client side receives this it builds a map of BlockFamilys to register (a map with the uri as the key and the Integer id to register as the value) and sends that to the BlockManager (in BlockManagerImpl.processBlockRegistrations starting at line 344).

In BlockManagerImpl.receiveFamilyRegistration (starting around line 160) the client side manager first loads the blockFamily via it's own AssessManager. It then loops over the blocks in the loaded family and retrieves the corresponding id to register from the map using the uri of the loaded block.

The problem appears to be that the uri string don't match exactly. Here is the log output from the client after I added some log statements:

19:13:58.787 [main] INFO  o.t.network.internal.ServerImpl - BlockFamily from the server 'JoshariasSurvival:BerryBush:engine:HalfBlock'
19:13:58.791 [main] INFO  o.t.network.internal.ServerImpl - Constructed family-to-id map {JoshariasSurvival:BerryBush:engine:HalfBlock=191}
19:13:58.793 [main] INFO  o.t.w.b.internal.BlockManagerImpl - ShapeUrn engine:HalfBlock
19:13:58.793 [main] INFO  o.t.w.b.internal.BlockManagerImpl - shape engine:halfBlock Half Block
19:13:58.793 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Loaded family uri JoshariasSurvival:BerryBush:engine:halfBlock
19:13:58.794 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Checking map for blockUri 'JoshariasSurvival:BerryBush:engine:halfBlock'
19:13:58.794 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Retrieved id 'null'
19:13:58.794 [main] ERROR o.t.w.b.internal.BlockManagerImpl - Missing id for block JoshariasSurvival:BerryBush:engine:halfBlock in registered family JoshariasSurvival:BerryBush:engine:HalfBlock
19:13:58.794 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Registered BlockFamily[freeform,JoshariasSurvival:BerryBush:engine:halfBlock]
19:13:58.794 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Failed to register block JoshariasSurvival:BerryBush:engine:halfBlock - no id
19:13:58.795 [main] INFO  o.t.network.internal.ServerImpl - Destroying entity: EntityRef{id = 3252, netId = 774, prefab = 'JoshariasSurvival:JoshaberrySeed'}

You may notice that the Constructed family-to-id map has JoshariasSurvival:BerryBush:engine:HalfBlock but the Checking map for blockUri checks for key JoshariasSurvival:BerryBush:engine:halfBlock, the h in halfBlock is a different case.

To confirm that this was the problem (or a sympton) I changed the map to use a lower case key

and that seems to have worked (left is server, right is client).

I know that's treating the symptom and not the problem, but I tried to figure out why the letter cases differed and unfortunately I haven't had much luck figuring that out. I thought I'd document what I've found so that someone with better knowledge in this area might be able to help. Hope this info is helpful.

[pollend]

@askneller we should probably just treat these as id's and any modifications to the string in the code-base should be avoided. might be worthwhile to check where else we do this and remove it.

[immortius]

Suspect code like this predates the existence of Name, incidentally.