Fix redstone neighbor update order differing from vanilla

[embeddedt]

Fixes #1863. We now update in the horizontal plane order, and then the vertical plane order. Technically we still emit updates on the vertical axis, while vanilla does not, but this should still be much closer to vanilla behavior. We also don't send vertical updates to vanilla comparators anymore.

Suggestions would be appreciated on where to put NEIGHBOR_UPDATE_LIST.

Most credit goes to 2No2Name for the code analysis.

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

Last commit published: a24773c091c0641cbfdf204b29ae3e38d8511475.

PR Publishing

The artifacts published by this PR:

• 📦 net.neoforged:testframework:21.4.66-beta-pr-1866-neighbor-update-order
• 📦 net.neoforged:neoforge:21.4.66-beta-pr-1866-neighbor-update-order

Repository Declaration

In order to use the artifacts published by the PR, add the following repository to your buildscript:

repositories {
    maven {
        name 'Maven for PR #1866' // https://github.com/neoforged/NeoForge/pull/1866
        url 'https://prmaven.neoforged.net/NeoForge/pr1866'
        content {
            includeModule('net.neoforged', 'testframework')
            includeModule('net.neoforged', 'neoforge')
        }
    }
}

MDK installation

In order to setup a MDK using the latest PR version, run the following commands in a terminal.
The script works on both *nix and Windows as long as you have the JDK bin folder on the path.
The script will clone the MDK in a folder named NeoForge-pr1866.
On Powershell you will need to remove the -L flag from the curl invocation.

mkdir NeoForge-pr1866
cd NeoForge-pr1866
curl -L https://prmaven.neoforged.net/NeoForge/pr1866/net/neoforged/neoforge/21.4.66-beta-pr-1866-neighbor-update-order/mdk-pr1866.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zip

To test a production environment, you can download the installer from here.

[Technici4n]

I think that this is a fine place to have the constant. Can you add a comment along the lines of // Neo: Also send update to vertical directions?

[2No2Name]

The issue also includes the vertical updates existing, which is detectable and different from vanilla. I think in some reasonable setups this might occur accidentally, breaking contraptions. (Comparator update detector above or below some other inventories.)

This setup updates the detector with neoforge, but not in vanilla.

For some reason placing the comparator directly on the hopper doesn't trigger the behavior, I don't understand why.

[2No2Name]

For reasoning on what's happening and what I suggest to do: #1863 (comment)

[embeddedt]

PR has been updated, as per feedback, to exclude vanilla comparators from the vertical updates.

[2No2Name]

For me it is confusing that these two different update methods exist, meaning
blockstate.onNeighborChange(this, blockpos, p_46718_); and
this.neighborChanged(blockstate, blockpos, p_46719_, null, false);
What's the reasoning for these being different calls?

blockstate.onNeighborChange seems to a neoforge method that by default only comparators implement.
The second method seems to be the vanilla method