1.12.2 | Desynced Block

[Daring Do]

Okay, so, for whatever reason, the rotation on my block causes it to desync with the server when broken. I know it's the rotation, as I commented all of it out, ran it, and it was perfectly okay. Any ideas as to how to fix this? I've tried copying from the furnace class, extending the furnace class, following a tutorial on block rotations. All of it led to the same desyncing problem.

Code is right here:

Spoiler

Block class: https://github.com/CammiePone/Voidaic-Arcania/blob/master/src/main/java/com/camellias/voidaicarcania/blocks/BlockMortalCentrifuge.java

Other classes used by said block: https://github.com/CammiePone/Voidaic-Arcania/tree/master/src/main/java/com/camellias/voidaicarcania/blocks/blockmortalcentrifuge

 

[Daring Do]

1 minute ago, diesieben07 said:

• Problematic code, issue 4, 5, 10, 14.
• Do not use that "re-use the tile entity" hack that the vanilla furnace uses. Override TileEntity#shouldRefresh.
• You are not retaining the BURNING property in metadata. You must serialize and deserialize all properties that are not stored elsewhere (and set via getActualState) in getMetaFromState resp. getStateFromMeta.

Except, in reference to 4 and 5, as well as 10, the tile entity isn't the issue. Nor is it the BURNING property. There exist 2 other tile entities, both of which work flawlessly, and act similarly, code-wise, to this one. It's the rotation that's screwing it up.

[jabelar]

3 minutes ago, Daring Do said:

Except, in reference to 4 and 5, as well as 10, the tile entity isn't the issue. Nor is it the BURNING property. There exist 2 other tile entities, both of which work flawlessly, and act similarly, code-wise, to this one. It's the rotation that's screwing it up.

 

diesieben07 is being helpful by providing additional review to your code. Even though it may not be directly related to your reported problem, these are in fact problems. Note that sometimes when code is "unhealthy" it is not immediately clear there is a problem -- bugs can lurk without causing full crashes -- so you can't just say that it is fine because you think it is working elsewhere. For example, because you don't serialize the BURNING property your saves will be screwed up. diesieben07 took the time to write up that list of common problems for a reason -- many mods have had trouble due to them.

[Daring Do]

8 minutes ago, jabelar said:

 

diesieben07 is being helpful by providing additional review to your code. Even though it may not be directly related to your reported problem, these are in fact problems. Note that sometimes when code is "unhealthy" it is not immediately clear there is a problem -- bugs can lurk without causing full crashes -- so you can't just say that it is fine because you think it is working elsewhere. For example, because you don't serialize the BURNING property your saves will be screwed up. diesieben07 took the time to write up that list of common problems for a reason -- many mods have had trouble due to them.

Maybe so, but I came here looking for a solution to this problem specifically. If I find other problems later on, I'll come back here and debate on whether or not to rewrite 3 tile entities and blocks. I didn't finish the BURNING bit, as I haven't gotten the rotation issue functioning properly, which is my number one concern right now.

 

And while, yes, I do appreciate them trying to assist in a potential issue later down the line, I'd rather fix the one right in front of my face.

Edited July 13, 2018 by Daring Do

[Animefan8888]

8 minutes ago, Daring Do said:

And while, yes, I do appreciate them trying to assist in a potential issue later down the line, I'd rather fix the one right in front of my face.

Did you even attempt to make the changes diesieben described, they could be somehow interfering with your blocks rotation.

[Daring Do]

1 minute ago, Animefan8888 said:

Did you even attempt to make the changes diesieben described, they could be somehow interfering with your blocks rotation.

It would take me a few hours to make all of those changes to one of them, and test it to make sure it didn't break anything at all, especially in the case of one of them, which has been problematic from the beginning up until recently, but I'm fairly certain that they wouldn't affect the desynchronization between the server and the client when the block has the ability to rotate.

[Animefan8888]

12 minutes ago, Daring Do said:

It would take me a few hours to make all of those changes to one of them, and test it to make sure it didn't break anything at all, especially in the case of one of them, which has been problematic from the beginning up until recently, but I'm fairly certain that they wouldn't affect the desynchronization between the server and the client when the block has the ability to rotate.

Problem 4 takes like 30 seconds to do as well as problem 10(setUnlocalizedName(getRegistryName().toString)) and 14. 5 Might take upwards of 4 to 5 minutes. To apply to one Block/TileEntity. As long as you know what you are doing.While you say that your problem is with the rotation, I can't understand how simply having a rotation causes the server to desync from the client when the block is broken. So what you should do is step through your code in your IDE's debugger.

Edited July 13, 2018 by Animefan8888

[Daring Do]

4 minutes ago, Animefan8888 said:

Problem 4 takes like 30 seconds to do as well as problem 10(setUnlocalizedName(getRegistryName().toString)) and 14. 5 Might take upwards of 4 to 5 minutes. To apply to one Block/TileEntity. As long as you know what you are doing.While you say that your problem is with the rotation, I can't understand how simply having a rotation causes the server to desync from the client when the block is broken. So what you should do is step through your code in your IDE's debugger.

See, the thing is... I don't know why either, hence why I'm here. I tried everything I know how to do, and it just does. And again, I said "few hours to make all of those changes to one of them, and test it to make sure it didn't break anything at all". There's more than just changing things, I want to make sure everything works under every condition in which it should work. I don't want to end up releasing a bug-riddled mod, after patching so many since the last release.

 

Unless there's irrefutable proof that those steps would fix this whole problem, I don't want to spend the time messing with it at the moment. That, or have proof that it's related to this problem.

