Carry On

Carry On

112M Downloads

Mekanism Wind Generator when carry-placed crashes server

XDbored1 opened this issue ยท 8 comments

commented

i am not sure if anyone would support other mods but i think it would be even weirder sending it to the Mekanism guys so i am posting it here anyway hopefully someone is able to fix it, if not i will just find a way to disable Wind Generators

Expected Behavior

Wind Generator is placed without the server crashing

Actual Behavior

Wind Generator is placed and then the server crashes until manual restarted then it works as normal until someone carry-places a Wind Generator again

Steps to Reproduce

pickup Wind Generator with shift right click then place Wind Generator

Version of Minecraft, Carry On, Forge

1.16.3, forge-1.14.4-28.0.46 carryon-1.16.3-1.15.1.7, Mekanism-1.16.3-10.0.15.441, MekanismGenerators-1.16.3-10.0.15.441

attached is a list of .mod files and the actual log file, here is just the section from the end of the error log

[29Oct2020 20:20:06.889] [Server thread/FATAL] [net.minecraftforge.common.ForgeMod/]: Preparing crash report with UUID 494264d6-ea90-4f76-a338-51f2ec741acd
[29Oct2020 20:20:06.892] [Server thread/ERROR] [net.minecraft.server.MinecraftServer/]: Encountered an unexpected exception
net.minecraft.crash.ReportedException: Ticking block entity
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:851) ~[?:?]
at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:283) ~[?:?]
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:783) ~[?:?]
at net.minecraft.server.MinecraftServer.func_240802_v_(MinecraftServer.java:638) ~[?:?]
at net.minecraft.server.MinecraftServer.lambda$func_240784_a_$0(MinecraftServer.java:229) ~[?:?]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_261]
Caused by: java.lang.NullPointerException
at java.util.EnumSet.of(Unknown Source) ~[?:1.8.0_261]
at mekanism.generators.common.tile.TileEntityGenerator.onUpdateServer(TileEntityGenerator.java:47) ~[?:10.0.15]
at mekanism.generators.common.tile.TileEntityWindGenerator.onUpdateServer(TileEntityWindGenerator.java:62) ~[?:10.0.15]
at mekanism.common.tile.base.TileEntityMekanism.func_73660_a(TileEntityMekanism.java:494) ~[?:10.0.15]
at net.minecraft.world.World.func_217391_K(World.java:491) ~[?:?]
at net.minecraft.world.server.ServerWorld.func_72835_b(ServerWorld.java:366) ~[?:?]
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:847) ~[?:?]
... 5 more

latest.log
list of mods.txt

commented

@pupnewfster Thanks for looking into it, I think you might be onto something...
For 1: I think you might be right, but the block is placed before the nbt is read, but I think what might be happening is this: When I save the nbt of the tile, the position is also serialized. When I then deserialize the data, I update the position after the deserialisation call. If a TE is doing stuff with the Tile's position in the deserialisation check (like checkin the sides for pipes or whatever), this would probably be an issue.
I'll try to modify the position in NBT directly and then reading that instead of updating it after deserializing.

2: This is a really good idea. I basically directly ported the mod from lower versions and haven't given it that much thought about using newer features of the game. Will definitely implement that though. Thanks for the suggestion.

commented

Is there any further information? Will there be a fix soon?

commented

I will work on this when I get the time to, sorry. I can't give a timeframe.

commented

For now, you could put the entire Mekanism mod in the blacklist as a workaround

commented

This is probably because I call deserializeNBT instead of read/write. Will need to rethink this.

commented

I have found this with multiple Mekanism machines, there is a way to place it again, but trying to hook it back up to a pipe or anything else, will cause a crash.

commented

A couple things here:

  1. Not sure if calling deserializeNBT vs read/write causes issues (most mods do use read/write, though from the issue linked from Mek's repo, it does seem like the position information is not being properly updated as all the crash reports I have seen of this are in places related to checking the sides of things. On second thought maybe what is happening is that the block is being placed quite a bit later than the tile? In which case the tile could try ticking, and then if it requires information about the block it won't be able to get it as the block isn't there yet.
  2. I recommend (and can make a new issue if it is easier for you), that carryon checks the two following TileEntityType tags forge:immovable and forge:relocation_not_supported, as blacklists of tiles that shouldn't be moved by default, as both Mekanism's cardboard box, and also the packing tape mod, look at these tags to see what things should not be able to be picked up because things can go very wrong (such as wind generators are multiple blocks, picking up a single one and replacing it won't transfer the rest of the blocks properly). Various other mods like IE have also started adding their tiles that can't be safely moved to those tags so it would be a good thing to check. Personally I would recommend making a tag carryon:blacklist or something that defaults to those tags so that pack devs can either block from everything at once, or specifically stop carryon from picking up a tile.