Loghan

https://forums.minecraftforge.net/topic/157393-1201-forge-rocket-flame-particle-trail-moves-up-and-crashes-into-the-rocket-during-flight/#comment-584134

Hi everyone, I’m working on a custom rocket entity in Forge 1.20.1. During flight, I’m trying to spawn flame and smoke particles that trail behind the rocket, like in Ad Astra or Galacticraft. I’m using ServerLevel.sendParticles() with calculated Y-offsets far below the rocket's base (e.g., getY() - 2.5), so the particles should clearly appear under the rocket thruster. ❗The Problem: Even though I spawn the particles several blocks below the rocket, they still start rising and eventually collide with the rocket from below. It's like the particles are moving upward with the rocket, even though their Y position is set in absolute world coordinates (not relative to the rocket). This causes the trail to look broken, unrealistic, and eventually the flames just slam into the rocket's base, defeating the effect. 🔍 What I’ve Tried: Double-checked that I’m using server.sendParticles(...) with proper world coordinates. Increased vertical offset (up to -3 blocks or more). Spawned debug markers (armor stands) and verified their position is correctly placed far below. Tried spawning trail particles after calling move(MoverType.SELF, ...). Confirmed this only happens when the rocket is moving upwards — at rest, particles stay where they’re supposed to. 🔥 Code Snippet: double rocketBottomY = this.getY() - 2.5; double trailSpacing = 0.12; for (int i = 0; i < 40; i++) { double offsetX = (random.nextDouble() - 0.5) * 0.2; double offsetZ = (random.nextDouble() - 0.5) * 0.2; double flameY = rocketBottomY - (i * trailSpacing); server.sendParticles(ParticleTypes.FLAME, this.getX() + offsetX, flameY, this.getZ() + offsetZ, 3, 0.0, 0.0, 0.0, 0.01); } No matter how far I place the flameY below, it still starts drifting upward with the rocket. I’m not applying velocity to the particles (0.0 on Y), so I have no idea what’s making them rise and then crash into the rocket ❓Question Has anyone dealt with this before? How do mods like Galacticraft or Ad Astra keep their flame trails pinned to the world while the rocket moves up? Is this a side-effect of how Forge or Minecraft queues particle updates for moving entities?

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.