Jump to content

Recommended Posts

Posted

I'm making a multiblock structure - an item which, when placed, places a set of three blocks in a particular layout. When any one of those blocks is broken, all of the others are removed too. I've made the neighborChanged method so that it checks the expected positions of the other blocks in the structure, and then removes the block if they aren't there. I've also made the onItemUse method to place all three blocks when the item is clicked.

 

But when I actually use the item in the game, the structure doesn't get placed. Because on each setBlockState call, the game checks for neighborChanged and finds the the other blocks aren't there yet. I've looked through the code for vanilla beds and I can't figure out how this problem is suppressed there. I could add a whole other block property to keep track of whether the structure is 'being built' or not, and only update it if it's false - but that seems excessive. Is there any other way to tell the game not to check neighborChanged until all the blocks of the structure have been placed via onItemUse?

 

Edit: I think I've solved it! Needed to add the third parameter to the setBlockState method, the flags which define whether the block updates the neighbours. I don't understand bitwise flags very well, but with some trial and error it seems that '2' is making it work as expected.

Solved with Choonster's advice in post #2.

Posted

When a bed item is right clicked on a block:

  • The foot block is placed, calling
    Block#neighborChanged

    on the surrounding blocks (none of which are incomplete beds)

  • The head block is placed, calling
    Block#neighborChanged

    on the surrounding blocks (one of which is the foot of the now-complete bed)

 

Block#neighborChanged

is never called on an incomplete bed while the bed is being placed.

 

You should implement your

Block#neighborChanged

override such that it only checks the immediately adjacent blocks and not the whole structure.

 

Let's say your structure is composed of three blocks: left, right and centre. When your item is right clicked on a block:

  • Place the left block, calling
    Block#neighborChanged

    on the surrounding blocks. None of these are structure blocks.

  • Place the centre block, calling
    Block#neighborChanged

    on the surrounding blocks. One of these is the left block, which checks the immediately adjacent blocks, finds the centre block and does nothing because it's valid.

  • Place the right block, calling
    Block#neighborChanged

    on the surrounding blocks. One of these is the centre blocks, which checks the immediately adjacent blocks, finds both the left and right blocks and does nothing because they're valid.

 

Whenever a structure block is broken,

Block#neighborChanged

will be called on the surrounding blocks. The adjacent structure blocks will see that the structure is now incomplete and remove themselves, propagating the change along the structure.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted

Ahh, thank you! I was thinking that I needed every block in the structure to check every other block, but I see now that I can just have them trigger each others' checks in a chain.

 

This means that I actually don't need to set the third parameter in the

setBlockState

method, right?

Posted

This means that I actually don't need to set the third parameter in the

setBlockState

method, right?

 

Correct, the two-argument overload of

World#setBlockState

(which uses 3 [1 + 2] as the flags) should work.

 

Oddly enough,

ItemBed

uses 11 (1 + 2 + 8) as the flags even though it only sets the block on the server and only the client-side implementation of

IWorldEventListener#notifyBlockUpdate

(indirectly called by

World#setBlockState

) actually checks for flag 8.

 

Edit: I always forget to disable smileys when posting something with "8)" in it.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Hey! I noticed you're trying to register your alexandrite item and possibly set its resource location manually with setId(...). I wanted to help clarify a few things that might simplify your code and avoid errors. ✅ The issue: You're using setId(...) inside the item registration like this:   public static final RegistryObject<Item> ALEXANDRITE = ITEMS.register("alexandrite", () -> new Item(new Item.Properties().useItemDescriptionPrefix() .setId(ResourceKey.create(Registries.ITEM, ResourceLocation.fromNamespaceAndPath(TutorialMod.MOD_ID, "alexandrite"))))); But: Item.Properties does not have a setId(...) method — this line will either fail or do nothing meaningful. useItemDescriptionPrefix() is mostly used for translation keys (like "item.modid.name") but isn't needed unless you have a very specific reason. 🛠 The fix: You only need to register your item like this:   public static final RegistryObject<Item> ALEXANDRITE = ITEMS.register("alexandrite", () -> new Item(new Item.Properties())); Forge automatically handles the ResourceLocation (modid:alexandrite) based on the name passed into .register(...), so there’s no need to manually assign it. 📝 For the texture: Make sure you have this file in your resources: src/main/resources/assets/tutorialmod/models/item/alexandrite.json { "parent": "item/generated", "textures": { "layer0": "tutorialmod:item/alexandrite" } } And your texture PNG goes here: src/main/resources/assets/tutorialmod/textures/item/alexandrite.png 🌍 For the name in-game: Add this to your en_us.json under: src/main/resources/assets/tutorialmod/lang/en_us.json { "item.tutorialmod.alexandrite": "Alexandrite" }   Note: if im wrong about the issues you are encountering, i apologize.
    • 🛠️ Fix for Transparent or Clipping Item Render Issues When Held in First Person (Forge 1.20+) Hey everyone! I recently ran into a frustrating bug while making a custom item (a rocket) for my Forge mod, and I’m sharing the fix because it’s a bit obscure — and it worked wonders. 💥 The Problem: My item rendered semi-transparent and see-through — but only in first person. It also clipped through nearby blocks when held, unlike default items like swords or leads. The texture file was confirmed to be fully opaque (alpha 255), so the issue wasn’t the PNG itself. Interestingly, when no texture was present and the default purple-black checkerboard appeared, the clipping issue disappeared. ✅ The Fix: I ended up resolving it by randomly trying something I found on a Forge forum post about block rendering. I added this property to my item's model JSON — even though it's typically only used for blocks: { "parent": "item/generated", "textures": { "layer0": "farbeyond:item/rocket_item" }, "render_type": "minecraft:cutout" } Boom. That single line forced the item to render using a proper opaque (cutout) layer, removing all the unwanted transparency and clipping behavior in first person. 🙌 Credit: I originally found the "render_type" trick mentioned here, in a block rendering context: 👉 https://forums.minecraftforge.net/topic/149644-1201-help-with-transparent-blocks/ Even though it was meant for blocks, I thought, why not try it on an item? And it worked! Big thanks to the poster — this fix wouldn’t have happened without that tip. Hopefully this helps anyone else stuck on a weird rendering bug like I was. This isn’t a common item solution, so feel free to share it further. I’d love to know if it works for you too.
    • Use Java 21 instead of Java 24   Also make a test without modernfix
    • Ive been on this world for 2 days now, my computer blue screens pretty often so maybe that has something to do with it. maybe just incompatible mods like a lot of people so im hoping someone more knowledgeable can help me find what i need to get rid of. thank you! paste bin
    • Should probably say that i am running minecraft 1.21.1 and with quite a lot of mods (many of which im unsure should even be on the server side)
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.