Skip to content

Add BlockItemProvider capability to allow alternative sources of blocks for modifiers like Exchanging#5568

Merged
KnightMiner merged 27 commits intoSlimeKnights:1.20.1from
ChiefArug:blockItemProvider
Feb 18, 2026
Merged

Add BlockItemProvider capability to allow alternative sources of blocks for modifiers like Exchanging#5568
KnightMiner merged 27 commits intoSlimeKnights:1.20.1from
ChiefArug:blockItemProvider

Conversation

@ChiefArug
Copy link
Contributor

@ChiefArug ChiefArug commented Jan 2, 2026 •
edited
Loading

This adds a capability BlockItemProviderCapability that can be added to ItemStacks to let them provide block items. This is intended for compatibility with other mods like Botania that add items that place blocks at the cost of things such as Mana, or hold large numbers of a single block.

BlockItem rather than Block was chosen as the current exchanging logic works off BlockItem, however looking into other places that use instanceof BlockItem there are alternatives for placing the block 'manually' which may be added to Exchanging and the capability swapped to directly use Blocks.

Additionally a new modifier hook has been added to provide a blockitem (at the cost of durability), which glowing uses to provide glows.

TODO:

  • Investigate updating Exchanging to be able to place non BlockItem blocks.
  • Look into support for PlaceBlockFluidEffect
  • Do a final docs pass

@KnightMiner
Copy link
Member

KnightMiner commented Jan 2, 2026

BlockItem rather than Block was chosen as the current exchanging logic works off BlockItem, however looking into other places that use instanceof BlockItem there are alternatives for placing the block 'manually' which may be added to Exchanging and the capability swapped to directly use Blocks.

This could always be done by putting the capability in charge of placing the block to some degree. Default impl runs block item placement, but you could do an impl for placement from other sources.

Related, if we are going to place in exchanging here, we should place from ichors fluid effect in the same way. We do not, however, need to use this capability for the fixed block forms of fluid effects, just the one that selects block from the offhand.

@KnightMiner KnightMiner added Technical Pull requests making changes to workspace or targeted versions 1.20 Issue affects 1.20 labels Jan 4, 2026
@ChiefArug
Copy link
Contributor Author

ChiefArug commented Jan 4, 2026

This could always be done by putting the capability in charge of placing the block to some degree. Default impl runs block item placement, but you could do an impl for placement from other sources.

After implementing this I have realised that theres nowhere in Tinkers (or in the compat I had planned for Botania) where this would actually be used, as they all consume from the inventory anyway. This means I can't test it without some annoying additional useless code. I've committed and pushed this code to my fork on a different branch in case its useful to anyone, but will leave it out of this PR.

@ChiefArug ChiefArug marked this pull request as ready for review January 12, 2026 02:23
@ChiefArug
Copy link
Contributor Author

ChiefArug commented Jan 12, 2026

Should be ready to go now.

If the default BlockItem cap does end up being a performance issue then additional context could be added to the getBlockItem and consume methods to allow a single instance to be reused between all BlockItems.

@ChiefArug
Copy link
Contributor Author

ChiefArug commented Jan 12, 2026

Actually turns out that the Botania integration I am thinking of requires some extra context like that, so time to rewrite it a bit.

@ChiefArug ChiefArug marked this pull request as draft January 12, 2026 02:49
@ChiefArug
Move the cap to providing context to the methods so that singletons c…
6207caa 
…an be used and player context can be provided
@ChiefArug ChiefArug marked this pull request as ready for review January 12, 2026 03:53
@ChiefArug
Copy link
Contributor Author

ChiefArug commented Jan 30, 2026 •
edited
Loading

One thing to consider here is if tools such as those with glowing should implement this capability to provide glows.

KnightMiner
KnightMiner requested changes Feb 1, 2026
View reviewed changes
Copy link
Member

@KnightMiner KnightMiner left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from cosmetics, just have three concerns:

  • If two different modifiers implement the new hook, the merging will simply ignore the second. It should try each hook until it finds the first with a nonnull block item.
  • Place block fluid effect has some issues with how it handles placeRestricted.
  • Seems you need a rebase, as when you implemented the glowing changes it conflicted with an older feature related to the tooltips.

Otherwise looks pretty good as a way to bring back that behavior with exchanging.

@ChiefArug
Fix up most of the misc requested changes.
dd417c9
@ChiefArug
Merge branch 'source/1.20.1' into 1.20.1
3d34ef8 
# Conflicts:
#	src/generated/resources/data/tconstruct/tinkering/modifiers/glowing.json
#	src/main/java/slimeknights/tconstruct/tools/TinkerModifiers.java
#	src/main/java/slimeknights/tconstruct/tools/data/ModifierProvider.java
#	src/main/java/slimeknights/tconstruct/tools/modules/interaction/PlaceGlowModule.java
#	src/main/java/slimeknights/tconstruct/tools/modules/ranged/common/ProjectilePlaceGlowModule.java
@ChiefArug
Make keeping block entity data and adventure mode work by being able …
cbd58c6 
…to provide a backing stack.
@ChiefArug
Run datagen again
a823c33
@ChiefArug
Add backing stack and add a bit more context to some cap methods
4388047
@ChiefArug
Merge branch 'source/1.20.1' into 1.20.1
997e2a5
@ChiefArug
Add canSurvive method to GlowBlock
2b65aba 
Important due to it now having a BlockItem that uses canSurvive to determine suitable placement places.
KnightMiner
KnightMiner reviewed Feb 3, 2026
View reviewed changes
@ChiefArug ChiefArug requested a review from KnightMiner February 4, 2026 05:53
KnightMiner
KnightMiner requested changes Feb 14, 2026
View reviewed changes
Copy link
Member

@KnightMiner KnightMiner left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just had a chance to test this in game and it overall looks good. Just one small bug I discovered when testing it. Should be good to merge after fixing that.

Also seems I accidently gave you another merge conflict due to the reusable projectile logic.

src/main/java/slimeknights/tconstruct/library/tools/capability/ToolBlockItemProviderHook.java
Comment on lines +61 to +62
ToolBlockItemProviderHook provider = entry.getModifier().getHooks().getOrNull(ModifierHooks.BLOCK_ITEM_PROVIDER);
if (provider != null && provider.consumeBlockItem(tool, capStack, entry, backingStack, entity)) {
Copy link
Member

@KnightMiner KnightMiner Feb 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (entry.getHook(ModifierHooks.BLOCK_ITEM_PROVIDER).consumeBlockItem(...))

src/main/java/slimeknights/tconstruct/tools/modifiers/ability/tool/ExchangingModifier.java
BlockPos pos = context.getPos();
if (offhand.isEmpty() || !(offhand.getItem() instanceof BlockItem blockItem)) {
LivingEntity entity = context.getLiving();
if (item.isEmpty()) return null;
Copy link
Member

@KnightMiner KnightMiner Feb 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This causes an issue where empty offhand blocks us from using mainhand's glowing.

@KnightMiner KnightMiner merged commit 0c28558 into SlimeKnights:1.20.1 Feb 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@KnightMiner KnightMiner KnightMiner requested changes

Assignees

No one assigned

Labels

1.20 Issue affects 1.20 Technical Pull requests making changes to workspace or targeted versions

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@ChiefArug @KnightMiner