Minecraftforge: Expose hooks for axe log stripping

[waitingtocompile]

Currently log stripping behaviour is determined by AxeItem.BLOCK_STRIPPING_MAP, which is a protected static final field. Some sort of hook for registering new blocks and/or letting individual blocks define their own stripping behaviour would be useful.

[williewillus]

You can just do this in your own block's onBlockActivated method, or use PlayerInteractEvent

[TeamSpen210]

That’s true, but it’s rather ad hoc. Each block would then need to replicate the bit of logic in the axe item, and it’s not introspectable - if you wanted to make a “log stripping machine” for example it’d have no choice but to place a block, simulate a right click, post the event maybe and then pick up the block after.

[Draco18s]

it’d have no choice but to place a block

Good luck doing that and not bollocksing something up, too. I have to do a similar thing with a machine to determine valid item stack insertion, and use an entire god damn dimension to avoid...

• overwriting blocks in the world (e.g. breaking the bedrock floor/ceiling)
• letting the spawned block be visible (The End?)
• item duplication (if the player can find the spawned block...)
  etc.

[waitingtocompile]

While handling things on the log's activation is doable, I do agree with Draco and Teamspen that it potentially intoduces some problems with things like the theoretical "log stripping machine", or something similar. Not to mention other problems, where a mod might add some special log stripping tool that, while able to handle vanilla logs fine, doesn't play nicely with your mod's way of implementing log stripping. That's not to mention that it doesn't seem to me unresonable for forge to introduce, for instance, a recipe hook that let's you define log stripping in json, and including that in the mapping that vanilla uses, or some other way of registering that functionality.

[Shadows-of-Fire]

All it needs is a change from protected to public and from ImmutableMap to HashMap. Maybe a further change from Map to IBlockState or IRegistryDelegate, but nothing beyond that. Custom axes can simply call Items.(any axe item).onItemUse to replicate the logic.

You can do it pretty simply right now in code with an AT,

[waitingtocompile]

While that's not too hard I do still think it would be better to actually expose some sort of proper system.

[Alpvax]

Making it a recipe type would be the best approach IMO. Would allow for more modpack customisation.

[Shadows-of-Fire]

Thats not within the specification of IRecipe.

[waitingtocompile]

What do you mean by "not being withing the specification?". That's really unhelpfully vague. Do you mean that the current recipe interface can't handle it? I'm thoroughly unconvinced of that. Do you perhaps mean that it's outside of the intended useage of the recipe system? Again I'm not sold, log stripping is, after all, a means of turning an item into another item. Admittedly the process is a touch different from most of the other vanilla methods, but no more esoteric than mechanics we've seen from mods in the past.

[Shadows-of-Fire]

IRecipe provides a means of transforming Items (in an IInventory only) into another ItemStack.

Log stripping is a process of transforming a BlockState into another BlockState, with a world, pos, and player context. IRecipe has no use there.

[Draco18s]

Just because IRecipe has no use here does not mean that a JSON system is wrong.

[Alpvax]

I can see shadows' point, I was thinking of and said "a recipe type".

We would need to come up with a similar system for blocks, but I think it would be useful for more than just log stripping.
E.g. grass path making, tilling dirt, just in vanilla

[waitingtocompile]

If I have time in the next few days I'll take a look at putting in a PR that adds a json based "block conversion" system. If forgeteam don't like it then no harm no foul.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

[stale[bot]]

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.

[Alpvax]

@waitingtocompile I'm guessing you never got around to looking into this?

I'm happy to look into knocking something up if people are still interested.
How far do we want to go? Do we cover all blockstate changing by player interaction?
Do we make it a system for fluid interaction as well (or a separate similar system)?
A more tricky problem is how to interact with vanilla. The simple approach would be to just leave it hard-coded, and only use the new system for modded interactions, but it would be less consistent.

Does anyone even still care about this enough for me to spend some time on?

[waitingtocompile]

Unfortunately other projects supplanted my time for minecraft modding and this dropped off my list of priorities. If I do end up returning to minecraft modding in the future I might revisit this, though I doubt that'll be any time soon. If this is something you care to do for yourself be my guest.

As for how to handle vanilla stuff, Lex or CPW would be the people to ask, they are the arbiters of "good practice" when it comes to forge after all.