jeffryfisher

I think I'll need an entity to sail on lava (and water). If I can't work with the vanilla EntityBoat, then I won't be able to extend it. That'll leave me copying most of its code, but then maybe I was destined to do that anyway.

So I should copy-pasta EntityBoat into a new class rather than trying to inject a new value into vanilla EntityBoat's enum? Perhaps my lava-going boat is different enough to need that, but I was hoping to re-use at least some of the code.

Minable's offset is a fixed +8 +8 to move away from the problematic north and west edges (south and east always have neighbors already, so it's ok for ores to push into them). Minable does not randomize, so a mod still needs to do that. Some mods don't use WorldGenMinable (perhaps because they must do other work or make other decisions) . Those are the mods that must beware of runaway worldgen and produce their own offset to avoid generating anything along the north or west edge of the given chunk (which would trigger neighbor updates into unloaded chunks, which would trigger more worldgen).

There are many Forge mods at CurseForge, and many of them link to their source code at github. You can learn much from just walking through others' source code, especially if you can find a mod doing something like what you want to do.

For my next trick, I would like to add a new type of boat. Made from my netherworld rubies, it will be enchantable and able to sail upon lava. Almost from the start, I have hit a snag. There's an enum within EntityBoat that looks like something I should extend so I don't need to copy-pasta an entire vanilla class. Looking in EnumHelper, there's no public method specifically for adding a boat enum. The general-purpose addEnum method used by all public methods looks like my way out. However, at least in 1.10.2, it is private There are several directions I can go from here. I am leaning toward using reflection to access the private method inside EnumHelper. What do you guys do when faced with extending an enum not specifically supported by the public methods in EnumHelper? Here's my stub of a new boat class: public class RubyBoat extends ItemBoat { static final EntityBoat.Type TYPE; static final int ORDINAL; static { TYPE = EnumHelper.addEnum (EntityBoat.Type.class, "RUBY", String.class, "ruby"); ORDINAL = TYPE.ordinal (); } public RubyBoat(String n) { super (TYPE); // TODO: Continue from here } }

Are you generating "ore"? Is your generation algorithm triggering runaway worldgen? (If you employ WorldGenMinable then you should be ok)

That's a difficult starting point. You'd do well to do a basic "first mod" from scratch, place textual markers at key locations within it, compile it, and see what comes out the other end of the compiler. Maybe this will give you insight into the interpretation of a decompiled mod. BTW, Why do you want to decompile a mod? There may be easier ways to reach your goal (depending on what it is).

See how structure blocks work and then go from there.

Think about it for a moment... The client displays things. How could it display a new block known only to the server? Servers do not distribute renderers and their textures. In fact, with graphics-heavy mods, it is possible to make a server-only version of a mod by removing its assets folder before compiling it. Indeed, this is what I do for my paintings mod (shrinking the server version from megabytes down to 45k).

Look at how the structure block (new in MC 1.10) in vanilla. Compare that to what the tutorial describes. Tell us if they're the same paradigm. Anyway, you should be able to use structure blocks in a test world to create structure files you can put in a /structures folder of your mod's assets. The rest should easy to figure out.

Komodo "dragons" in Indonesia? If so then there's little relation with the fire-breathing dragons of Northern European myth (especially as resurrected by Tolkien).

Hmmm... I think the conditions need to be a bit more intelligent than that. First, you probably want to attach it to a cave system, so traverse blocks downward seeking solid blocks followed by air. Second, you wouldn't want your block-replacements to break through an ocean bottom that would flood the nest, so design the structure and its placement algorithm accordingly. Since a dragon-sized structure is probably almost never fit randomly into a cave, the structure itself should probably use plenty of air blocks and void blocks creatively to produce the open space you want.

Just don't fall into the mistake of overriding shouldRefresh to simply return false (never regenerate). There are situations when a TE should be cleaned up (e.g. when the new block type isn't the one the TE class supports), so make sure yours is well behaved.

Ah then, that might be a horse of a different color (or class). The server has a notion of "accesses". Look at how the server processes sound -- sound can be initiated on the server and then (a few layers down in its processing) the server loops through the world accesses to send packets to all users. You might also look at how one player's achievement causes messages to all other players. So, if you're trying to make a mod where something happens on the authority (server) and is then told to some or all players, you should be able to imitate one of these processes. On the other hand, if you're trying to write yourself a client-side mod that will tell you where the nearest diamonds are, then we can't (won't) help you.

In texture/model cases, we want to see the client log file. The file has more warnings than the console output, so it sometimes tells us things that the console misses. I'm glad the problem was found and fixed.

I don't understand your fuel-switches at all. What's a "theoretical method"? What syntax is that? I pasted it into Eclipse, and it's all underlined in red. I've simply deleted everything that had no meaning, and this is what I came up with, which has a chance of working: import net.minecraft.init.Items; import net.minecraft.item.ItemStack; import net.minecraftforge.fml.common.IFuelHandler; public class TestFuelSystem implements IFuelHandler { @Override public int getBurnTime(ItemStack fuel) { if (fuel.getItem () == Items.APPLE) return 100; if (fuel.getItem () == Items.ARROW) return 200; return 0; } } If you wanted more than that, please explain (and show more context). Have you thought about using a map (mapping fuel item to burn time)? You could take your time during map creation to figure out what each should be, and if someone changes a config setting, then you could edit a value for a key in your map.

Cave creation seems to work around all manner of custom ores, so you might be able to do your stone variant as a kind of "ore" generation that is restricted by biome. NB: If you generate large amounts of this stuff, just be careful that it doesn't overflow its chunk boundaries (contributing to runaway terrain-gen). BTW, Do you get vanilla coal and iron ore bodies forming in your variant stone? Do you want them? By delaying your replacement until ore-generation, you might also control vanilla ores.

Never mind; it was probably just the reinterpretation of tabs in your OP. I'm glad you found a solution. Note to self: Tell my editor to replace tabs with spaces so that other people see what I see if/when I share code.

Advice: 1) Fix indentation. Your code is hard to read. 2) You don't show the call(s) to WorldGenCedarTree(...), so we can't see if the arguments make sense. 3) Take care with pos; be careful to not spread generation into new chunks north and/or west of the one in which your tree starts (see "runaway worldgen").

