jeffryfisher

The ambient sounds emerge from dark air with no sky. You can hear them even if there's stone between you and the darkness. Yes, it would be worth looking at the test for ambient sound.

There's probably a YouTube tutorial on ore gen out there. Search the web, specifying your minecraft version.

If the mod IDs are being scrambled, then it's happening sometime after registration (or it's happening to a different set of IDs than what I've been looking at). My reg calls all log their resulting IDs so I can check for that very phenomenon, and my 1.8.9 IDs matched my 1.8 IDs. I've decided that (for now) modded worlds with custom blocks are version-locked. I'll just create a new one from time to time.

Maybe put a torch next to a mushroom, or spread water through crops or carpets. Those actions may trigger the event without setting a "harvester". If all else fails, try some TNT. It may not solve your problem, but it will make you feel better. You may also temporarily wrap your danger zone in a try-catch frame. Catch the next NPE and output everything you can see. Try to figure out what was being harvested and how. Then you'll have a better idea how to replicate the NPE as needed during testing. Looking at your call stack, it appears that something was acting upon a BlockBush. Or you can simply accept CoolAlias's advice to check harvester for null.

If you don't mind missing caves high in hillsides, you could look at the player's Y coordinate to see if it is <62. Overworld and subterranean y and no sky and not wet is probably a cave (or mine, or stronghold, or the player's underground lair). Also decide what you want to do about dimensions besides the overworld. What are you trying to accomplish? Depending on your objective, you might also look at light-level to rule-out houses, deep bases, and well-civilized caves.

I think that vanilla Minecraft already counts hoe many of each mob is killed by each player. Look into "stats" to see what's there and how to read the count of Zombie kills.

Subscribe to PlayerEvent.BreakSpeed

Jabelar has some relatively recent tutorials and examples. There's also a whole tutorials section here at minecraftforge.net, but many of the articles are old. And there's more on the web if you search, but I recommend filtering results to the last year.

I suggest that you cut your teeth on some simple mods before embarking on an advanced and complex project. View some recent tutorials, and build up some Java expertise. Learn to access the decompiled vanilla code so you can learn by analyzing how vanilla Minecraft does what it does. For instance, you might answer some of your own questions by finding the code that spawns the wither (or a golem). When you have learned enough of the basics to understand our answers, and when you have developed a mod as far as the basics can take you, then come back with a separate thread for each remaining advanced topic where you need a pointer to where you can continue your self-teaching. You will not find people here to design a whole mod for you.

I don't think you want the client side to even know that a DB exists. Let clients be user interfaces. Let the server be the data authority with its own proprietary data storage mechanism(s). Depending on what you're trying to do, you may find yourself defining and/or sending some custom data packets. If you're going to implement a relational DB to store some of Minecraft's data on the server, then you need to look at the entire dataflow for NBT reads and writes, and then create something parallel to that. Depending on how many places you want to involve DB I/O, you might be able to hitchhike. As for security, don't distribute any version of your mod that contains any DB connection parameters. Also, for good practice, you should assume that every data originating from a client has been hacked with an SQL injection attack. Sanitize all client data before concatenating into an SQL statement. Your Minecraft server should not connect to the DB via a DB user having admin privs. Instead, the connection parameters should involve a dedicated DB user having only enough DB privileges to perform the DB operations needed by your mod's code.

You can either step into the call using the debugger or post (in spoiler tags) the crash report.

If you extended the vanilla BlockFurnace class, then there's already a boolean "isBurning". It's not a property, perhaps because furnace block types get swapped instead of changing state. The boolean is private, but you can crack it using reflection to force the field to be readable. Alternatively, you could simply have your constructor save the isBurning parameter into your own copy (mimic the vanilla block's constructor). Don't forget to call super.

It's time to set a breakpoint and walk through your generator in the debugger. See what's happening with your randomizer (you may want to articulate your code so you can examine subexpressions). Also find out where the random is coming from.

One of my mods (alt paintings) has a bunch of relatively large images that no physical server would ever need. After debugging, I compile it twice, the 2nd after deleting all assets. I give it a different file name and load it onto my server without a hitch. Just don't create sync problems that will jumble reality (like boats did before 1.9)

I am attempting to write an event handler for AnvilUpdateEvent (the one that fires early, so it can overrule what the output should be). Unfortunately, the player is not one of the fields provided with this event, and neither is the anvil (the anvil gets as far as the method in ForgeHooks that fires the event, but it is not relayed to the event itself). Without knowing the player, I can't respect creative mode. What I am trying to do is allow a few enchantments to be placed by enchanted book onto my custom shears in survival mode. I want to return without doing anything if the player is in creative mode. I also don't want to interfere with creative mode's cost and cost-limit processing. Is there a way, on the logical server, for my event handler to figure out what player is using the anvil when an AnvilUpdateEvent fires, even though the handler has neither the player nor the anvil to work with? If not, then some future version of Forge should add the anvil pointer to the event so reflection can be used to extract the private thePlayer field to check on creative mode (or just pass along the isCreative boolean instead).

Then you need to Google the syntax of Java enum. After fixing that (or deciding to use one of vanilla Minecraft's existing color types), then replace your expression in the state from meta method. Get rid of the trinary operator. I recommend using an enum's built in values array to return the enum value for a given integer.

Then it's time to worry about things like capitalization in the filename. If you can't find some mismatch, then start posting more of your log (not console) and code. Show us the whole error message in context. Show us the whole method that calls the playSoundEffect method. Running in the debugger would probably also be informative. My one experience with sounds is in mc 1.8, so it's possible that something must be different in 1.7.10.

For starters, please edit your OP to give it a version label (just in case the rules have changed between MC versions). My own custom sound uses "master" rather than "general", but I don't know the difference. IIRC, "stream":true is for long-playing sounds like music discs. They might need special handling. If you're playing just a few seconds of sound effect, change this to false. Your sound file must be in ogg format.

While you wait, hunt down the code in vanilla Minecraft that generates structures. I think it's somewhere in the chunk generation. Walk through it to see what it does. Along the way, take note of any calls to ForgeHooks methods. Designing your own structures and getting them to appear in your choice of biomes / villages etc will then be derived from a combination of extending vanilla classes, registering them somewhere, and writing some event handlers that subscribe to Forge events (be sure to have them listen to the right "bus").

I see a possible problem: There are several methods called "registerRender" in various non-sided classes, and each tries to get Minecraft. If I recall correctly, that's a client-only call. Methods called registerRender should either be in your client proxy or calling proxy.something to avoid blowing up the server. Indeed, you'd be well served to relegate all mention of "render" to your client proxy, because all rendering (graphics) is display stuff that is toxic to a server And if you haven't done so already, get rid of the server proxy. You want common and client. I know it's hard to wrap one's head around, but it has something to do with the difference between physical and logical clients in MP and SP environments. Therefore you need client extends common or else bad things happen in one of those environments (I think that a true server proxy would never exist in SP).

If you think walls are unfriendly, just try adding a new horse armor It's almost as if Mojang's coders didn't plan for future modders when they wrote the vanilla code

Your decision will turn on what you think of world preservation. Do you want to keep playing in a modded world you've been building using your mod, or do you want to start a new world? This is critical because modded worlds often don't travel well from version to version. I've pursued a couple of threads here in the last year, and my conclusion was that people just don't open modded worlds in anything but the version in which they were created (and did I want to write a version-sensitive conversion program that would comb through all of the saved world data for all of the chunks ever loaded -- nope, too daunting a task). Therefore, going from 1.7.10 to 1.8 or higher would not only mean learning the radically new and tediously difficult json-based rendering paradigm, but it would also mean that your upgraded mod would only be usable in new worlds created with the newer version (unless you don't mind wholesale scrambling of modded blocktypes in an existing world). If you don't care about any worlds with long history worth continuing, then follow Ernio's advice: Keep pace with recommended Forge builds as much as possible (which actually means forking development at each decompiled workspace you create). It's then your choice whether to port new features back to earlier versions. I'm too lazy to do so (yet), only touching 1.7.10 when a bug is reported there. For what it's worth, I am married to some long-running worlds, so I upgrade only intermittently. I upped from 1.7.10 to 1.8 last year, so I'll probably skip 1.8.9 and go to 1.9 later. The interim will also give me a chance to develop some new mods before being sucked into another upgrade cycle (1.8 was/is a nightmare, as evidenced by the hundreds of threads here anguishing over json files, meshing etc). However, nightmare or no, you'll probably want to try out the loads of new features in each major Minecraft release, even if you end up hosting a whole new world for each . YMMV

I've made this exact mod (except that I did not use netherbrick, which is too dark for my taste). BTW, Netherbrick in the crafting shape of a vanilla wall will craft a vanilla netherbrick fence. What were you planning for your recipes? Another irritating feature of vanilla walls is that they won't join up with subclassed walls (the test is for '== BlockWall', not 'instanceof'). Likewise subclassed gates. I ended up adding my own cobble and mossy-cobble walls after distinguishing my recipe to make 7 walls from 7 blocks (I added a cap to the top center). In addition, if you try to vary hardness by metadata, you may need to guard against having your hardness method called against an air block (when breaking blocks, vanilla seems to make one last call to get hardness after replacing a block with air). Take a look at uncle jeff's anystone walls (my extra walls mod). There are two sets of 16 walls in the version for 1.8. I ported to 1.8.9 but haven't uploaded that yet because I ran into problems moving my world from 1.8 to 1.8.9 for client-server final testing. However, I could stick it on Curse Forge as an alpha if you want to try it.

Well, for starters, things like the mesher (pertaining to rendering) exist only on the client side, so you need to learn about proxies. Even worse for the mesher is that it is fragile. Common wisdom now is that you should be calling some custom model loader in (client proxy's) preinit.

Are you sure that you need BlockSlabHalf and BlockSlabDouble? I'm not seeing such an arrangement in Vanilla slabs. It sounds like your mechanism for changing one into the other is incomplete.