jeffryfisher

Some houses are built as if they have tree trunks laying horizontally. Do you want those logs replaced too (for appearances), or just living trees (for some behavior)?

You may also use instanceof in comparisons where any subclass will do. If some mod makes a custom bed by extending the vanilla class, then an '==' would only match the vanilla bed and not recognize the mod one. What you choose depends on what you're trying to accomplish.

Da, try your test again with sword in main and torch in off-hand. See what gets printed. To really see how it does this, get into the debugger and step through (and into) it. You'll see the decision(s) being made.

A rail is a block, so it's not far at all. Make a custom block that extends the rail class (or its base class). What's far away is the minecart entity, which I told you to study. What did you learn? Yes, and I just read it again to be sure. You found a tutorial but gave no indication that you had completed a simple mod. Perhaps your writing is not as clear as you imagine. Others have played with rail mods. Try to find an example at github.

Many mods have been put up at github. If you Google this forum for github references, you can follow the links to see examples of what other modders have done (some are better to emulate than others).

If one of those long steps includes a call to another method, then step INTO it instead of over. Drill down until you find yourself somewhere you shouldn't have gone (like loading and unloading huge piles of the same data again and again). Do whatever it takes to get over your debugger-phobia. Stop making excuses; just get inside the bloody program to see what it's doing while it's doing it. Learn the features of the debugger so you can use it effectively instead of giving up with a vague "every step takes too long". What was it doing? Why didn't you step into the call(s) to see why? Get in there again and drill down until you find the problem.

As usual, mysterious runtime behavior demands an investigation in the debugger. Set breakpoints that will stop execution when you reach the problem stage of the game. When you get there, then set more breakpoints in methods that you want to why they're even being called. When they hit, look at the call stack. Home in on your problem from there and do some stepping. If chunk gen is really running away, then the "why" should become obvious after an iteration or three.

I highly recommend that you complete a simple mod as an exercise before venturing into more creative territory. There are plenty of mistakes you can make in the simplest of mods, so you should make and learn from them so your later work will be less frustrating. Then when you investigate rail, look into both rail blocks and minecart entities. You may discover that the behavior you need to modify is programmed into the cart, not the rail.

Actually I do. I want to see more people post what they see when they STEP line-by-line through their code (and affected vanilla code) surrounding mysterious run-time behavior. It's often quite illuminating. Inexplicable runtime behavior should send you to the debugger before it sends you here. And yes, there are other debugging techniques to instrument your mod so you can learn what is happening inside of it.

How many times have you stepped through this in the debugger to see what it's really doing? What did you discover?

I think that positioned sound is a client-side only class. Have you stepped through these things in the debugger? Actually walking the processes will clarify the client-server architecture for you. Even if I could remember every detail, I couldn't write in words what an execution walk-through can show you. Please step through these processes in the debugger.

Some of the vanilla sound methods run on the server and send packets to all listeners (players). Other methods act like renderers, only existing or running on the client, often downstream from the packet handlers. Unfortunately, much of the naming is similar, so Minecraft's sound system is confusing. IIRC, PositionedSound is client-side only. You need to analyze these classes and then organize your code so that you make decisions on the server that cause sounds to be rendered on the client. In many cases, you do not need to design your own packets and handlers; vanilla will handle that for you. I recommend setting some breakpoints and then stepping through the process for some vanilla sound in debug mode. That'll show you in a hurry what calls what where. You should also read about sound in the Forge docs.

Use your IDE to jump into the class to see what constructors are really available.

You can Google for "github" at site:http://www.minecraftforge.net/forum/topic You can go to github and then search for Forge projects. Stick to mods using the same version of Minecraft (1.12.2). After looking at a few, you'll quickly distinguish between matters of style versus matters of necessity. You'll also quickly get a sense for who knows what he's doing (and who knows even less than you do). Once you've settled on one or two worthy examples, emulate them (don't cut and paste). You learn by assimilating and doing. Finally, when you are getting ready to run something, run it in debug mode (with some break points set within your own code). Step through and into the various methods, examining some of the changing fields as you go. More than any static examination of vanilla code can ever teach you, a ride-through will illuminate how the program functions. Try to scan each operation at least once so you have some idea how it hangs together. No need to sit through 500 cycles of a loop, but try a few at least once. And have fun.

onItemRightClick gives you a Hand, which probably holds a stack. I think you can operate upon the stack (e.g. decrement its count) and then return it. If count reaches zero, then you may return the empty stack.

I see "core" in your mod name. Core mods often don't fare well in Forge. Last time I heard, core mods were not supported in this forum.

If you don't understand 7's 2nd bullet, then you must learn Java (elsewhere). Expect this thread to be locked.

IIRC, LWJGL = LightWeight Java Game Library Are you missing LWJGL or a DLL it needs? But it should have emitted an error if that were so... Maybe there's a version mismatch. Did you install on top of an earlier (or worse, a later) version of Forge? I think you showed us console output. Have you dug up the actual log files? They contain more gruesome detail, so there might be a further clue.

If you still have problems with the CurseForge web site, then you'll probably find more info there than you can here. This is a development help forum, not tech support for remote sites.

I think that isRemote means you're on the client. Perhaps you want !isRemote?

Did you consider extending dirt instead of the generic Block class? What issues did you encounter?

Start by learning Java (elsewhere, there are many online tutorials), which you should be able to do in a couple weeks. Then install Forge's development system, described in detail elsewhere on this site. Don't worry, you shouldn't be asking for code to be spoon fed to you, so you won't need to be told where to put any. However, what you can do (after learning Java and installing Forge) is to Google for Forge mods at GitHub. You can see code and how it's organized by successful modders.

Another thought: In what instances is farmland generated? Isn't it only as part of a village, and then always with crops on top? If so, then there should be event in that process that gets you closer to what you want to affect.

What do you want to have happen when a player uses a hoe to turn dirt into farmland? Once upon a time, there was a block substitution system in Forge, but there were bugs in it. I wonder if it was ever fixed...

Set a breakpoint in getActualState. Use the debugger to step through / into the decision processes to see where the errant state is being made.