warjort

Yes, that is what I thought. You can Channel.force() or FileDescriptor.sync() to ensure the data is written to disk. Why isn't this done for config files to avoid corruption if you have things like power outages?

It seems to be a common problem that when somebody loses power to their computer that some of the config files get corrupted. e.g. the most recent https://forums.minecraftforge.net/topic/113418-modded-world-not-loading-version-1165/ My question is why aren't the config files forced synched to disk? They are just closed. Using a Closeable here: https://github.com/TheElectronWill/night-config/blob/1d678751747451e3a8458cf12d0ced21b84ebcad/core/src/main/java/com/electronwill/nightconfig/core/io/ConfigWriter.java#L87 It is my understanding that this will just leave the data in the buffer cache, and doesn't guarantee it will be physically on disk. I could be wrong about that and it might depend on the OS? Minecraft uses the following logic where file is a FileChannel - see net.minecraft.world.level.chunk.storage.RegionFile try { this.file.force(true); } finally { this.file.close(); }

Same problem, different file. This time fastleafdecay-server.toml You can repeat the process. If it happens again look at the first line of the error message to identify the problem file.

Problem with your curios-server.toml configuration file, ask for the mod author for help.

The latest version of AE2 is 11.1.4 https://www.curseforge.com/minecraft/mc-mods/applied-energistics-2/files If that doesn't fix it, contact the mod author.

Then use one of the ItemStack.matches() or the equals(ItemStack, boolean) defined by the IForgeItemStack interface. I am not sure of your requirements so you will have to figure out which one yourself 🙂

You want to retrieve the held item on the server. Instead you are retrieving it on the client which will not be the same item stack as the held item on the server. It will be a copy. So == will be false. But I think you actually just need the following return (player.getMainHandItem().sameItem(heldItem)); to check the items are the same type. You are not interested in the stack count or tags?

stillValid() runs on the server, where are you storing "heldItem" when you press B?

Try that, if it doesn't work correct it to the java.exe that exists.

Then you need to talk to AMD support.

When I mentioned neighbouring blocks above I forgot to conclude my thought 🙂 I was trying to point out that you should look for a block that is common to the areas you have a problem with, rather just concentrating on the block you directly interact with. e.g. follow lines of pipes or redstone to see what they connect to. .

This is a crash in atio6axx.dll which is AMD's opengl graphics driver. Check your driver is up-to-date. Sometimes these problems can be caused by misconfiguring your monitor settings into a mode the graphics driver doesn't understand/support properly.

That sounds very cursed. You should know its not just the block you change. It could be a neighbouring block that changes in response to what you did and so on to its neighbours. The block is probably not visible to you on the client if you have that NPE. But the server knows it exists. It would be a "ghost block". You could try to detect it by walking around and see if the server stops you walking into a certain block that looks like air to you.

Removing the mod is a bit drastic when its obviously just a misconfiguration 🙂 speak to the byg mod author about how to fix it.

I am sure many are confused when you used the javadoc convention for naming methods. Hobbiest programmers have probably never written javadoc. 🙂

I quoted "half" because you can ignore things like jei and graphics mods that don't have blocks.

The obvious candidate would of course be the create mod then. Is it possible for you to create a copy of the server and start it without create installed to see if you get the same error in that area? If the mod is not present, it will turn its blocks to "air". I wouldn't do it on the live world unless you have a backup, you will probably corrupt things. If that's not it, the only thing I can suggest is to perform that process for other mods until you find the problem one. An efficient way is to start by removing "half" the mods to eliminate many at once, then repeat with half the mods in the problem group.

I am not sure it is one of those mods. Looking at the error message, the problem is it trying to BlockState.getBlock() where the BlockState comes from a chunk section update packet. The problem is the BlockState is null The block states are actually sent as ints in the packet and then turned into BlockStates using Block.BLOCK_STATE_REGISTRY.byId() That BLOCK_STATE_REGISRY is synchronised with the server when a client joins the game so there should be no way for that method to return null. The client should know about all the block states the server has. Do you have an anti-cheat mod or something similar? These are known to rewrite these packets to hide ores from hackers.

Nope, look at BlockEntityType.BlockEntitySupplier it is create(BlockPos, BlockState) in 1.18.2 Some vanilla blocks entities do have a protected constuctor with a block entity type parameter, this is intended for use by subclasses not for actual construction.

MobRepellentBlockEntity::new is just syntatic sugar. For you it is kind of the same as the lambda expression: (blockPos, blockState) -> new MobRepellentBlockEntity(xxxx, blockPos, BlockState) So you can see your problem is you don't have an xxxx to reference, it should not be there.

You are probably copying example code from the wrong version of minecraft, things like this can change between versions. MobRepellentBlockEntity::new passes a reference to your constuctor, which must match the signature of BlockEntityType.BlockEntitySupplier - the parameter type used by of() In 1.19 that is (BlockPos, BlockState) - see the create() method of this functional interface. Your constructor has signature (BlockEntityType, BlockPos, BlockState), which is therefore wrong.

Not without mixins. It is intended for entities you create. It is used to pass additional data to the client when the entity is spawned. The entity has to implement that interface and understand the packet.

You need a render method in your screen and then use renderBackground() Don't forget to call super.render() after that to draw the widgets. There is also renderDirtBackground() if you want that.

That is an optimisation that has its drawbacks. Using the same code for network/disk serialization makes it easier/less error prone (you don't have to maintain 2 pieces of code that can get of step). You also don't have to worry about some method in your capability referencing data that is not there on the client. Since capabilities are also meant for intermod communication, if another mod wants to use your capability for something else on the client, they may want a different bit of data that you are not sending. But then you can always say you don't support that on the client. In this case, its not relevant since there is only one piece of data and its not meant to be used by other mods.

The mod is probably called rubidium (a port of sodium)