jeffryfisher

What version of Minecraft and Forge?

See vanilla examples. Make something like one of those (both code and resources). Register it. When you run in Eclipse and MC crashes, look for past threads having the same or similar errors. Rinse, repeat.

Yuck... That'll be a joy to fix when I do my next upgrade. I must confess I'm still in 1.10.2. I'll probably play catch-up when 1.12 has a stable Forge release.

You shouldn't need to mess with packets. As long as your TE writes and reads NBT consistantly, you should only need to mark the TE after changing its data. The vanilla logic should then handle the rest. If you're curious to learn what "the rest" is, then the best way to see it is in the debugger as it executes rather than by trying to trace static code. It's way more difficult to sort the client versus server paths in static code. It's way easier to see how the paths work when you can actually step through the real thing. Set a couple break points and let the debugger take you on a guided tour.

In other words, your common proxy may implement an interface, but it should not itself be an interface. It needs to be a (non-abstract) class.

The mesher is a tricky method called during init. Used by vanilla but now discouraged for mods, it's tricky because certain things need to be called in a certain order (and the client side-only proxy is involved, which separates some of those statements in code space). I believe that Forge created the custom location method because it's much less fragile. Note that it's called during preInit, not init. The threads discouraging mesher use run like a rash across this forum going back almost 2 years. Any modder facing any rendering problems should have come across them when searching for answers to avoid posting repeat questions. That's why Draco sounds frustrated: When someone shows up here using the mesher call, it means that the modder's scholarship stopped at a long obsolete tutorial without reading any threads written in the last 22 months.

See the blockstates and model JSONs for cauldron

Other considerations: If any players use creative mode, then they might set time to zero as a way to move the sun to sunrise. That'll foul your time-keeping. Also: Time can roll over. Its design only needs to cover a cycle of moon phases; I don't know how much larger its range might be. Before relying on the tick-counter for long-term aging, you should look at its range and decide what to do if time ever appears to have gone backward.

Those hash-named files are tedious to work through. I found a jar file that I can open using 7-zip. In my system, the jar is in C:\Documents and Settings\<username>\.gradle\caches\minecraft\net\minecraft\minecraft... Edit: But I don't see sound files in there. My work has been with textures, models etc. Never mind

Rather than "gradle build", try gradlew build (run the script that came with the Forge installation). And, I don't know what Eclipse might be doing to gradle, but be safe by opening a command window and running the gradlew script from a command prompt.

Can users fake it by adding virtual memory? Then unused models would be paged out.

See how doors work.

The anvil does not look at crafting recipes. In each item class, you need to override public boolean getIsRepairable(ItemStack toBeRepaired, ItemStack ingredient) to return true when your item is offered the right ingredient.

You have a folder called "assests".

Looks like you neglected to provide an "inventory" variant.

It's probably starving for memory and swapping. To run that long, it might even be thrashing. See if you can allocate more RAM to the JVM (but if you don't actually have the RAM, then it might blow its stack instead). Google to find other threads with similar issues.

I suggest that you explore the features of Eclipse to see what it can do for you (the web has tutorials). When you discover the many ways to select elements of code and jump to them, try them out on all the vanilla Minecraft elements you can, starting with GameRegistry. Look through it to see what public methods exist for registering items. After sufficient explorations, that will no longer seem to be a bit complicated.

If your recipe used ingots instead of swords, then you'd start with the ore (+ gems, dust & ingots) library. If you look into it, maybe you can see a way to add a raft of swords to it. As for tool materials, you could try analyzing the enum during postInit to see what mod materials were injected by other mods. Your polearms will probably need their own material definitions, but checking for other mods might tell you which will be in use.

If you have installed others' mods but are not writing your own, then you're in the wrong forum. Contact the sources of your mods with a bug report. Then they might come here with specific questions about Minecraft Forge. We can't help you to run a buggy mod.

In Eclipse, you can even click on that line number to go directly to the offending line.

As has already been mentioned, Minecraft already lists TEs. Try to avoid reinventing such wheels at the core of the game.

Try to be efficient about how each one decides that it has nothing to do (yet) and then returns. If that runs smoothly, then you don't need to make more coding for yourself (and risk introducing bugs).

At the time I looked at your block's code, it was fetching the TE to get the value of "active". It shouldn't need to do that. In fact, the TE might not need to hold onto that either. It knows its own pos and should fetch its co-located blockstate to find out (and to verify that the block in place is still the furnace that it belongs with). The block should be able to know it's active by using its own bs / metadata. At most, it should be telling the TE about changes (and Choonster pointed at a useful method). Look at your code where the block decides whether to become active / inactive. Pretend that the TE isn't there to help you (unless the block actually needs TE data about inventory or smelting progress -- but I didn't see any such factor in the decision). Do you see it now? I don't think you need to fetch a TE to tell you that you're active when your own metadata should know that much.

Xray mods are considered cheating almost everywhere, so you might not get help here (and this thread may be locked as soon as an admin sees it).

Agreed. First write the equivalent of a "Hello World" Forge mod in 1.11 (create a block and put a texture on it and its ItemBlock). That'll drag you through the new (fragile) JSON paradigm (NB: Ignore the mesher mentioned in obsolete tutorials, and make sure you learn the Forge's advanced blockstates JSON format). After you've done that, then write a new mod using your old one as if it's a design spec. Work from the easy parts toward the deeper constructs (like the packet you mentioned). That's because there's a chance of the more modern Forge having new events / features etc that will spare you from having to "hack" as deeply to accomplish your goal(s). What does your mod do (from a player's point of view)?