Fix custom fluid baking for Supplementaries lumisene#166
Conversation
|
Hi, supp author here. I looked at this and I was wondering why it needed to be this hardcoded. Is it because of the couple of mixin that supplementaries has in liquid block? |
The problem is your lumisene liquid exdends vanilla Fluid path, but for some reason your block part only extends Block class and then continues with FiniteLiquidBlock -> FlammableLiquidBlock path, but voxy algorithm calls for all blocks, checks wether its a pure fluid block by doing blockState.getBlock() instanceof LiquidBlock, lumisene do not fall under liquidblock category, so voxy checks whether its waterlogged block by doing (!isFluid) && (!blockState.getFluidState().isEmpty()) and lumisene returns true for both checks and voxy decides that its waterlogged block that contains fluid state, after that baker tries to bake fluid state via blockState.getFluidState().createLegacyBlock() and it returns same lumisene liquid with id -1, cause all liquid blocks should be baked before starting to bake waterlogged blocks, that already contains its respective id(more than -1), but lumisene do not fall for the liquid category and therefore there is no baked lumisene with non -1 id, baker sees it and trow exeption IllegalStateException("Block has a fluid state but fluid state is not already baked!!!"), thats why all this crashes happens, so thats why most plausable fix from voxy side looks this hard-coded, and from supplementaries side it would be easiest to make FiniteLiquidBlock also extend LiquidBlock class, not only Block class, if you have any questions left, you can message me in discord, my id: magamed . |
|
Sooooo doesn't this uncover a deeper issue of the mod? The whole "making assumptions" part? Lumisene CANNOT extend Liquid block as that requires a FlowingFluid and lumisene is just a Fluid. The game interface's howeeve definitely allow conditions like this. Shouldn't this mod be changed to respect the game contracts better instead? Otherwise next time a mod does something like this a similar crash will be thrown again |
Well, you're right, but as you say it would be hard-coded to both catch your situation or fix this design flaw, and i'm not the Cortex, i can't change this design issue, i can only suggest bypasses. |
|
yeah obviously hats off to you for figuring out the bypass. I'm just suggesting to the devs here to actually look into fixing the issue at the root by making the system not make assumptions about FlowingFluids and LiquidBlocks as the game allows that. |
2 participants
No description provided.