warjort

There's no error in that log Post a link to your launcher_log.txt on a file sharing site from directly after the crash.

Some issue with it not being able to find or load the SDL2 native library. I suggest you speak to the controllable mod author.

You have mods that are not compatible with 1.19.4 - farmer's delight, ecologics, storage drawers and exotic birds. And you also have placebo which is a mod for Minecraft 1.16.5 ! You need to check the mods you download are compatible with the version of minecraft you want to use. e.g. Farmer's delight currently does not have a version compatible with 1.19.4 https://www.curseforge.com/minecraft/mc-mods/farmers-delight/files

This is not Forge. You need to ask wherever Magma provides support.

Please don't post logs in the forum, use a file sharing site. What you posted is just showing the same as your original. You need to read the documentation/wiki for the spark mod to learn how to use it.

One of your mods is not registering its blocks properly. The logs/debug.log might contain additional information? Otherwise there is no indication which mod is causing the problem. You will have to experiment with removing mods until the problem goes away to find it. Backup your world(s) before removing mods.

This will always replace deepslate blocks with deepslate tin. It is the first test to match those blocks. Since mithril has exactly the same conditions there is no case where it could be used. Similary, for the NETHER and END ores only the first could ever be used. If you really do want to mix these ores together in the same "veins", you will need to write your own Feature whose ConfiguredFeature uses a WeightedRandomList or similar mechanic. Otherwise each ConfiguredFeature will need its own List of TargetBlockStates. By the way, don't just post code snippets in the forums. Post all your code on github that is relevant to reproduce the issue (sometimes we have to run/debug the code for ourselves to see issues that are not obvious from just reading the code).

Yes, but look at how my class overrides getType() to ignore that value and return your own.

https://github.com/MinecraftForge/MinecraftForge/blob/d4f211b81586d24ab6b734c7815fc067579b09b9/src/main/java/net/minecraftforge/client/event/EntityRenderersEvent.java#L93 But as to why it doesn't work, look at the constructor for LecternBlockEntity and what BlockEntityType it hardwires. In general you can't reuse vanilla blocks because of such hardwiring made by Mojang. In this case, you can probably hack it by doing something like (untested pseudo code): public class MyLecternBlockEntity extends LecternBlockEntity { public MyLecternBlockEntity(BlockPos p_155622_, BlockState p_155623_) { super(p_155622_, p_155623_); } // Make this block entity return your type @Override public BlockEntityType<?> getType() { return MWBlockEntityTypes.SPRUCE_LECTERN.get(); } } public class MyLecternBlock extends LecternBlock { public MyLecternBlock(Properties p_54479_) { super(p_54479_); } // Make the block create your block entity @Override public BlockEntity newBlockEntity(BlockPos p_153573_, BlockState p_153574_) { return new MyLecternBlockEntity(p_153573_, p_153574_); } } but such hacks only work when there isn't other hardcoding elsewhere. e.g. you will also have to use an event to workaround the hardwiring of the LecternBlock instance in Writable/WrittenBookItem.useOn() There might be other places?

Look in your logs/debug.log You misspelt farm. 🙂 https://github.com/meme2023/my_mod/blob/838b11405464e28ac3d4f46b9f06adf159b95e40/src/main/resources/data/farmsimmod/loot_modifiers/remove_loot_from_grass.json#L9

Looks like you are missing the obscureapi mod?

You are talking to yourself. 1.16.x is not supported here: https://forums.minecraftforge.net/topic/91712-supported-version-directory/

Don't post snippits in the forum. and what you posted is horribly formatted. It also gives no clue to where those json files are located, what they are called or show all the necessary code (like the registration process). Put your code on github where we can see everything in context. Here's one I made a while ago, explaining all the steps: https://forums.minecraftforge.net/topic/113816-1182-method-for-iterating-over-blocks-belonging-to-a-tag/#comment-505993 although the part about the "block tag loot item condition" is optional unless you want to use block tags.

Something is taking too long on the server thread. The error shown does not say what. At the time it crashed, it was saving entities which might be a clue? Using a mod like https://www.curseforge.com/minecraft/mc-mods/spark to see what is taking time on your server thread.

No. These are the Forge support forums. We help with problems related to the Forge mod loader. We don't fix modpacks or other people's mods. The best we can do is tell you which mod is causing the problem so you know who to contact to get help.

From the subheader of this forum.

You should report it is a bug to the mod author, see my comment above. But I bet this is a concurrency (race condition) issue. It wouldn't suprise me if you try to the load the game again, you don't get the error. But sometimes you do get the error at random? Otherwise you will just have the remove the mod until the mod author fixes the problem.

https://github.com/Shadows-of-Fire/Apotheosis/blob/df983100d374abb0d7ce9cddd82fd78303758ac6/src/main/java/shadows/apotheosis/village/VillageModuleClient.java#L19 This is not the correct way to register entity renderers which is: https://github.com/MinecraftForge/MinecraftForge/blob/547ce9cb7c63d89462f5d3b44495c457ec72dccb/src/main/java/net/minecraftforge/client/event/EntityRenderersEvent.java#L55

Apotheosis "MiningArrow" entity is not registered properly for some reason. Check you have the latest version the contact the mod author.

There is no error in that and its also not the logs/debug.log If that really is the full log, post the launcher_log.txt from directly after the crash. Also, are you sure these mods for 1.19.3 are actually compatible with 1.19.2?

Post a screenshot of the file in your mods folder and make sure you have "file name extensions" enabled if you are using windows explorer. The mod must end with .jar to be loaded by forge. Also post a link to the logs/debug.log on a file sharing site.

I don't know much about forcedPose() but... If you want to set the pose so that everybody sees it, then as was said above you need to do it on the server. That should take care of broadcasting the new pose to everybody in range of the player you changed. But that won't do much for the actual player you changed. The server doesn't usually "control" players. https://forums.minecraftforge.net/topic/119553-1192-solved-cannot-get-passengers-of-an-entity-when-there-are-multiple-instances-of-the-entity-in-the-world/#comment-524427 So you will also need to force the pose on the client for that player you changed, otherwise player.updatePlayerPose() will just reset/recalculate it on the next client tick. When other players are looking at a player they use a RemotePlayer which overrides that method to do nothing. So their view of the pose shouldn't get recalculated on their clients.

Looks like you have something seriously messed up. It is repeatedly crashing over and over again when trying to produce a crash report. Unless this is caused by a mod doing weird things, I would guess there is some issue where the game is unable to create the crash report file for some reason? It is not saying why. e.g. * your disk is full * there are too many open files on your system * there is some file system permission problem with the crash report folder * etc. As a first step, try deleting all the files in your crash report subfolder.

There's only one Biome registry per server. It contains vanilla and datapack biomes, the latter of which includes modded biomes. If you load a different save you get a seperate registry with different objects (datapacks can vary per save/server). In older versions of minecraft there was a BuiltinRegistry that only included vanilla biomes (unless modders hacked theirs into it). It still wasn't the real registry used at runtime. It was the "templates" I referred to in the link above. It doesn't work that way anymore.