Client unable to trigger block-family registration.

[4Denthusiast]

Block families are registered on-demand by BlockManager, i.e. they are only assigned ids once they are requested by URI. On multiplayer servers, the server is in charge of assigning block ids (it has generateNewIds set to true in BlockManagerImpl), so if a client attempts to retrieve a block by BlockManager.getBlock before the first time the server does, it will fail (and return air). This can occur, in particular, if the block is only referred to by a system with @RegisterSystem(RegisterMode.CLIENT).

[4Denthusiast]

Related to this, but probably having the same solution, is the fact that if something requests a list of all the blocks (BlockManager.listRegisteredBlocks), at no point is it actually guaranteed that all the blocks are already registered. While I assume that this is intended so that updated versions of modules can add new blocks to an existing world, it also seems very likely to lead to additional bugs, as the current behaviour isn't well highlighted, and in some cases (e.g. ExtraBlockDataManager), adding new blocks part way through is just much harder to deal with.

[LinusVanElswijk]

We had a discussion about how the engine currently deals with block registrations and if this is desirable.
The engine currently seems to assing ids to block lazily. No block id is assigned until the block is request via BlockManager.getBlock. Because of this modules could add new block ids to the engine at any time. This complicates things, because you can never be sure if the list of registered blocks is final or if stuff gets added later on.

It seems reasonable to me that modules are required to provide a list of block types that they add to the game. This way BlockManager.listRegisteredBlocks can be guaranteed to be a complete list of all possible block in a game.

If modules are required to provide a complete list of blocks at load time, then this should be made clear in the API. Instead of modules requesting the engine to register a block, the engine should request the module the blocks it wants to have registered.

I did some research on how the engine loads modules and studied the BlockManager. I estimate that this change can made with a reasonable amount of time and effort. It's not a trivial change, but shouldn't be too hard to implement either.

The remaining question is what part of a module should be responsible for providing the list of blocks.
Is it reasonable to make ComponentSystems provide the list of blocks to be registered?
Do we want to use kind of annotation? Or some interface like this:

public interface BlockProvider {
    public List<BlockUri> providedBlocks();
}

[Cervator]

@LinusVanElswijk - bit of a clarification request here: do you mean requiring modules to provide a list of block types / families (like "This module provides MyBlock, you could request it in all possible shapes") or all possible block permutations, meaning no more lazy id assignments at all?

I'm thinking the first one, but it is a little unclear to me from just reading your comment :-)

Shouldn't such a list of possible blocks be determined purely by looking at block asset files, no Java needed? There's been one idea to do a scanning step like that to be able to list how many of asset x that exist in module y - could be interesting in a module overview.

It sounds like the idea of block files as true prefabs would also be relevant here. @pollend has been poking at that from time to time, but I'm not sure how it might relate to determining possible block types.

[4Denthusiast]

Block tiles seem to already be loaded in the way Cervator was suggesting: getting a list of every asset file of that type, then processing them all in WorldAtlasImpl. I'm pretty sure that that should be possible for blocks, too, as all block registered with the BlockManager come from either block-family assets or auto-tiles (blocks with no special properties, specified only by their textures). It should definitely at least be possible to continue using block families in the same way (only explicitly mentioning the family for registration, not the individual blocks).

[sladyn98]

I can see a few issues referenced here, wanted to confirm the validity of this issue @4Denthusiast @Cervator before working on it

[Cervator]

@sladyn98 still valid, although I'm not sure if any of the related code has changed since the prior comments. It may be a tricky fix but a high priority one due to the impact in multiplayer.

Another option is a new game initialization phase proposed as part of the multi-world GSOC project, see for instance this flow sketch - rather than wait till the world is actually starting up we could do some of the scanning stuff before that point, so we can initialize more fully before starting to generate world. That'll also be useful in a case where we might start generating world at a higher level than the chunk level where we need blocks and such, like for simulating generic city development over a large span of time. May be relevant to @RatMoleRat's interests :-)

If that sketch shows poorly (it comes out with a black background for me, huh) just poke on Discord and we'll give you team access to it. I tried to make it public but for some reason that isn't working.

[sladyn98]

@Cervator Is the gsoc project idea in draft state because I cannot seem to find it on the trello board.
If not I would like to maybe make a proposal on it and this could be used as a starter or POC if you like.

[Cervator]

Hey again @sladyn98 sorry for missing your comment until now. Bit past the GSOC proposal period too - but honestly multiworld isn't a great pick for GSOC, the complexities are too hard to estimate up front, that's what derailed multiworld's first GSOC. You can see that issue via #3146 and its project board at https://github.com/orgs/MovingBlocks/projects/15

As for this issue: I may have new details, submitted via #3887. We just merged #3886 which fixed a long-standing block id issue and I could confirm in multiplayer a pure-client being able to get a matched up block id list for plain blocks - but then was able to also confirm that a particularly shaped block still resulted in a problem. @4Denthusiast / @LinusVanElswijk: if either of you are still around could you check and see if that's a good example of this issue?

I'm hoping both this issue and the other relate to the same problem, but since this one talks a bit more widely about the architecture in the area I still submitted a separate issue with a more specific case. Discussions keep happening on occasion about improving the registration of block families, especially if we can better the phases of initialization that relate. I imagine we could register all block families if needed without necessarily assigning block ids to every possible combination thereof