Describe the bug

Used the latest commit on the master branch: bcee2ec

After setting up a Quantum Network Bridge with an security terminal, changing the player who replaced the security terminal and then unloading and loading the chunk again via travelling, the Quantum Network bridge connection is being broken.

To Reproduce

1. Checkout the above commit
2. Use the below diff to decrease the probability of the same username as the last one in the runClient task from 100% to 0.1% (or manually add the line to the minecraft.runs.client section of the build.gradle)

diff --git a/build.gradle b/build.gradle
index ead856fad..949478faf 100644
--- a/build.gradle
+++ b/build.gradle
@@ -122,6 +122,7 @@
                     source sourceSets.api
                 }
             }
+            args '--username', 'Test###'
         }
         server {
             property 'forge.logging.console.level', 'debug'

3. Start Minecraft via ./gradlew runClient
4. Create a test world (creative mode in my case, gamerule dodaylightcycle = false)
5. Teleport far away from the Spawnpoint: /tp 10000 128 10000 (i think because the spawnpoint is never unloaded)
6. Reduce your Render Distance in the settings to the lowest value (2) to reduce the distance necessary to unload chunks
7. Setup a simple Quantum Network Bridge setup with a security terminal:
   
8. Check that it's working (items can be placed and accessed via both terminals)
9. Save the world and quit Minecraft
10. (Optional) Change the AE2 configuration in run/config/appliedenergistics2-common.toml. Set the key LogSecurityAudits in the section [features.Misc] to true for debugging purposes.
11. Start the client again via ./gradlew runClient
12. Enter the world and ensure, that you cannot retrieve or place items in the ME-Network, because you now have a different player (You should get You lack permission to access this. in the chat). If you got the same player, close the game and go to 11.
13. Break the Security terminal and place it again. You should now be able to retrieve or place items in the ME Network and the Quantum Network Bridge should still be working (as both terminals show the items).
14. Fly ~300 blocks away on one axis to unload the chunk (z in my case). Then turn around and fly back.
15. Only one Crafting terminal now shows the items (the left in my screenshot), as the Quantum Network Bridge does no longer connect both networks.

Expected behavior

The connection should not break due to reloading of the chunk. Either it should never break or break directly when the security terminal is being replaced.

Additional context

• Initially discovered on 1.12
• If you've done step 10, you'll get a bunch of failed security audits: https://gist.github.com/bibo38/96df8b70d72726b4ec07cfcf7c0a7492 (just an excerpt of the failed ones)
  • The security audits fail, because the Network bridge blocks are owned by the first player, but the security station is owned by the second player.
  • Upon connection we have one secured network (the right one with the security station) and the other unsecured network (the left one with the disk drive). And since the unsecured network has the old player id, the secured network won't connect to it, as the old player doesn't have permissions to.
  • I think the relevant check, that's failing here is:

    Applied-Energistics-2/src/main/java/appeng/util/Platform.java

    Lines 952 to 958 in bcee2ec

    	if (!a_isSecure && b_isSecure) {
    	return checkPlayerPermissions(b.getGrid(), a.getPlayerID());
    	}
    	if (a_isSecure && !b_isSecure) {
    	return checkPlayerPermissions(a.getGrid(), b.getPlayerID());
    	}

• Taking out the Quantum Entangled Singularities and putting them back just creates another failed security audit and doesn't connect the networks.

Environment

• Environment:
  • Arch Linux
  • Git 2.28.0
  • OpenJDK 1.8.0_265 64-bit
  • Minecraft 1.16.2
  • Forge 33.0.42
  • MCP 20200812.004259

P.S.: I didn't quite understand the usage of the lastSecurityKey (i know which Grid something belongs to (which is also saved to the NBT), which I could use to get the associated Security station to check the security). And why is the player id is saved to the NBT (i only see it necessary, to be able to make a securityBreak when the player places the block. So keeping it in memory should be sufficient)?

Please verify that this is happening with an existing minecraft account and a normal client.

Not going to happen from my side, as I only own one account.

The security feature depends on existing game profiles and will most likely not work across multiple launches of a hacked client, which indev pretty much is.

The fact, that I cannot reproduce the bug when I don't execute step 2 to get a variable/changing username shows that the security systems seems to work across multiple launches in offline mode.

The ME Security system only cares about the UUID (based on PlayerData.java) and by launching the client multiple times you can check via /data get entity Dev that the UUID stays the same. Launching via another username gives a different UUID and going back to the original username gives you back the correct UUID. Given that I've verified that the UUID is constant for a given username, I don't see, why the AE2 Security system shouldn't work in indev.

See also: https://forums.spongepowered.org/t/why-are-the-uuids-changing-in-offline-mode/20237/4

Thank you for this detailed report. It also shuldn't matter as long as the UUID was stable when the player initially builds the QNB, it should not stop working when the chunks reload, as the player has not yet received a new UUID.

This will probably take some time to look into though.

Please verify that this is happening with an existing minecraft account and a normal client. The security feature depends on existing game profiles and will most likely not work across multiple launches of a hacked client, which indev pretty much is.

Same problem can be reproduced without a QNB:

Is this setup across a chunk border?

it should not stop working when the chunks reload, as the player has not yet received a new UUID.

Here's my Theoretical explanation of the bug. Maybe it helps clarifying the problem:

• Player123 creates the world and sets up the QNB
  • All blocks and items are in AE2 set to be owned by Player123 (after UUID -> AE-Security number mapping).
  • Everything works fine loading and unloading the chunk
• We change the playername (which changes the UUID in offline mode) to Player456
  • The player gets correctly a message when trying to access the system, as he is not Player123
  • The network still works fine with chunk loading and unloading
• Now Player456 replaces the Security station of the Network.
  • Since the QNB connection is already established, it doesn't break the connection immediately
  • When the player reloads the Chunk, we have 2 ME Networks (each with one QNB).
  • In my image the right network has the Security Station which therefore only allows Player456
  • In my image the left network has no security station and is therefore considered as not secured, but knows that it was placed by Player123
  • Now the QNB tries to connect both Networks (due to the chunk loading):

    Applied-Energistics-2/src/main/java/appeng/me/cluster/implementations/QuantumCluster.java

    Line 135 in bcee2ec

    Api.instance().grid().createGridConnection(sideA.getNode(), sideB.getNode()));

    • This fails, because the secured network node only allows connecting to an unsecured node, if the player placing the unsecured node (Player123) has permissions to the secured system (which is owned by Player456).

Is this setup across a chunk border?

It was. But I've executed my steps again with only one chunk and I could reproduce it:

Please note that we probably will not backport this to 1.15. The fix is in 1.16.1 and 1.16.2/3 however.