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.