Leaderboard

This is SideOnly(CLIENT)

3 hours ago, everything we push is automatically built and put on our file server. Read the changelogs to be sure.

Fixed: https://github.com/MinecraftForge/MinecraftForge/commit/52702e5cc9c629b3b2baff6a726aabb168aced16

Patience young padawan, all will be revealed in its time. Learn programming first, in any language. If you want to learn more than is in the course syllabus, then go to your professor and request extra reading, online tutorials, personal instruction, guidance to the right follow-up course (including independent study) etc. Speaking of guidance, that's what guidance counselors are for. Both professors and counselors should be thrilled to see a student latch onto an internal motivation, so you have a high probability of receiving advanced, possibly off-catalog instruction... but you need to pursue it. If you're burning my tax dollars, please get my money's worth by making my volunteer work here easier.

Now, its because vanilla is dumb and doesn't convert down like it should. Go find a tool called midas {if its still around} to mass convert your save. You can talk to mezz if you want the fix backported. TLDR of this issue is that Observers break from one of our fixes to the vanilla bug of doors/other blocks breaking. Because Mojang wrote the block special.

Just a little note. The new observers placed with forge 1.12.1 with the fix, changing to vanilla are alright! They work properly But the old ones placed since the forge in 1.11.2, changing to forge 1.12.1, and then to vanilla 1.12.1, just doesnt update They keep being frozen (The same problem). I dont know if you can update the forge of older versions, but it would be great if you can fix it! I just think its cause in forge 1.11.2 the fix isnt done, its only in 1.12.1, so , it seems that only the observers placed in forge 1.12.1, will be alright, but the old ones wont.

Damn, really, really thank you! Im glad you made the fix so fast! ^^

Some of the issues with your mod is that you are trying to register everything incorrectly: You are only registering them on the client You are registering them in init, not using the Register<Item> event You are only registering the textures, not the blocks themselves on the client Why, why, WHY are you using proxies just to call methods in other classes? Your project is a mess, just calling 1 method which simply calls another and another... Your Main class does nothing except call methods inside the proxies, which in turn mostly do nothing (you have the proxy do something on pre-init on the client, init on both and nothing else)! This makes everything almost unreadable. LEARN JAVA. Then, come back and start from scratch, follow the example of other (well written) mods, and ask for help with forge modding issues when you need it. One of the most important things to learn is how to understand your errors, learn to read and understand the stack trace, you shouldn't need to ask others what the problem is (Although in this case, as Choonster pointed out, you can't see the stacktrace for the actual error without setting a breakpoint).

Use World#getCollisionBoxes(Entity, AxisAlignedBB) to get all Block and Entity collision bounding boxes that intersect with the specified AABB. Use World#collidesWithAnyBlock to check if the AABB intersects any Block collision bounding boxes.

Use RenderLivingEvent#getEntity to get the entity being rendered, check if it's the client player (Minecraft#player) and then cast it to AbstractClientPlayer before rendering the ears. Since you're only rendering this for a player, it's probably best to subscribe to RenderPlayerEvent.Post instead of RenderLivingEvent.Post. This is only fired for players rather than every living entity.

As jeffryfisher said, you need to read up on how Java and IDEs work. Oracle have a set of official Java tutorials here that might help. Your IDE should have some documentation on how its debugger works. When you set a breakpoint on a line, you're telling the IDE to pause execution of the code once it reaches that line (and optionally meets some arbitrary conditions, but you don't need them here). This allows you to inspect things like arguments, local variables and fields and execute code in the context of the line it's paused at. Breakpoints are only hit when the program (Minecraft) is running in debug mode. When the breakpoint is hit, you should be able to hover over the Throwable argument of the method in the anonymous class (the one you set the breakpoint in) and look at its value. Alternatively, there should be a window that shows you the values of various arguments, local variables and fields in the current context. In this case, it's probably easier to change the breakpoint so it doesn't suspend (pause) execution and instead tell it to log the Throwable using FML's Logger when it's hit (i.e. call Logger#error(String, Throwable) on FMLLog.log) , this will print the full stacktrace to the log.

From what I just tested yes translation does work

Yikes! See the forum rules (like the part that says "This is not a Java school...). Do yourself a favor and go learn enough Java so you are never tempted to offer that excuse again. You should arrive here comfortable enough with Java and Eclipse (or other chosen IDE) so that you're up to learning Forge in the programming jargon that volunteers are using. If any of the words or concepts are mysterious to you, then you should go out of your way to Google and read before asking for more effort to explain prerequisites.

I'm guessing this is for 1.11 (I'm not sure if 1.12 is different) Did you register your sound with GameRegistry?

I dont want to act child-ish or anything simmilar. But this is a bug that SHOULD be fixed, and well, at least I think this has affected/affect/ will affect a lot of people, so please, take atention to this post.

The class you need to set a breakpoint in is a part of FML, not a part of your code. Open the LoadController class, navigate to the constructor, set a breakpoint in the handleException method of the anonymous class and then run Minecraft in debug mode. When the breakpoint is hit, look at the value of the Throwable argument of the method to see where it was thrown from.