-
Recently Browsing
No registered users viewing this page.
-
Posts
-
If that was the problem, it no longer gives me an error when starting, thank you very much for your help 😄 -
By ChampionAsh5357 · Posted
The best I can think of is a makeshift old redstone block where each state is its own separate block. Overriding the `Block::isIn` function is pointless since it doesn't take in a blockstate. This just leaves `CampfireBlock::func_226915_i_`, however this can't event be accessed since its specific for SOUL_CAMPFIRE. If you wanted to do a combined implementation, then you would need to override `Block::isIn` to return true if a SOUL_CAMPIRE is passed in and have your block extend CampireBlock. From there, you would need to put it in BlockTags::field_232882_ax_ which is also known as campfires. You could then override all the methods to make your block act the way its supposed to. That's the only two options I can really think of in the current state. -
Sorry, I'm having trouble. I have a block that has an ON/OFF status, like a campfire. In this case, registering the block in the tag is bad. PiglinsMobsSensor has the following code. private static boolean func_241391_a_(ServerWorld p_241391_0_, BlockPos p_241391_1_) { BlockState blockstate = p_241391_0_.getBlockState(p_241391_1_); boolean flag = blockstate.isIn(BlockTags.field_232865_O_); return flag && blockstate.isIn(Blocks.SOUL_CAMPFIRE) ? CampfireBlock.func_226915_i_(blockstate) : flag; } It looks impossible to me... Is there a solution? -
-
.thumb.png.ac6efa9df20b37a05b89e64e5af08eed.png)
Please try deleting the fml.toml config file, it seems that it is incomplete that the config reader cannot parse it correctly.
-
-
Topics
-
-
Who's Online (See full list)
