StealthyNoodle

Fantastic - That would take me days to figure out! Got it all up and running now. Thanks a lot, man! I'll keep this in mind too

Certainly! https://github.com/Fnkee/solidrocks I see that I'm running a copy method on the torch, under the ItemTagsProvider (ModItemTagsProvider). That should be transfering data from the block tag into an item tag. Maybe that's what's causing the duplicate registration.

Currently I don't register a WallTorchBlock, so I wouldn't think that's the duplicate (unless it's being registered as part of the WallOrFloorItem). But at the same time I find it odd that it would register my WallOrFloorItem(which is registered under ITEMS) to be in conflict with my TorchBlock(which is registered under BLOCKS with the same name) as they're unique in their registries as you say. Could it be that I'm messing up somewhere else? Data generation perhaps?

Hi. I've just made a torch that extinguishes over time, but only as a floor block. The torch is functional, but to finish it I need to pass the floor block through a WallOrFloorItem, along with a wall block. I'm struggling with figuring out the proper way to register WallOrFloorItem along with those two blocks. Do I register the TorchBlock and WallTorchBlock with their own unique registry-names, or do they get registered as part of WallOrFloorItem? If they all should be registered, shouldn't I be able to use the same registry-name for WallOrFloorItem and TorchBlock? If only there was an example resource to look at, that'd help a lot too! tl;dr: What's the right way to register custom WallOrFloorItem, TorchBlock and WallTorchBlock? ModItems: public static final RegistryObject<Item> FLIMSY_TORCH = Registration.ITEMS.register("flimsy_torch", () -> new WallOrFloorItem(ModBlocks.FLIMSY_TORCH.get(), Blocks.WALL_TORCH, (new Item.Properties()).group(ItemGroup.DECORATIONS))); ModBlocks: public static final RegistryObject<Block> FLIMSY_TORCH = register("flimsy_torch", () -> new FlimsyTorchBlock(Block.Properties.from(Blocks.TORCH).tickRandomly().setLightLevel((state) -> { return 14; }), ParticleTypes.FLAME, 3)); //Still missing a WallTorchBlock, using vanilla WallTorch as placeholder When trying to register the TorchBlock in addition to the WallOrFloorItem(using same name), I'm presented with this error:

Wooh, got it! I continued reading about getUpdatePacket and onDataPacket, and stumbled over @diesieben07's post on the matter: I was certain I had to handle all the data through getUpdateTag and onDataPacket, but seems like the data first has to be sent through getUpdateTag (which is then processed by handleUpdateTag). I still still struggle with wrapping my head around exactly how it works, but I think I'm starting to grasp the concept. Here's the latest, working version. Some of the code has been optimized and moved around since last time. DynamiteBlock: DynamiteTileEntity: Thanks a lot for helping out, poopoodice!

Thanks. I did some reading up on the docs in regards to syncing, but I'm worrying that my formatting here is still off (even though it seems to pick up the changes I do). The logger triggers whenever I call notifyBlockUpdate on the DynamiteBlock class, yet the isActive-bool still doesn't appear to change on client side. I've been looking at several cases, but few examples handling custom data through getUpdatePacket and onDataPacket. Here's what I've tried out so far (even though it still isn't functioning correctly) DynamiteBlock: DynamiteTileEntity:

Thanks for your quick response! This should probably point me in the right direction - not sure if I grasp exactly how they're used yet, but will see if I can't figure it out. Here's the full code of both classes, should that be more insightful: DynamiteTileEntity: DynamiteBlock:

Hello. I've been trying for some time now, to add a particle effect to my custom Dynamite TileEntity, identical to that of a TNTEntity, but can't seem to make the particle-effect appear. I reckon this have to do with the TileEntity's isActive-boolean being called on server, rather than client, resulting in the conditions never being checked on client-side. I'm unsure what the proper way of implementing this would be though, and I can't find a similar example of conditional ticking elsewhere in vanilla. I had a look at the Block method animateTick, but that one only seems to be called periodically, thus not producing the wanted results. DynamiteTileEntity: @Override public void tick() { if(isActive) { if(this.fuse <= 0) { this.remove(); if (!this.world.isRemote) { execute(); } } else { this.fuse--; if (this.world.isRemote) { this.world.addParticle(ParticleTypes.SMOKE, this.getPos().getX() + 0.5D, this.getPos().getY() + 0.5D, this.getPos().getZ() + 0.5D, 0.0D, 0.0D, 0.0D); } } } } DynamiteBlock: public ActionResultType onBlockActivated(BlockState state, World world, BlockPos pos, PlayerEntity player, Hand handIn, BlockRayTraceResult hit) { if (world.isRemote) { return ActionResultType.CONSUME; } else { TileEntity tileentity = world.getTileEntity(pos); if (tileentity instanceof DynamiteTileEntity) { DynamiteTileEntity dynamiteTileEntity = (DynamiteTileEntity)tileentity; if(dynamiteTileEntity.isActive) { this.isActive = false; dynamiteTileEntity.deactivate(); CodingPanda.LOGGER.info("DISENGAGED"); return ActionResultType.SUCCESS; } else { dynamiteTileEntity.activate(); this.isActive = true; CodingPanda.LOGGER.info("ACTIVATED"); world.playSound((PlayerEntity)null, pos.getX(), pos.getY(), pos.getZ(), SoundEvents.ENTITY_TNT_PRIMED, SoundCategory.BLOCKS, 1.0F, 1.0F); return ActionResultType.SUCCESS; } } return ActionResultType.CONSUME; } }

Seems like the log was referring to world being called, without it being declared first (I would've thought it would declare world every time the event ran). Checking if world is null seemed to fix the issue, though I guess might not be the most optimal solution? if(world != null) { if(!world.isRemote()) { Anyways, it took care of the problem! I'll carry on.

Hello. I'm interested in learning to write mods for Minecraft, and have little experience with java from before (got some knowledge in C# and AS though). I've read up on the documentation, and I gotta admit a lot of it is overwhelming! Nevertheless I wanna give it a shot, and am now in process of testing the waters of Forge, and seek your guidance. Now the problem: Upon world generation, I wish to replace all stone blocks with a block of different properties and texture. I've somewhat managed to do so, but now the world won't save any changes and all blocks seem to reset upon reentering the world. Code: public class HelloEventHandler { @SubscribeEvent public void ChunkLoad(ChunkEvent.Load event) { //final Logger logger = LogManager.getLogger(Reference.MOD_ID); IWorld world = event.getWorld(); IChunk chunk = event.getChunk(); if(!world.isRemote()) { //logger.info("Hi. this chunk is on server side"); //if(chunk.isModified() == false) { Block fromBlock = Blocks.STONE; Block toBlock = Blocks.OAK_WOOD; for(ChunkSection storage : chunk.getSections()) { if(storage != null) { for (int x = 0; x < 16; ++x) { for (int z = 0; z < 16; ++z) { for (int y = 0; y < chunk.getTopFilledSegment()+1; ++y) { if (chunk.getBlockState(new BlockPos(x ,y, z)).getBlock().getDefaultState() == fromBlock.getDefaultState()) { chunk.setBlockState(new BlockPos(x ,y, z), toBlock.getDefaultState(), true); } } } } } //chunk.setModified(true); //} } } } } Log: https://pastebin.com/8d4S1zi6 All I understand from what I'm reading is that the chunks won't load due to a NullPointerException ? I'm definitely open for other solutions here. At first I tried registering a new block as "minecraft:stone", as done in this thread, but didn't manage to change the texture this way. Searching for an alternative solution I came across this thread which is the origin of the event I'm currently using (I can't seem to find the markDirty-method under the IChunk class, so figured this might have been switched out in 1.14?). I would've thought that changing blocks on world generation would be optimal, but haven't managed to find any examples of this so far - and I'm far too inexperienced to trust my own assumptions. If this is something I easily would've solved with more java-experience, I'll take my leave.