Edited July 13, 2018 by Daring Do

[Draco18s]

You don't need to test any of the fixes from problems 10 and 14. 4 takes literally 30 seconds to fix and test: all you're doing is overriding a different method and removing the implements/extends.  Fix 5 is the only one that takes more than token effort.

 

You can do 4, 10, and 14 pretty much all in one go.

Edited July 13, 2018 by Draco18s

[Daring Do]

You know what? Fuck it. I've been here before, I've only ever gotten shit, and only once ever gotten assistance with the problem I've been having. I'm this close to just saying fuck it to the rotation, and changing the model all together so that rotation isn't an issue. Unlike this shitshow, MDC and MMD both at least try and help with the problems you're currently trying to solve, not point out other ones that you might have, that aren't causing any problems in the current.

[DaemonUmbra]

These are problems you are likely to come back with, and sometimes fixing issues you didn't know you had ends up fixing the issue you were focusing on.

[ModMCdl]

9 minutes ago, diesieben07 said:

Did you even read my post to the end? My last point is the actual problem.

If you really do not care about fixing these common problems: Just fix this actual problem.

 

11 minutes ago, DaemonUmbra said:

These are problems you are likely to come back with, and sometimes fixing issues you didn't know you had ends up fixing the issue you were focusing on.

Thank you for the help. I'd like to apologise for my partner's behavior. Can you explain why you'd recommend the aforementioned changes?

Edited July 13, 2018 by ModMCdl

[Draco18s]

26 minutes ago, ModMCdl said:

Can you explain why you'd recommend the aforementioned changes?

Problem #4:

ITileEntityProvider is outdated, still using numeric metadata as a paramter, rather than a fully defined IBlockState

For BlockContainer, it will cause issues, as BlockContainer overrides several methods of the block class that it is very unlikely that you actually want to override, such as what model type your block uses. 90% of TileEntity blocks do not need a TESR, but BlockContainer sets the default model type to INVISIBLE in preparation for a TESR.

 

Problem #5:

IInventory is deprecated in favor of more flexible and inter-mod compatible Capabilities.

 

Problem #10:

Quote

TileEntity registration names and enum entries added using EnumHelper should contain your ModID to avoid collisions between mods.

 

Problem #14:

You cannot control the order of execution when dealing with static initializers. As a result you can have objects created before the other objects they depend on (e.g. a CreativeTab that gets created with a null item icon, or an item that gets a null creative tab).

Edited July 13, 2018 by Draco18s

[Animefan8888]

18 minutes ago, ModMCdl said:

Thank you for the help. I'd like to apologise for my partner's behavior. Can you explain why you'd recommend the aforementioned changes?

I can answer this question in their steed if you don't mind.

• 4 " These classes are legacy vanilla code. " Old unnecessary code. just override hasTileEntity(IBlockState) and createTileEntity(World, IBlockState).
• 5 Intermod compatibility. IInventory is provided by Minecraft and Forge has provided a system that works much better. The old system has been shipped away since the capability system was first introduced.
• 10 They can conflict with other mods, however a modid is unique to your mod(hopefully), thus removing the conflict. A good strategy would be to set unlocalized names to the registry name.
• 14 Static initializers are immpossible to control. You do not know when they are initialized, so therefore forge cannot assign the modid for the registry correctly. There are also other reasons for using the event system, but there are too many and I don't want to type them out.

• 1 hour ago, Daring Do said:

  Do not use that "re-use the tile entity" hack that the vanilla furnace uses. Override TileEntity#shouldRefresh.

  Less code and uses a method in the TileEntity instead of some method in the Block class.

• 1 hour ago, Daring Do said:

  You are not retaining the BURNING property in metadata. You must serialize and deserialize all properties that are not stored elsewhere (and set via getActualState) in getMetaFromState resp. getStateFromMeta.

  Self explanatory, but it saves and loads the blocks metadata/blockstate correctly.

Now on to your problem with the de-syncing. If you remove onBlockAdded and onBlockPlacedBy it will fix your issue.

[Daring Do]

Okay.... so yes, I was wrong, but now clicking on the block causes you to hard crash. I got upset, and I apologize. I really shouldn't have. I just _really_ hate having to make changes like this to blocks with tile entities, as normally they just break entirely, which this moment kind of reinforced just then.

 

Other than the IItemHandler bit and the changing of the BURNING variable (which I wasn't done with, I was just trying to solve this problem first), I've done all that was in there. Reason for not doing the IItemHandler bit is because I don't understand jackshit when it comes to that. I work better with seeing examples, tearing them down, and analyzing them. It's entirely possible that's the reason it's crashing, but I have no idea how to fix it (and yes, I did read the information provided on it, it only left me more confused). I've gone ahead and updated the code, but I have to go for the night.

 

Again, I'm really sorry for lashing out like I had..

[Draco18s]

Here's an example of an ItemStackHandler in use:

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java

 

the outputslotwrapper is used for the GUI so that the player can't insert items into the output slot (but the machine can still do so when it generates its output). Predominantly you will want to look at getCapability.

[Animefan8888]

12 minutes ago, Daring Do said:

I've gone ahead and updated the code

Github hasn't changed except for setState and the implementations being changed.

shouldRefresh should compare the two IBlockStates parameters past in and return a value from that. aka if the blocks are not the same.

12 minutes ago, Daring Do said:

but now clicking on the block causes you to hard crash

Override hasTileEntity(IBlockState) instead of hasTileEntity()

12 minutes ago, Daring Do said:

but I have to go for the night.

Have a good night.

Edited July 13, 2018 by Animefan8888