Introduce proxyable and non-proxyable block capabilities

[Technici4n]

Some capabilities are not safe to forward to another block. For example, AE2 has such a capability (that is used to find ME Network components). This can result in nonsensical connections, and even in crashes in some cases with mods like Capability Proxy.
This PR proposes that block capabilities may be marked as not being proxyable. Mods like Capability Proxy should stop proxying such capabilities. cc @rubensworks

[neoforged-pr-publishing]

• Publish PR to GitHub Packages

Last commit published: c312629e710d451aa01c34e39518f0af32497541.

PR Publishing

The artifacts published by this PR:

• 📦 net.neoforged:neoforge:21.1.10-pr-1446-non-proxyable-block-caps
• 📦 net.neoforged:testframework:21.1.10-pr-1446-non-proxyable-block-caps

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 #1446' // https://github.com/neoforged/NeoForge/pull/1446
        url 'https://prmaven.neoforged.net/NeoForge/pr1446'
        content {
            includeModule('net.neoforged', 'neoforge')
            includeModule('net.neoforged', 'testframework')
        }
    }
}

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-pr1446.
On Powershell you will need to remove the -L flag from the curl invocation.

mkdir NeoForge-pr1446
cd NeoForge-pr1446
curl -L https://prmaven.neoforged.net/NeoForge/pr1446/net/neoforged/neoforge/21.1.10-pr-1446-non-proxyable-block-caps/mdk-pr1446.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.

[HenryLoenwind]

I don't agree with this approach. Forwarding any capability you don't know the semantics of is a Very Bad Idea and should not be done.

Explicitly allowing other mods to handle unknown capabilities in random ways only opens the door for even more semantics-breaking uses. I see no way I would ever not set proxyable to false even when making a capability that would be proxyable using the correct capability-specific semantics.

A better solution would be to include an original target specifier to getCapability, which would allow proper handling of requests for capabilities that were forwarded (this is how http handles this). That way, the code that knows the semantics of a capability (because it hands it out) can properly handle forwarded requests if it needs to. This also would enable bidirectional requests like they are required for cable connections (although those would be tricky to implement as it breaks the assumption that each block side can have exactly one connection, something that will remain true in rendering the connection).

[Technici4n]

Forwarding any capability you don't know the semantics of is a Very Bad Idea and should not be done.

Mods have been doing this for some time, for example Capability Proxy or Entangled. It is quite clearly useful for the capabilities where it is safe.

I see no way I would ever not set proxyable to false even when making a capability that would be proxyable using the correct capability-specific semantics.

The point here is that a lot of "transfer" capabilities, which are the ones that players generally want to proxy, are completely safe to proxy. This includes for example all of NeoForge's builtin block capabilities, as well as Mekanism gasses for example.

A better solution would be to include an original target specifier to getCapability

This would make the capability provider interface more complicated for everyone, in order to address what is pretty much a niche feature. There might be other solutions to this problem, but that doesn't feel like one.

---

An alternative is to flip the default: make capabilities non-proxyable by default, and require opt-in for capabilities where it makes sense.

[rubensworks]

This approach looks good to me, should be straightforward to implement into Capability Proxy.

A better solution would be to include an original target specifier to getCapability

I agree this could be beneficial. But given the invasiveness of such changes, it would probably be better to keep it as a future (possible breaking) change, and continue with this PR here in the short-term.

[Soaryn]

Is this possible to be made to be chained so that we could call something like

    BlockCapability<SomeClass, Void> BLOCK = BlockCapability.createVoid(resource("some_handler"), SomeClass.class).nonProxyable();

[Technici4n]

I'm not a fan for the reason that it is dependent on classloading, and might be called at any time.