DavidM

Have you tried it without mods?

Please post the crash log.

Then use Jarfix to associate the opening of the jar file with Java, or run the jar via the command line.

Economy-Inc-Mod's problem. Remove it and report to its author.

Install Java.

This is normal (well kind of). These are obfuscated names that do not have a MCP mapping in your mapping version. You can fix this by updating Forge.

Problem with Bonsai Trees 2.

Please read the EAQ and post logs.

How did you know that the capabilities are being reseted? Where and how did you debug?

Unlikely. There is always a log to post. If you are unsure, please read the EAQ.

Proxies are not necessary in this case. The event provide you with an instance of World; use World#isRemote (which returns true on client and false on server) to check what side you are on.

I used an assortment of guessing, looking at vanilla usage, and looking at the code in the obfuscated method (I didn't realize the MCP names were in place in the latest version at that time). AFAIK the only thing that changes across minor versions is the build.gradle file. To update, simply download the newest mdk, replace your build.gradle with the new one, and edit it to fit your need (add mod id, dependencies, etc). Make sure to re-import the workspace after that.

“My entity renders as a pig” means that the outcome of the entire render is a pig. In this case something is terribly wrong (incorrect entity data, possibly caused by not sending the entity creation packet to the client properly). Meanwhile, “my entity’s model looks like a pig” means there’s something wrong with the model. These two problems are drastically different. I would recommend to elaborate on the problem in the future to prevent misunderstanding. In this case, the misunderstanding caused diesieben07 to spend a lot of time tracking down a problem that didn’t exist, which would be frustrating to anyone.

1. How is hacked clients related to the animation at all? 2. Check out LivingEntity#swingArm, including the client’s receiving of SAnimateHandPacket. Also look at ClientPlayNetHandler#handleAnimation.

PlayerTickEvent. Make sure you are executing the hunger changing code on the server side (read up on Sides in the documentation if you are unsure).

There is no 1.15.2 version on that page.

That is not how you get an instance of the server world.

Because it is not necessary in this case.

You cannot make sure there is no desync, as the server will not tell you if the attack entity attempt is successful or not. Why does the desync matter though? What does your mod do from an end-user's perspective? If you want to create an animation of the arm swing it would be much easier to do it from the server side (attack the entity directly, and then send packet to the client to tell it to swing the arm).

What is "dc"? What are you trying to do?

Stacks in rendering is something like: Each matrix in stack holds a series of transformations (position, rotation, scale). When you render something, it undergoes the transformation of all recorded transformation in the stack. When you pop a matrix (let's call it matrix A), it removes all the transformations after the pushing of matrix A. For example (pseudocode): pushMatrix(); translate(3, 0, 2); // move 3 units on x axis, and 2 units on z axis renderModelA(); pushMatrix(); rotate(180, 1, 0, 0); // rotate 180 around the x axis renderModelB(); popMatrix(); scale(2, 2, 2); // scale 2 on all axis renderModelC(); popMatrix(); Model A would be rendered with translation of 3, 0, 2. Model B would be rendered rotated 180 around x axis and translated 3, 0, 2. Model C would be rendered 2x the size and translated 3, 0, 2. Since the matrix involving the rotation is already popped at the time Model C is rendered, the rotation does not apply to Model C.

Model controls the entity's appearance; it doesn't control the collision box (which is used in code that handles physics). An entity can have a huge model and a small collision box at the same time. MatrixStack is used to record the transformation of rendering via a stack. It is similar to the stack manipulation of GlStateManager in earlier versions. An example of updating from GlStateManager to MatrixStack is this. As for the obfuscated names, you should update your Forge to latest. The mapping has been updated in the later versions (I was using 31.1.0 and experienced the same thing).

C# and Java are very similar syntax-wise. Java would be very easy to learn if you are familiar with C#.

Kind of. However not only references change across versions, but also concepts, practices, and the way the game works. You will have to change a lot from 1.12 to 1.15 (almost completely rewriting). Yes. No. 1.13 is very different from 1.12. This still will not work. In general, mods across all versions will not work with any other version of Minecraft. They are fundamentally not compatible. There might be exceptions such as 1.15.1 -> 1.15.2, but that only works if the Modder is lucky and never use any code that was changed in the progress (which rarely happens).

... No. This WILL NOT work. Changing the FML version will fool Forge into loading the mod, but mods across versions are not compatible AT ALL. The codebase for 1.12.2 and 1.15 is completely different, and mods in 1.12.2 use code that no longer exists (or work the same way) in 1.15. This will result in a crash.