jeffryfisher

Double check spelling, capitalization etc. Is the name in sounds.json supposed to recap domain etc? Mine didn't in 1.8, but then maybe that's why my own sounds remain silent in 1.10

A couple pics might draw comments from the modelers here, especially if you have a pic of what your mob is supposed to look like (can Techne show you that?) and can compare it to what's glitched. Unfortunately, I can't help with model design. I've only added one mob, and I "cheated" by copying a vanilla model to recolor

A) Post your blockstates file. Have you validated the json in a tool such as json lint? B) Tell us what you tried, what you expected, and what actually happened that was different. How does this differ from a vanilla example? Have you tried setting some break points and running in the debugger?

Sort of. The whirr is a continuous sound. The others are short sound-effects. The power-up and down also play when the fan changes speed (covering the skip when the whirr changes pitch).

You'd be stunned by how much data is stored by Minecraft in order to avoid calculating it every time it is needed. Just think of the model bakery... A switch statement would compile into a jump table much like the array I suggested. The only difference might be where the strings are stored (or maybe only where the pointers to the strings are stored). For a compact data set with known contiguous index, a static array should fit perfectly.

Or you could pull a string from an array of strings using meta as the index.

Got past the earlier error and ran into something really surprising. The "sound" supplied by Forge's PlaySoundEvent has a null in it! It turns out that the "sound" in the event is a sound record wrapper around the actual sound that I used to get directly in mc 1.8 and earlier. Inside of this wrapper, the actual sound is null because the hook fires before it is set by side-effect of a call to createAccessor. In order to make getSound() callable, my PlaySoundEvent event-handler needs to call p_sound.createAccessor(this.sndHandler) before it can call getSound(). Without the side-effects of that call, getSound() blows up with a null pointer exception. I'm aghast at how badly MC mangled the sound interface since 1.8 (leaving initialization until after the constructor is egregious, and requiring external calls to functions with side-effects is unforgivable). Who's writing this now, Microsoft? At least I'm no longer crashing. However, my block is silent. Perhaps I am calling the wrong server-side substitute for playSoundEffect(...). I will poke around some more in the debugger and post again if I get stuck. My revised registration code: public static final ResourceLocation PWRUP = new ResourceLocation (modid, "fanPwrUp"); protected static final SoundEvent fanPwrUpSnd = GameRegistry.register (new SoundEvent (PWRUP).setRegistryName (PWRUP)); public static final ResourceLocation WHIRRLOC = new ResourceLocation (modid, "fanWhirr"); protected static final SoundEvent whirrSnd = GameRegistry.register (new SoundEvent (WHIRRLOC).setRegistryName (WHIRRLOC)); public static final ResourceLocation CHOKE = new ResourceLocation (modid, "fanChoke"); protected static final SoundEvent fanChokeSnd = GameRegistry.register (new SoundEvent (CHOKE).setRegistryName (CHOKE)); public static final ResourceLocation PWRDN = new ResourceLocation (modid, "fanPwrDn"); protected static final SoundEvent fanPwrDnSnd = GameRegistry.register (new SoundEvent (PWRDN).setRegistryName (PWRDN));

Is there a reason that you did not extend BlockFurnace? At least walk through the vanilla furnace classes to plagiarize all code fragments that would fit your use case.

Your code is missing semicolons at the ends of some statements where Java requires semis. Please clean up all syntax errors and run your program in the debugger before coming back with runtime symptoms. Example: If running results in a null-pointer exception, step up to the crash site and examine involved variables at least once before posting the crash log (inside spoiler tags). PS: Please edit your OP to encapsulate the code within code tags.

This is unchanged from what worked in 1.8. Have the rules changed? sounds.json: { "fanPwrUp": {"category": "master","sounds": [{"name": "fanPwrUp", "stream": false}]}, "fanWhirr": {"category": "master","sounds": [{"name": "fanWhirr", "stream": false}]}, "fanChoke": {"category": "master","sounds": [{"name": "fanChoke", "stream": false}]}, "fanPwrDn": {"category": "master","sounds": [{"name": "fanPwrDn", "stream": false}]} } Aha... I'm not doing that (yet). I'll get on it tomorrow. Too bad the RL I passed into the constructor wasn't used to set the registry name (and register the sound for me).

The one missing aspect is randomness. As written, your gunpowder will explode as soon as fire appears next to it. TNT has a random delay before the fire catches. If you don't care, then it doesn't matter. Anyway, I am happy that my idea worked.

Don't worry about writing the shifts in your source code. Any optimizer worth the name will replace your "*16" subexpressions with shifts at the assembly level anyway. That liberates you to write what you mean yet enjoy the speed of fast machine execution

No. Registry name acquires a "modid:" prefix during its setting. Your bare string is missing that critical piece.

