jeffryfisher

I have read that in 1.9, one must set registry name before registering a block. I don't know if nesting is recommended. I see "init" methods being called in a "preInit" event handler. For clarity, I recommend either moving them to the "init" event handler or renaming them. I don't think that an explicit ItemBlock need be set for every block (that's why there's a registration method without that parameter). The Vanilla ItemBlock class will be used for any block being registered without its own. However, if giving your own led you do re-order your set and registration lines, then you may have fixed another problem by accident.

The survival overworld has Y-coords 0..255, with bedrock filling the lowermost few and sea-level at 63. I think there's a world method "isWet", but what I meant was not swimming in an ocean. Just being in air should suffice. There are several light levels (including the luminosity of each block type), but now I'm not sure that would help you. You want a trigger in lit caves also, right? I think you want to find the method "canSeeTheSky" (or something like that). BTW, One can never see sky in the End and Nether, so you might want to trap those first (and maybe make different sounds for them).

Um... How can we to say "why" when you keep the error a secret? Show us the error log (in spoiler tags) and show your entire class that contains the proximate cause.

Was cardboard_block ever initialized? I see a method to do so, but I can't see that method being called.

If your need is general programming ability rather than specific Forge-wrapper tips, then you should seek out a personal friend or family member who can tutor you in programming/Java. You should never ever ask someone here to write your code for you (remember this forum's description: "This is not Java school").

My only thought is to explore the vanilla code, set a break point well upstream, and then step through in the debugger (stepping into all side-calls). An opportunity may present itself.

Also, when you use the server-side methods, your sounds are sent to pre-set client-side "renderers" (also called sounds, just to confuse us modders). You might be able to impose more control over sound behavior by instantiating your own sound-renderer on the client side and then using an event to detect your horn and swap renderers for it. Explore client-side sound handling to discover what your options are.

There are several strategies. The easiest is for your smelter to "play" an occasional sound effect after deciding (!remote) that it is smelting. This works if the sound is subtle enough to overlap or have gaps. What's actually happening is that the server-side playSoundEffect method sends a packet to all world accesses (clients within earshot), and each client reacts to its network packet by actually rendering the effect through a predefined "sound" (renderer). This predefined renderer has predefined parameters. Among them is no repeat. Yes, the naming of sound methods and classes adds confusion to the already mind-bending concept of client-server interoperation. PlaySoundEffect is a server-side decision. PlaySound is a client side rendering method. Do not confuse them. Moreover, in articles about sound, the word "sound" can refer to either a sound renderer or a sound resource, depending on context, and some writers confuse the two just to make modders' lives more interesting. If you really really want a repeating (continuous) sound that you can stop on command, then you must do two things: Instantiate your own client-side renderer, and handle an event to substitute yours for the predefined one when a client is about to play it. For the renderer, extend PositionedSound and probably implement ITickableSound. For the event, subscribe to PlaySoundEvent (@SideOnly(Side.CLIENT)). Mine looks like this: @SideOnly(Side.CLIENT) public class InventionsClientEventSubs { public InventionsClientEventSubs() { } @SubscribeEvent public void onPlaySound(PlaySoundEvent e) { ResourceLocation r = e.sound.getSoundLocation (); if (r.equals (BlockBlower.WHIRRLOC)) { WorldClient wc = Minecraft.getMinecraft ().theWorld; PositionedSound ps = (PositionedSound) e.sound; e.result = new ContinuousPositionedSoundFan (wc, ps); // Substitute with my continuous sound } } } And because it's client-only, I register the event handler to its bus in my client proxy. Note: ContinuousPositionedSoundFan is my own extension of PositionedSound, so I have written a constructor to copy what it needs from another ps. YMMV.

OK, I'll admit my recollection was vague, but I thought I'd seen loader code checking a supposed mod for the usual three handlers before deciding that it's a valid mod. Maybe it doesn't actually require all three all of the time, but I'd be asking for trouble if I left one out without walking that loader code again to be sure. I'm glad your problem is solved.

However, we're not trying to plant wheat here, so we don't even need to work around ItemSeeds#onItemUse. We're trying to plant some custom thingy, so let's override the custom thing's onItemUse method to do a different test. Have it copy the early branches of the seed's version, and then look for diamond block instead of calling canSustainPlant. PS: It would help if you could post the source code to MIItemSeeds. I think that's where you need to override onItemUse.

Since mc 1.8, proxies are mandatory. Create your proxies and start trying to be clever afterward. The main mod's init method needs to exist on the server side. If you declare it to be client SideOnly, then you're going to crash. The mod validation code within Forge might not even allow your mod to load on the server (when it is truly separate from the client).

I think D7 said that if no item is explicitly defined, then Forge will look for an inventory variant within the blockstates json. That means that your blockstates json can do item work for you. BTW, I am wondering why you have so many models. Are these different colored objects really different shapes? If not, then more simplifications are possible

When setting IIcons, you should be able to refer to vanilla textures for the sides you want to look like vanilla (e.g. the books). As for the animated particles flowing to an enchanting table, you are probably hosed. Those are generated by the table itself. If the table's client-side particle generator doesn't recognize extensions of BlockBookshelf (using instanceof for its comparison), then you might not have an easy fix. One workaround would be for your bookshelf to generate particles aimed at any nearby enchanting table. Look at how the enchanting table generates its particles, and then see about mirroring the effect.

Reeds (sugar cane) can be planted on any of several types of blocks. Can they be imitated? Do they need co-operation from sand, dirt etc? Walk through the reed code to see if you can extend that class (or its parent) to achieve your purpose. EDIT: Oh, and netherwart is a "bush" that grows on soul sand. Maybe that's what you should imitate.

Yes, but it's a pain. You must subscribe to the AnvilUpdateEvent (create an events handling class and import net.minecraftforge.event.AnvilUpdateEvent). Your AnvilUpdateEvent handler method will then need to mimic nearly all of the vanilla updateRepairOutput method, doing things your way in whatever key place you want something non-vanilla to happen. If you're new to events, then you have some reading / tutorial watching ahead of you.

Isn't there a damage to drop method that we can override?

Looks like you tried to access class Minecraft, which is client only. Whatever you're getting from it, get it from somewhere else, or come up with a different design, or only do it in a client proxy.

Indeed, you didn't say anything about worlds, so there were too many possibilities to guess at. So you're changing names in a mod but not moving from one Forge (or MC) version to another. There's hope, or at least there should have been. If what you say about injectSnapshot is correct and block remappings are all being ignored, then there may be a bug in Forge that needs to be reported (though it may have been fixed since 1.8.9). You might want to check the change logs. Speaking of later versions, it is generally hopeless to "upgrade" existing modded worlds to later MC versions of Minecraft (possibly because block remapping is broken), so you can posit that it simply shouldn't even be attempted. That frees you to rename things with impunity when porting your mods to newer MC versions -- only new worlds will run with the new naming. Therefore, make a note to self to complete your case-change renaming when you next upgrade this mod (e.g. to 1.9.2)

Are you sure that your files even make it into the jar file? Try opening it using zip to see what shipped. If your files aren't there, then you might need to ask for help in the gradel sub-forum.

When a brand-spanking new mod is added to a brand-spanking new world, there shouldn't be any of its blocks in that world needing remapping, so why are you doing remapping? (There's something missing from your story that means "the world" to us. What are you trying to do???)

After you get your walls working perfectly by extending from class Block, then you can change it back to extending from BlockWall. The reason for the roundabout development route is to be sure that you replicate all of the walls' features independently before you refer back to vanilla's walls and annotate those methods as @Override. When you are back to extending BlockWall, then the instanceof tests will do what you want, and your abstract wall class will prevent execution from going into BlockWall methods that refer to properties no longer in existence.

There are multiple layers of version compatibility, and sorting them out may be more trouble than it's worth, but... While your mod will almost always need to run in a forge client or server for which it was compiled, it might be possible for one version of a client to log into and play nice with another version of the server. That means that you might be able to compile your mod in for each related MC version (1.8, 1.8.8, 1.8.9), put the right mod on each client and on each server, and then have some gap between server and its clients (use a 1.8.9 client to join a 1.8 world). I think that higher clients are more likely to play with lower servers than vice-versa, but I'm not sure. My mods don't get spread widely enough to bother. I play my 1.7.10 world-server with a 1.7.10 client, and they all have the 1.7.10 versions of my mods; likewise 1.8. I'll skip 1.8.8 and 1.8.9 (and probably 1.9) to do 1.9.2. But that's just me.

I've heard of cobble and mossy cobble blocks being used in crafting, but not their walls. I distinguished my walls recipes by taking 7 input blocks to produce 7 walls (add top-center to the vanilla wall recipe). That lets me use the same materials that would otherwise make vanilla stuff (like those cobbles, and window panes, and nether-brick fences). I can now contemplate a full set of wooden walls that won't be confused with fences either.

Those java line numbers in the crash report are clickable. Get in there, set breakpoints, run in the debugger, and see what's what. Report back with more context, including all source code of any mod class referenced in the broken reflection code. If your mod classes are not involved at all, then you have an environment setup issue (like mixing versions, dropping a core mod into the workspace's mods folder etc). In that case, clean up. If you can't repair your existing workspace, then try setting up a fresh decomp workspace/ gradle Eclipse from scratch. BTW, What core mods and other infernal complications have you mixed in here without telling us?

Being a "full cube" might also do things to lighting and graphics occlusion. It's better to just add your own versions of cobble and mossy cobble to your list of variants. BTW, Set yourself up to do more than one set of walls (separate your walls into an abstract class and a child set of walls). Then you can add another 16 compatible wall types by writing another extension of the abstract class. Mine is up to 2 sets (32 walls), and I have contemplated a 3rd set. Mine even have variable hardness, blast resistance etc, and a few give off light. My glowstone and sea-lantern walls are quite useful.