warjort

I would start with looking at the version numbers in the file names. Most mods include the minecraft version (but not all). So something that says 1.18 would be a likely cause. Also since this is 1.19 anything released before July would likely be incompatible.

There are quite a few errors relating to broken datapack files. But I don't think this is your real problem. Your real error is This indicates a misconfiguration/conflict of the modded tool tiers somewhere, e.g. something says diamond is stronger than iron, but somewhere else says the opposite. It won't actually be diamond and iron it will be some other modded tool tiers and the conflict might not be so direct/simple. I would say report this problem to the modpack author, but since you have modified it, you will need to figure out which of the modifications you made causes the problem. The error message does not say which tools are involved, only that there is a problem.

It's never a good idea to just blindly follow tutorials. You need to make sure you understand each step so you can correct errors.

Compare your biome modifier with the one from the tutorial https://github.com/Tucky143/Crystal-Minecraft-Mod-for-1.19/blob/main/src/main/resources/data/examplemod/forge/biome_modifier/add_example_ore.json https://github.com/Tutorials-By-Kaupenjoe/Forge-Tutorial-1.19/blob/main/src/main/resources/data/tutorialmod/forge/biome_modifier/add_zircon_ore.json

This is not something I have ever looked at before, but; Both Wardens and Sculk Sensors implement VibrationListener.VibrationListenerConfig. This class by default listens for GameEvents with the tag GameEventTags.VIBRATIONS. Entities emit vibrations in that tag, see callers of Entity.gameEvent() so you can always override that method to suppress events you don't want to emit. This may have unwanted side-effects if the event is used for other behaviours, e.g. playing sounds However, if you look at VibrationListenerConfig.isValidVibration(), it checks Entity.dampensVibrations() so I guess you can override that method in your entity to return true?

This suggests you have mods that are incompatible with this version of forge. The error does not say which ones.

Conflict between apoli and flickerfix Make sure you have the latest versions then contact the authors.

https://github.com/TeamDeusVult/MagnesiumExtras/issues/26

In the run.bat replace java with the full path to the java 17 java.exe (wrap it in quotes if it contains spaces).

My guess is it's another instance of this: https://forums.minecraftforge.net/topic/113483-mods-not-showing-up-in-game-119 But you can't see the .zip ending because you have file extensions turned off in windows explorer?

https://github.com/TeamDeusVult/MagnesiumExtras/issues/26 The mod name is rubidium-extras

Remove rubidium and its related mods. These broken client side only mods are not needed on the server.

https://github.com/sp614x/optifine/issues/6974

See Slime.remove()

https://github.com/sp614x/optifine/issues/6974

Basic objects like Blocks and Items are always registered first. This is to avoid circular references in the loading/registration. You should change your item constructor to accept a Supplier<MobEffect> or RegistryObject<MobEffect> as the parameter and then use the get() when you need the real object later at runtime.

Yes you need to store the instance somewhere. If you create new ones they are different shouts. Think about if another player starts/stops shouting. They will send messages to the server which will send messages to your client. You need to keep track of which players are linked to which sound instances to handle this properly. As I said above, a player capability would be a good way to store this data. WARNING: You would need to be careful that any server side code of the capability doesn't try to load the SoundInstance class, e.g. by wrapping the sound instance in a holder class that only gets used on the client.

No, you need a different instance each time you start a new sound. What if there are 5 players shouting at the same time? That's 5 different instances. You shouldn't be including gui code in that sound instance code. The sound instances could/will be for other players. I think you need to step back and think/understand how this should be working in a multiplayer environment. e.g. maybe you could have a shouting capability for players with its own network events to make it easier to model.

You don't call the method yourself. You override the method in your Screen to trap the keys you want to process. See for example ConfirmScreen.keyPressed() or one of the other vanilla screens.

If I understand what you are saying correctly, your instance can never be active at that point, you just created it. I don't see anything in the api that lets you check if a different instance with the same sound is playing. But it should be easy for you to keep track of this yourself?

You need your own RecipeBuilder like vanilla has for its recipes.

A naive implementation yes. 🙂 You just make the flag on the player something like NOTHING, NEEDS_ADDING, BEING_ADDED

The crouching is not controlled by the player's Pose. It is handled by the logic in LocalPlayer.aiStep() which is hardwired to check the isShiftKeyDown() I guess you could hack something in the MovementInputUpdateEvent? But you can't just set shiftKeyDown = false, because the isCrouching check is done before that event is fired. I can't see a clean way do it other than using an access transformer to be able to change the LocalPlayer's isCrouching field?

This is indeed recursive death. That method is meant to decide if you want to block a potion effect. Possible fixes include; * A hack with a ThreadLocal to spot the call is your addEffect() invocation. * Instead of applying the effect directly, defer the addition by remembering some flag for the player and doing it in a player tick handler on the next tick.

This is a crash in a native library. It looks to be related to the physicsmod Contact the author.