When you finally get your project set up correctly, if your door still won't open, try running in the debugger so you can step through your methods and into any vanilla methods they rely upon when you try to open/close a door. Then when you ask for more help, you'll be able to tell us what you saw happening (or not happening).

That's a real problem. Java is a prerequisite for this forum, so you must go learn it elsewhere or have enough programming experience that you can wing it successfully. In other words, claiming Java ignorance will earn you disdain here, not sympathy. Fortunately, the web is a rich source of help with Java, and the Eclipse IDE is a powerful crutch to the new Java programmer. Best of all, you have all of the decompiled and deobfuscated vanilla source code to explore (and Forge source too). Get out there (exploring the existing Minecraft code base) and learn yourself some Java.

Tell us what you saw happening when you stepped into proxy.genInit() in the debugger.

In the future, whenever you get a null pointer (NPE) that's not immediately obvious, set a break point upstream and then rerun in the debugger so you can step through the code leading up to the exception. You'll see what's null and usually put palm to face when you see how it happens. I may sound hard-nosed, but in my opinion, no NPE should be posted in this forum unless the modder has at least tried the debugger and can tell us what was seen.

If you run into such missing methods in the future, look to the vanilla code for examples that already do what you're trying to do. In this case, you could probably have found what to use by diving into the furnace class. Think of all those vanilla classes as a huge raft of tutorials.

"Hard work" should include exploration of vanilla code. An IDE makes it easy. In Eclipse, select any vanilla class identifier in your code and then hit F3. Start with classes you extend, and then go on to visit some of the classes that they extend. When you get to the Block class, you'll see the registrations and instantiations of all vanilla blocks (down near the bottom). That's where you'll find this line (among many similar lines): registerBlock(35, "wool", (new BlockColored(Material.CLOTH)).setHardness(0.8F).setSoundType(SoundType.CLOTH).setUnlocalizedName("cloth")); Try it, and then you'll be able to answer many of your own questions.