warjort

By the way, the method you are using to change the biomes won't work in 1.19 The biomes are now stored in a PalettedContainerRO (RO = read only)

For the same reason, you can't use net.minecraft.world.level.biome.Biomes.SNOWY_TAIGA You have to look it up in the registry. Sorry, its a ResourceKey not the actual biome. 🙂

Not create, it is createcafe, a food mod. 🙂

You won't be able to use the builtin registries for biomes at runtime. They are just templates. The ones actually used are found using MinecraftServer.registryAccess().registryOrThrow() These are copies of the builtin ones augmented with the stuff from datapacks.

https://johann.loefflmann.net/en/software/jarfix/index.html

Can you confirm the packet is received by the client. If it is, I would guess there is something about the way you are updating the data that means the code that creates the packet cannot see your change? You should try deserialising the packet after you create it to see if the data it contains is correct.

Are you sure the player is correct? You should really be sending to all players that have that chunk loaded. Maybe get the list using something like (I am not sure this is correct)? List<ServerPlayer> list = serverLevel.getChunkSource().chunkMap.getPlayers(chunkPos, false); You should also be able to see if your chunk packet is actually received on the client if you listen for forge's ChunkEvent.Load

I still don't see a lootTables.put() in the above code?

For the torch rendering, not really my area of expertise. But you are using RenderType.translucent() while vanilla uses RenderType.cutout() https://github.com/Mattah12/Kanohi_Craft2022/blob/62dac5df0ba4f7e5e381ef78e01050721ed2dcd8/src/main/java/com/Mattah12/kanohicraft/setup/ClientSetup.java#L21

For the loot pool stuff, you create your builders here, but don't do anything with the return value? https://github.com/Mattah12/Kanohi_Craft2022/blob/62dac5df0ba4f7e5e381ef78e01050721ed2dcd8/src/main/java/com/Mattah12/kanohicraft/datagen/KanLootTables.java#L26

To answer your question directly: Level level = player.level; BlockPos pos = player.blockPosition(); boolean isAir = level.getBlockState(pos).isAir(); But I think you need to familiarise yourself with the main minecraft classes. The above is basic stuff, but it might not be what you really want. e.g. maybe you want one of the level.isUnobstructed() to check for blocks the player can walk through

You need to use forge-40.1.57 if you want to run optifine. Until it updates. https://github.com/sp614x/optifine/issues/6974

Uninstall Optifine, you don't need it on the server.

Your actual error is Which is the radium mod. If you only get the problem when mekanism is loaded then they must be conflicting with each other in some way. Check you have the latest versions of these mods, then contact their mod authors.

I reported this issue so it doesn't get lost: https://github.com/MinecraftForge/MinecraftForge/issues/8853

There is no compatible optifine version. forge 40.1.58 (released yesterday) changed a method signature that optifine uses. So its either use forge 40.1.57 or remove optifine until it updates. https://github.com/sp614x/optifine/issues/6974

Click on your "mod pack" (the image not the play button) In its main screen there are three vertical dots next to the play button, click that and select "Profile Options". Change the forge version in the advanced settings.

Looks like this issue: https://github.com/sp614x/optifine/issues/6974 Temporary workaround is said to be use forge 40.1.57 Always try removing optifine if you have strange bugs. It will probably fix it. 🙂

The mod that springs to mind for me is: https://github.com/BlakeBr0/ExtendedCrafting

The end of your log says it set the user fine, the last thing in the log is initializing the graphics. You really need to post the logs/debug.log so we have the full information. But an error at this point usually means a problem with your graphics driver (check it is up-to-date) or your monitor settings. What error code does it tell you in the launcher? Also, look for a file starting with "hs_err_pid" in your minecraft folder, that would show the error if it crashed in your graphics driver.

Ok, that respawnPosition is not what you think it is. It is It lets a block decide where to place the player if they happen to respawn at that block.

You can't just teleport somebody to their spawn. The location might be in a different dimension. Which needs special handling. In the vanilla code, this is only done when the player dies which effectively creates a new player as they respawn.

What is the code you are showing? The ServerPlayer.getRespawnPosition() method looks like this public BlockPos getRespawnPosition() { Note: the result maybe null if the player hasn't set their spawn.

Yes, its looks like a bug to me. Its actually only kind of related to the dimension. The forge code has an optimisation beyond vanilla that checks if the "target block" is actually loaded into the world before doing anything. https://github.com/MinecraftForge/MinecraftForge/blob/05297fd72fa99e9ff020fee3ee365ad51bcaf8f0/src/main/java/net/minecraftforge/common/ForgeHooks.java#L1106 The issue is, it looks like this check is getting used before the block has been determined. So it is checking if 0,0,0 is loaded. This usually will be for the overworld (spawn chunks) but might not be in the nether. It works for me at 0,~,0 in the nether, but not at 1500, ~, 1500 This will be why it works in a different world for you, 0,0,0 is loaded there. Report bugs here: https://github.com/MinecraftForge/MinecraftForge/issues

Actually, you will probably be better off doing it the processResources. So it doesn't even get copied into your build folder (used by runclient)