"Epic" issue about network node and world representation desyncs

[raoulvdberge]

A long time ago... I made an architectural decision for RS that has worked good for us for years. Unfortunately, since mods and Minecraft are evolving, this decision is quite problematic now.

This issue is alleviated in RS 2, but needs (temporary) fixing/workaround in RS 1.

Blockstate mismatch

• Server Instant Crash #3410
• crash with orientation #3383

Network(Node) mismatch

• Invalid player data - AdvancedExporterNode cannot be cast to class ExternalStorageNetworkNode #3357
• ClassCastException with mekanism transporter #3376
• Cables and Create schematics (.nbt) burned my creative testing world #3405
• Override nodes anyway to prevent crashes #3326
• Bug before create the world #3337
• World corruption after using copy paste gadget #3291
• When disk drive is placed by any sort of block placer word crash and make it unplayable #3273
• Crash when placing controller using a CC Tweaked turtle #2610
• Certain *NetworkNodes can fail to cast to CableNetworkNodes #3459
• Crash and world corruption when breaking RS parts with Ars Nouveau #3583
• RS and Tom's Simple Storage instant crash - unable to reconnect afterwards #3563
• Refined Storage exporter / importer corrupting world (with logs this time) #3555
• client locked out of server #3556
• Random crashes connecting cables and/or exporters within ATM8 (and most recent RS and Forge) #3477
• Previous server crash caused Wireless Transmitter with Inf booster to vanish... #3586

Confusing behavior

• Blocks don't keep installed items when copied with SHIFT+M3 while in creative #2254

[raoulvdberge]

Some work for this has been done already on: 885d46c

[raoulvdberge]

Note to addon developers

If you are using NetworkNodeBlockEntity

Starting from RS v1.12.4 for MC 1.20.1 (and version v1.11.7 for MC 1.19.2, v1.10.6 for MC 1.18.2) it is strongly advised to pass the network node class type to the constructor.

For example:

    public DetectorBlockEntity(BlockPos pos, BlockState state) {
-       super(RSBlockEntities.DETECTOR.get(), pos, state, SPEC);
+       super(RSBlockEntities.DETECTOR.get(), pos, state, SPEC, DetectorNetworkNode.class);
    }

In order to avoid crashing bugs at runtime when a block entity mismatches with its network node representation, RS needs to know the class type.

Both constructors will keep existing to ensure compatibility, but please move to this new format to avoid crashes (see this bug report for a nice list).

When can I use this API?

Now!

• For MC 1.20.1: v1.12.4
• For MC 1.19.2: v1.11.7
• For MC 1.18.2: v1.10.6

If you are not using NetworkNodeBlockEntity

If you have a custom implementation of INetworkNodeProxy, remember to cast safely when you are retrieving the node from the network node manager.
Like so:

    @Override
    @Nonnull
    @SuppressWarnings("unchecked")
    public N getNode() {
        INetworkNodeManager manager = API.instance().getNetworkNodeManager((ServerLevel) level);

        try {
            INetworkNode node = manager.getNode(worldPosition);

            if (node == null) {
                LOGGER.warn("Expected a node @ {} but couldn't find it, creating a new one...", worldPosition);
                node = createAndSetNode(manager);
            }

-           return (N) node;
+           return networkNodeClass.cast(node);
        } catch (ClassCastException e) {
            LOGGER.warn("Node @ {} got desynced with it's block entity container, recreating", worldPosition, e);
            return (N) createAndSetNode(manager);
        }
    }

[raoulvdberge]

Fixed in 9b30bec

Will be fixed for RS v1.12.4 for MC 1.20.1 and will probably be backported to MC 1.19.2.

[raoulvdberge]

This is now backported to MC 1.19.2 in version v1.11.7.

[raoulvdberge]

This is now backported to MC 1.18.2 in version v1.10.6.