ChampionAsh5357

That's because there is no loot item condition for if the item belongs to a given tag. You would need to make your own if you wanted to support this case. See anything that extends `LootItemCondition` and then register it using one of forge's registry methods.

The version you are using is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. Currently supported versions are 1.19.2 (Latest) and 1.18.2 (LTS).

The version you are using is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. Currently supported versions are 1.19.2 (Latest) and 1.18.2 (LTS).

You can get the registry for blocks from `ForgeRegistries#BLOCKS`. From there, you can find a specific block by name via `#getValue` and get all blocks via `#getValues`.

That's because overriding any existing block or item will probably break compatibility with any mod in existence, including Vanilla minecraft. You can edit specific behaviors of blocks or items using events or attach custom logic using capabilities, but you should never override a block or item. I don't have any tutorials, but I typically suggest reading the forge docs or the community wiki and then asking specific questions on the discord server or here on the forums. You are expected to know Java and working on either the latest or LTS version if you want to receive support.

1. Don't use `@OnlyIn`. It is never needed anywhere. 2. You don't need the `PlayMessages$SpawnEntity` constructor nor override `Entity#getAddEntityPacket`. You are not syncing custom information from the server when the entity is spawned. 3. Don't ever use nonfinal static fields as instance fields. That's not how instances work. Please learn Java for that. 4. Layer definitions for models need to be registered in `EntityRenderersEvent$RegisterLayerDefinitions`. 5. Entity renderers need to be registered in `EntityRenderersEvent$RegisterRenderers`. 6. Do not combine client and common code. Separate them into different classes. 7. Do not have use a class for more than one purpose (e.g. `Item`, event listener, etc.). That is separation of concerns and leads to poor programming. 8. If you want stack specific behavior, use a capability. If you want client specific behavior, you can use static or instance fields because any mod instance will only have access to at most a single physical client. Finally, I watched the video on quarter speed and still have no idea what you're talking about. It looks like the bullet is hitting the entity.

Please provide the entire entity, item, and entity renderer class. The above provides no view on the issue. Additionally, there does not seem to be any visual bugs. If you're talking about the inaccuracy of the bullets, that's the result of `Projectile#shoot` offsetting the look vector by some amount. It is much more noticeable with smaller projectiles. Finally, do not use `@OnlyIn`. You should have no need to use it as `ItemSupplier` is not a client only interface.

Within your menu constructor, you need to call `#addDataSlots` and pass in the `ContainerData`. Otherwise, it will have no idea what to sync to the client. Additionally, it's bad practice to pass in state data (`Block`, `BlockState`) in a menu since they are supposed to act as agnostic views for internal data, not for syncing the world data itself. That's why modders typically pass in the inventory or data slots instead of the actual object itself.

Locking this thread under suspicion that user is working on 1.16 and removed the version. Post seems exactly the same as previous.

The version you are using is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. Currently supported versions are 1.19.2 (Latest) and 1.18.2 (LTS).

The version you are using is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. Currently supported versions are 1.19.2 (Latest) and 1.18.2 (LTS).

The version you are using is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. Currently supported versions are 1.19.2 (Latest) and 1.18.2 (LTS).

It seems this issue has to do with the Illuminations Forge mod. Somebody has reported the same error as you on their repo. Try removing the mod and it should work. If not, you can split the mod into separate piles and test each until the erroring mods remain.

First step, remove Optifine. It will probably not play well with the majority of mixins that change the client. Flywheel is definitely one of those cases. If that doesn't fix the issue, split the mods into two piles and try running the game with both. If no error occurs, you can be confident none of the mods are causing the issue. If an error occurs, split the erroring pile again and repeat. You should be able to single out the erroring mod/mods.

The version you are using is no longer supported on this forum. Please update to a modern version of Minecraft to receive support. Currently supported versions are 1.19.2 (Latest) and 1.18.2 (LTS).

Look within `LootItemConditions` for vanilla conditions prefixed with `minecraft:` and `ForgeMod#registerLootData` for Forge conditions. You can look at the wiki articles written for vanilla and Forge as well.

How are you testing whether the event is firing? Are you just opening the game, or are you going into third person so the player renderer is actually called?

Sure, though looking at your code again, it may be whatever custom printer you are using is at fault. Try putting a breakpoint in one of the events and attempt to execute it (going into third person or pressing a key).

You need to set the `modid` field to your mod id in the `@EventBusSubscriber` annotation.

If you are talking about in a GUI, you can sync shorts (0 to 65535) to the client using `DataSlot`s. You simply need to set the value when it updates. Then, on the client (once you have the container add the `DataSlot`), you can read the synced value using `#get`. You can look at `AbstractFurnaceMenu` for an example.

It seems like it wouldn't be an issue since the actual method is already enqueued. The fix seems useless imo since its synchronization in sequential execution. Based on what I'm looking at, I doubt that Configured would be the issue.

It seems both Create Cafe and Twigs are at fault here. They both register to hash maps without enqueue causing the CME. Here are the relevant pieces of code for Create Cafe and Twigs. Reported both as issues on their repos.

It's not possible without a rewrite of the entire Behavior system. Sensors used in `FrogAttackablesSensor` require a generic of at least a `LivingEntity` to set the `NEAREST_ATTACKABLE` entity. `StartAttacking` will only set the `ATTACK_TARGET` to be a `LivingEntity`. `ShootTongue` does allow it to be any `Entity`; however, the logic will only start if the target is on the `ATTACK_TARGET` memory. To replicate anything similar, you would essentially need to rewrite the entire things as goals which have never been used in conjunction with Behaviors due to two systems colliding and confusing how the entity would behave. If you would like to attempt it though, you would need to add a `NearestAttackableTargetGoal` on the `targetSelector` and then some attack goal (e.g. `MeleeAttackGoal`) written for the frog on the `goalSelector`.

The correct way to replace player rendering is by using `RenderPlayerEvent$Pre` and canceling the render before rendering the wanted model yourself. If using the regular player model and just changing the model animations, then you should be fine. If using a custom player model, there are some additional difficulties when it comes to layers since you may have to reinitialize them to supply your own player model for the correct rendering location.

What is the purpose of the custom player renderer? Are you trying to rerender the player from scratch, or are you just adding something on top of the original model?