My sounds' resource locations are being set correctly and bound to their sounds, but by the time MC tries to validate them, all of the domains have been lost, resulting in "minecraft:" locations that can't be found. I've stepped through my static assignments in the debugger; they're creating the correct RLs, which are printed to the console. This is not a new mod. This was all working as intended in mc 1.8. I can't for the life of me figure out where my resource locations are losing their domains. First my sound source code: protected static final String modid = classInventionsMod.MODID; public static final String pwrUpPath = "fanPwrUp"; public static final ResourceLocation PWRUP = new ResourceLocation (modid, pwrUpPath); protected static final SoundEvent fanPwrUpSnd = new SoundEvent (PWRUP); public static final String whirrPath = "fanWhirr"; public static final ResourceLocation WHIRRLOC = new ResourceLocation (modid, whirrPath); protected static final SoundEvent whirrSnd = new SoundEvent (WHIRRLOC); public static final String chokePath = "fanChoke"; public static final ResourceLocation CHOKE = new ResourceLocation (modid, chokePath); protected static final SoundEvent fanChokeSnd = new SoundEvent (CHOKE); public static final String pwrDnPath = "fanPwrDn"; public static final ResourceLocation PWRDN = new ResourceLocation (modid, pwrDnPath); protected static final SoundEvent fanPwrDnSnd = new SoundEvent (PWRDN); Then the console: How do I upgrade my code? Or, do I need to move to a later Forge build of mc 1.10.2?

Also: I think that rotation in a JSON file is a single fact having 3 inseparable elements. In other words, you can't use one property to set an 'x' and another property to set 'z' (or 'y'). Instead, you must design one property to set {'x', 'y', 'z'} together. Providing a rotation aggregate such as {x=90} implies { x=90, y=0, z=0 }. Providing a rotation aggregate with any other property means clobbering will occur, with the last applied rotation winning. I think what that means is that your code should first take what you thought were its properties (perhaps based on input) and compose rendering variants according to rendering traits (output). Vanilla properties sometimes get in the way, resulting in ignored properties and other hacks. Beware that some hacks can cause performance penalties (e.g. memory hogging). I must confess that I don't know exactly when memory is or is not wasted by ignored properties in underlying state maps. My mods might be horrible memory hogs, and I am old enough (coming from an era when every memory bit was precious) to almost feel bad about it.

Yeah, that's pretty much what I was saying at 07:35.

For starters, point us to where you use reflection and where you handle ticking, especially when both are combined.

First, it looks as if you have some very deep recursion (the stack is repetitive). Look at those calls and see if you're calling in a circle by accident. Second, a NoClassDefFoundError often means that the server is attempting to use a client-side only class. It can aslo mean that you attempted to use reflection, but you forgot to load a class before invoking it. Set a break point upstream of the error and run again to look at what's trying to do what with what values.

I think you should have passed the registry name, not a static string.

Look at the call stack when you hit the breakpoint in your temp method. In Eclipse, you could prowl around the call stack to inspect local variables in the involved methods to see what is happening in each. It should become obvious how a stair block ended up looking for its property at a pos that contains an air block in the world.

It looked like BlockFire called getFlammability on its way to spreading fire to its neighbors. A little bit after the call, it applied randomeness, and if spread, it would see if the neighbor was TNT and blow it up. Why can't you override getFlammability to hijack the decision process and blow up on your own terms?

If you get a blockstate from the world, check that it is still your block before you attempt to get your properties from it. Vanilla blocks don't have variable hardness etc, so Mojang doesn't necessarily make those methods safe for modders who do (and there have indeed been times past when deleting such a block could crash the game because getHardness was called on a block after it had been turned into air in the world). You will need to decide what your methods should return when they detect a blockstate mismatches.

That's correct for developers on the inside (if we were Mojang employees), but we're not. Being on the outside looking in, our mods are stuck using reflection rather more often than nicely integrated projects would. If used only to init data rather than in tight loops running many times per second, we don't care about the performance hit. Even if some reflected element needs to be used frequently, you can usually arrange to pay the cost during initialization so your data access is reasonably fast. However, reflection can defeat some of our IDE tools (because classes and fields become text strings that the IDE doesn't trace -- never assume that "unused" elements are really unused). Therefore, you're right that we're better off using reflection only when needed.

You could try to override the getFlammability method. It wouldn't be perfect, but you could randomly explode when your block's getFlammability is checked. Sometimes it will, and sometimes it will be consumed before it can. You could even return zero (never catches vanilla fire), reserving all randomness to your own explosion. That might even mimic TNT correctly.

Ahhh... I feel less crazy now. And, being non-recursive means we can worry less about designing properly re-entrant code. The error is elsewhere. I can. If you call a method on a block that is not yet (or no longer) in the world, and it assumes it can find its own state by looking at world and pos, then it can get into trouble (e.g. stairs trying to get a facing from a pos that is air in the world). Add a method temporarily just to help with debugging. Detect block versus blockstate mismatches in several places, and have all detections call your temp helper method. Have that method write to the console, and put a breakpoint inside of it to stop the program and let you analyze what's causing the mismatch (and where).