ChampionAsh5357

Since the log doesn't contain anything useful, you might want to look at the resource monitor to see how much your game is using or profiler your own client instance. It'll probably provide better insight as to what is going on.

Ok, so you're just calculating partial tick yourself instead of using the one provided by vanilla.

Probably start by removing this mod and removing any additional mods that error after testing again.

You have a bunch of missing dependencies. Additionally, remove OptiFine. The version you have does not support Forge 1.19.3.

Flowing? No. Spreading fire? Cancel the FluidPlaceBlockEvent on the forge event bus.

There are replacements that are better for mod compatibility like rubidium. Otherwise, take out any mod that tries to do any custom rendering.

Ok, I found what you're talking about. At no point does the wiki say to make the arm pose in a method. It should say it's a constant though so that the field is created at the class level.

Yeah, that's wrong. You should only be creating the arm pose once; specifically during the mod initialization. Creating it multiple times dynamically will confuse the enum and it will have the incorrect information associated with it.

The #toBytes method must write the bytes in the same order as PacketSyncTeleporter2S(FriendlyByteBuf) reads them. Otherwise, you are reading inaccurate data which could affect some of the results.

Are you sure the block entity on the client has the correct position? Additionally, you're reading the sent data to the server incorrectly. The order you write the bytes must be the order your read them.

Why? It points out mistakes and provides constructive criticism. I like having this information so I can fix things and get other perspectives (Lex, Curle, and sci are typically the people who do this with me). Personally, I would like if more people did it on the docs though.

Not really, since there is no error in the logs to potentially have a guess for.

In general, I would prefer an interface since enums are not extensible without hacky asm (like what Forge does to vanilla enums). Mixing tabs and spaces; also this will error. This is bad practice for two reasons. First, you are constructing the resourcelocation over and over. I would just store this as a field on construction. Second, this is introducing client side asset locations on the server which, in my opinion, is just bad practice since the server should need to know nothing about the client. Public field and getter? Also, should be final and probably an interface for better extensibility. I have no idea what any of this has to do with registering the item. Additionally, the item register isn't event added to the mod event bus. Probably should perform instanceof check first yes. Though, ideally, you shouldn't have to perform a check at all as there would be a base method would consume this such that these costly checks are unneeded.

Could you define doesn't send what you need? From what I'm looking at, all I can see is that you're trying to sync everything to the block entity client when creating the menu, which is an idea and should roughly work, but doesn't help me understand the issue. Additionally, I think breakpoints would be really helpful here so you can view what your own code is doing.

Depending on how you want to make your model, you can either use a json model with ThrownItemRenderer (or a custom renderer if you want some fancy logic, or a java model (you can generate this via BlockBench) attached via a BEWLR.

Makes sense, all of your fields are static, so they would be shared across all instances.

This seems to be an issue with the arm pose which is not shown in the code above. How have you created the arm pose and where are you registering it?

Ask wherever paper provides support. This seems to be an issue with some plugin of theirs.

Well, I would remove this mod first since it says it's erroring.

You need to create it yourself. It is only provided by the example mod mdk.

You're calling the supplier before the objects are registered, resulting in an NPE. Whenever creating constructor methods for registering, it's safest to assume all parameters, except the name, should be supplied instances rather than the raw object.

I would just use PlayerEvent$PlayerLoggedInEvent then and call disconnect from the player there since the connection happens on the server.

Use SavedData instead. No need to do something manual.

So vanilla does this by using a permutation source asset with generates the overlaid assets on top of one another. You could do the same with a model loader or by creating your own source asset by copying the one in 1.20.

Judging by this, it could be an issue with yungs api. However, as the error does not give any understanding as to why it happened, I'm unsure whether this api is truly the root cause.