Jump to content

[1.10.2 / 1.12.2] Machines no longer accepting items/fluid/energy after a block type change


turbodiesel4598

Recommended Posts

Hi there,

I have a simple issue which is that my machines stop being able to accept items/fluids/energy (or indeed have them taken out) after the block undergoes an update. I should note that for whatever reason, this issue only appears with certain conduits/ducts such as those of Thermal Dynamics and Integrated Tunnels, but since other machines from other mods don't appear to have the issue, I think the error must be on my end.

The machines will undergo a block update whenever the machine turns on or off, and this happens if it can run or can't run. All of my machines effectively follow the same recipe, so the solution for one of them should almost certainly be the same for the others, but for the purpose of showing the source code, I'll pick one of them:

Tile Entity class (and superclasses if required):

Processors.java
TileEnergyItemProcessor.java

TileEnergySidedInventory.java

TileEnergyInventory.java

TileEnergy.java

NCTile.java

 

Block class (and superclasses if required):

BlockManufactory.java

BlockProcessor.java

BlockSidedInventoryGui.java

BlockSidedInventory.java

BlockInventory.java

Thanks in advance :)

Edited by turbodiesel4598
Link to comment
Share on other sites

If the update changes IBlockStates, then by default, the TileEntity is removed.

Does this issue still happen after overriding TileEntity::shouldRefresh to return oldState .getBlock() != newState.getBlock()?

Also previously known as eAndPi.

"Pi, is there a station coming up where we can board your train of thought?" -Kronnn

Published Mods: Underworld

Handy links: Vic_'s Forge events Own WIP Tutorials.

Link to comment
Share on other sites

I did not know changing the block removes the tile entity. Unfortunately your suggestion does not fix the issue, and I imagine that would be because the idle and inactive blocks are indeed different blocks.

I realise now that I should have been more clear - the machine doesn't have its block's state change - the block type changes, e.g. blockMachineIdle -> blockMachineActive.

In fact, setting the method to return flat out true or false doesn't solve the issue in either case, so I don't think the issue is there.

Edited by turbodiesel4598
Link to comment
Share on other sites

The only reason is probably because the tutorials that I originally watched when first learning how to mod set up their 'custom furnaces' or whatever in that way. When I updated to 1.10.2 and above I guess I didn't know enough about what block states were to realise how I could just use one block. Perhaps I will do that some day, if you recommend doing so.

Anyway, this doesn't fix the problem either.
After a bit more testing, I noticed something a little peculiar. If the machine is off, and then is switched on by, say, adding an item to the input slot, the machine turns on and runs correctly - the energy buffer is kept full and the output is removed as expected. If the machine is then turned off, the output is no longer taken out, and if turned back on again, energy is no longer accepted either. Also, if an adjacent duct undergoes an update (for example, using the crescent hammer on an adjacent duct), then the input/output through that duct alone starts to work again.

Link to comment
Share on other sites

I have a feeling most of your issues stem from the fact that you're using two blocks.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

I think you are right about that - it just seems that, by some happy accident, some mods' pipes/cables/conduits are built with the possibility of a machine using two blocks in mind. I'm almost certain at this point that these issues would disappear if I changed that up.

Thank you all for the help :)

Edited by turbodiesel4598
Link to comment
Share on other sites

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

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

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