warjort

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)

Just occurred to me. Do you have mob griefing turned off?

On that same wiki you used for capabilities you can read about networking. Here's the main page: https://forge.gemwire.uk/wiki/Main_Page For your requirements, you need to use the PlayerEvent.StartTracking. This is fired when an entity comes into range of the player. Clients only see entities in range of the player. When this event fires, you need to send your capability data to the player using a custom packet. The data would be entityId and your capability serialized as nbt. On the client side you would find the entity (warning untested pseudo code) LocalPlayer player = Minecraft.getInstance().player; Level level = player.level; Entity entity = level.getEntity(entityIdFromThePacket); Then update your capability. Additionally, if your capability data changes, you broadcast your packet to all players tracking the entity using the following distributor strategy PacketDistributor.TRACKING_ENTITY.with(() -> entity) which sends the packet to all players tracking the entity. For other explanations of these concepts see this recent thread. It has a completely different synchronization requirement, so you won't be able to just copy the code. https://forums.minecraftforge.net/topic/113225-1165-syncing-player-capabilities-to-client/

I assume you mean zombified piglin? - gotta keep up with the times. 🙂 It works for me. Tested with forge-1.19-41.0.62 which isn't quite the latest version (63) I tested using spawn eggs, rather than going to the nether, but that shouldn't make a difference. I am looking at the code and all zombie types get the ZombieAttackTurtleEggGoal in their AI.

What .json file were you expecting? Did you edit the eula.txt to say you accept it? It should have told you to do that when you ran run.bat

This also notifies neighbouring blocks they may need to do stuff. e.g. if you output a redstone signal any redstone would recalculate its signal strength.

public void read(BlockState state, CompoundNBT nbt) { this.server = new Server(nbt.getCompound("server"); super.read(state, nbt); } You need to retrieve the subtag of the tile's nbt. The place where you put it. The read/write happens automatically. Except, if you change data for the tile, you need to call setChanged() so minecraft knows it needs to save it.

In general you shouldn't catch Errors yes, they signal a potential unrecoverable corrupted state, that's why I called it a "dirty fix".

Look at net.minecraft.block.Blocks if you want examples from vanilla blocks.

I think you are looking at some old example code? create() should be of() and setLightLevel() should be lightLevel() e.g. new Block(AbstractBlock.Properties.of(Material.REDSTONE_LIGHT).hardnessAndResistance(1f, 3f).lightLevel(blockState -> 15))); Where 15 is the light level

Ad hoc screens don't need to be registered. You only register container screens. Use ClientRegistry.registerKeyBinding() and have it do Minecraft.setScreen()

I believe this error is fixed in latest 1.19 release of forge. But it is not your problem. It was kind of caused by your problem.

note "tile entities" is your name. The game calls them BlockEntityTypes which is not the same as BlockType

Here is your renderer registration, it is not in a loop. https://github.com/StijnArts/All-The-Wood/blob/85e92326aa52affba3c91ef5a81f7ff87e1e20cc/src/main/java/Net/Drai/AllTheWood/AllTheWood.java#L126 It references this singleton https://github.com/StijnArts/All-The-Wood/blob/85e92326aa52affba3c91ef5a81f7ff87e1e20cc/src/main/java/Net/Drai/AllTheWood/modules/TileEntities.java#L14 What it should be using I don't know. You have two fields for TILE_ENTITIES here: https://github.com/StijnArts/All-The-Wood/blob/85e92326aa52affba3c91ef5a81f7ff87e1e20cc/src/main/java/Net/Drai/AllTheWood/modules/SimpleModule.java#L17 One is a static registry, the other is per module but it is of type List<BlockTypes>. Your code looks very confused.

You are missing the l2iibrary mod.

I am calm. "suck it and see" is an English colloquialism. It means "try it, you might be pleasantly surprised". https://dictionary.cambridge.org/dictionary/english/suck-it-and-see

Suck it and see...

This is not forge.