Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocks cannot be broken due to lacking a tool #309

Open
alcatrazEscapee opened this issue Sep 6, 2024 · 0 comments
Open

Blocks cannot be broken due to lacking a tool #309

alcatrazEscapee opened this issue Sep 6, 2024 · 0 comments

Comments

@alcatrazEscapee
Copy link
Owner

Background

Between Minecraft 1.12 and 1.20.1 (and likely in future), Mojang underwent several reworks of the way they declare tools, and tool-block compatibility. The main influence of this was moving to datapack-defined, explicit lists of blocks which can be broken with a given tool: #minecraft:mineable/axe, #minecraft:mineable/pickaxe, etc.

While this is generally fine and dandy, note that the check that blocks can drop without the correct tool, is still largely hardcoded to individual blocks, and notably NTP attempts to modify this for all blocks, way earlier than tags are loaded or visible - meaning it does not currently see if blocks have a tool.

Moreover, there is no functional way to assess if a block is breakable with an arbitrary modded tool. If mod A adds a block X, which is broken with a tool Y from that mod, and it's not using any conventional tool (i.e. shovel, axe, hoe, etc.), it's functionally impossible - without explicit compatibility with arbitrary mods - to determine if the block is mineable via some tool.

This has led to a situation in NTP where it tries to infer as much as it can (which is not much), however errs on the side of being quite aggressive, and leaves various holes with blocks that either have no tool, or cannot be mined. As the mod had been trying to focus on this core tenet (at the expense of any other potential content), this leaves it in a rather sorry state.

Workarounds

In theory - in theory - this is entirely resolvable via datapack. Blocks can be added to the respective tool tags, or whitelisted entirely from NTP, both from vanilla, or from other mods. If this sort of behavior is desired, it can be achieved. Except, it's insane to ask users to configure every combination of mods, and especially given I do not want to take the burden of proving that every block in vanilla is obtainable if originally intended to be. Doing this on any sort of manual basis is simply out of the question, however possible it may be.

NTP also has config options to disable this functionality, including a (perhaps bandaid) fix of disabling this functionality for instant-breaking blocks (which would tend to cover most of the issues that seem to be arising). This is a short term fix essentially admitting the block breaking functionality does not, and cannot work in the long term.

Another possible workaround for the core problem is to, in effect, reject the premise of NTP. The only blocks that can be set as blocks that require a tool, are blocks that can be deterministically proven at runtime to have a tool (i.e. anything tagged via known tools such as shovels, hoes, pickaxes, axes). This does, to some extent, throw away the premise of making block mining impossible or no drops without the correct tool, and probably leaves out most instant break blocks. The mod focuses less on the premise of block breaking; and becomes a flint-tool-and-some-random-pottery-objects mod. I, unfortunately, am not interested in maintaining such a mod at present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant