jeffryfisher

My only suggestion is to set a few breakpoints in EntityWaterMob and then hope to catch a squid or guardian in the act of spawning. If you find a water temple first, there should be plenty of activity to trap. Examine the methods in the call stack and look for anything that looks like it's in a branch following a land/water entity test. Keep your fingers crossed hoping that the test isn't specific to vanilla mobs by name.

I don't see recursion in the call stack, so you may really be short on memory. Go get a computer with at least 4GB.

Try extending public abstract class EntityWaterMob instead.

I'll consider that during debugging, but my initial design will mimic vanilla's registrations with state mappers. If it turns out that I can't usefully inherit anything from StateMapperBase, then I'll dump it.

OK, it looks like I need to extend StateMapperBase and override putStateModelLocations to simply return mapStateModelLocations without ever putting anything into it. I am hoping that will take care of "normal" (which is deeply rooted in a bunch of vanilla code that keeps adding it wherever property strings are empty). That leaves "inventory". I suspect it's creeping in because my default shared code creates an ItemBlock for every block it registers. Since my block should never drop or appear in inventory, I'll look into my library code and avoid making an ItemBlock if that's what's happening.

My new mod is trying to replace some air with something like smoke. In every way, it is air (and the class extends BlockAir) except that it has a slight opacity to attenuate light levels passing through it. Amazingly, my current code behaves (in game) the way I want. However, the console spews a bunch of warnings and errors during loading that scream about blockstate variants and models that I neither need nor want (and I'm already ignoring the the block's only property). Wanting a mod that is "clean" (so as not to alarm skittish users), I am wondering how best to avoid the error messages. My first approach was to look for the blockstates and model files for BlockAir, but they don't exist. The treatment of vanilla air is deeply embedded in the coding of many disjoint classes within Minecraft. Is there a recommended way to let Forge know that my block is "air", and therefore needs neither blockstate not model? If not, then what's the best way to trivialize the blockstates file (and avoid the need for a model file)? Errors that I am trying to silence (and yes, I have already declared a custom state mapper to ignore shadowlevel): [15:57:58] [Forge Version Check/INFO] [ForgeVersionCheck]: [Forge] Found status: OUTDATED Target: 12.18.2.2099 [15:58:33] [sound Library Loader/INFO]: Starting up SoundSystem... [15:58:34] [Thread-8/INFO]: Initializing LWJGL OpenAL [15:58:34] [Thread-8/INFO]: (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org) [15:58:34] [Thread-8/INFO]: OpenAL initialized. [15:58:34] [sound Library Loader/INFO]: Sound engine started [15:58:44] [Client thread/INFO] [FML]: Max texture size: 8192 [15:58:44] [Client thread/INFO]: Created: 16x16 textures-atlas [15:58:47] [Client thread/ERROR] [FML]: Exception loading model for variant jrfinventions:Shadow#normal for blockstates ["jrfinventions:Shadow[shadowlevel=4]", "jrfinventions:Shadow[shadowlevel=5]", "jrfinventions:Shadow[shadowlevel=6]", "jrfinventions:Shadow[shadowlevel=7]", "jrfinventions:Shadow[shadowlevel=0]", "jrfinventions:Shadow[shadowlevel=1]", "jrfinventions:Shadow[shadowlevel=2]", "jrfinventions:Shadow[shadowlevel=3]", "jrfinventions:Shadow[shadowlevel=12]", "jrfinventions:Shadow[shadowlevel=13]", "jrfinventions:Shadow[shadowlevel=14]", "jrfinventions:Shadow[shadowlevel=15]", "jrfinventions:Shadow[shadowlevel=8]", "jrfinventions:Shadow[shadowlevel=9]", "jrfinventions:Shadow[shadowlevel=10]", "jrfinventions:Shadow[shadowlevel=11]"] net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model jrfinventions:Shadow#normal with loader VariantLoader.INSTANCE, skipping at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:153) ~[ModelLoaderRegistry.class:?] at net.minecraftforge.client.model.ModelLoader.registerVariant(ModelLoader.java:241) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadBlock(ModelBakery.java:145) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.loadBlocks(ModelLoader.java:229) ~[ModelLoader.class:?] at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:146) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28) [ModelManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.registerReloadListener(SimpleReloadableResourceManager.java:122) [simpleReloadableResourceManager.class:?] at net.minecraft.client.Minecraft.startGame(Minecraft.java:540) [Minecraft.class:?] at net.minecraft.client.Minecraft.run(Minecraft.java:386) [Minecraft.class:?] at net.minecraft.client.main.Main.main(Main.java:118) [Main.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_80] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_80] at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_80] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_80] at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) [start/:?] at GradleStart.main(GradleStart.java:26) [start/:?] Caused by: net.minecraft.client.renderer.block.model.ModelBlockDefinition$MissingVariantException at net.minecraft.client.renderer.block.model.ModelBlockDefinition.getVariant(ModelBlockDefinition.java:78) ~[ModelBlockDefinition.class:?] at net.minecraftforge.client.model.ModelLoader$VariantLoader.loadModel(ModelLoader.java:1184) ~[ModelLoader$VariantLoader.class:?] at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:149) ~[ModelLoaderRegistry.class:?] ... 21 more [15:58:47] [Client thread/ERROR] [FML]: Exception loading blockstate for the variant jrfinventions:Shadow#normal: java.lang.Exception: Could not load model definition for variant jrfinventions:Shadow at net.minecraftforge.client.model.ModelLoader.getModelBlockDefinition(ModelLoader.java:274) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadBlock(ModelBakery.java:121) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.loadBlocks(ModelLoader.java:229) ~[ModelLoader.class:?] at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:146) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28) [ModelManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.registerReloadListener(SimpleReloadableResourceManager.java:122) [simpleReloadableResourceManager.class:?] at net.minecraft.client.Minecraft.startGame(Minecraft.java:540) [Minecraft.class:?] at net.minecraft.client.Minecraft.run(Minecraft.java:386) [Minecraft.class:?] at net.minecraft.client.main.Main.main(Main.java:118) [Main.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_80] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_80] at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_80] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_80] at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) [start/:?] at GradleStart.main(GradleStart.java:26) [start/:?] Caused by: java.lang.RuntimeException: Encountered an exception when loading model definition of model jrfinventions:blockstates/Shadow.json at net.minecraft.client.renderer.block.model.ModelBakery.loadMultipartMBD(ModelBakery.java:205) ~[ModelBakery.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.getModelBlockDefinition(ModelBakery.java:185) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.getModelBlockDefinition(ModelLoader.java:270) ~[ModelLoader.class:?] ... 20 more Caused by: java.io.FileNotFoundException: jrfinventions:blockstates/Shadow.json at net.minecraft.client.resources.FallbackResourceManager.getAllResources(FallbackResourceManager.java:103) ~[FallbackResourceManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.getAllResources(SimpleReloadableResourceManager.java:79) ~[simpleReloadableResourceManager.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadMultipartMBD(ModelBakery.java:198) ~[ModelBakery.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.getModelBlockDefinition(ModelBakery.java:185) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.getModelBlockDefinition(ModelLoader.java:270) ~[ModelLoader.class:?] ... 20 more [15:58:47] [Client thread/ERROR] [FML]: Exception loading model for variant jrfinventions:Shadow#inventory for item "jrfinventions:Shadow", normal location exception: net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model jrfinventions:item/Shadow with loader VanillaLoader.INSTANCE, skipping at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:153) ~[ModelLoaderRegistry.class:?] at net.minecraftforge.client.model.ModelLoader.loadItemModels(ModelLoader.java:317) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadVariantItemModels(ModelBakery.java:170) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:147) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28) [ModelManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.registerReloadListener(SimpleReloadableResourceManager.java:122) [simpleReloadableResourceManager.class:?] at net.minecraft.client.Minecraft.startGame(Minecraft.java:540) [Minecraft.class:?] at net.minecraft.client.Minecraft.run(Minecraft.java:386) [Minecraft.class:?] at net.minecraft.client.main.Main.main(Main.java:118) [Main.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_80] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_80] at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_80] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_80] at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) [start/:?] at GradleStart.main(GradleStart.java:26) [start/:?] Caused by: java.io.FileNotFoundException: jrfinventions:models/item/Shadow.json at net.minecraft.client.resources.FallbackResourceManager.getResource(FallbackResourceManager.java:68) ~[FallbackResourceManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.getResource(SimpleReloadableResourceManager.java:65) ~[simpleReloadableResourceManager.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadModel(ModelBakery.java:311) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.access$1100(ModelLoader.java:118) ~[ModelLoader.class:?] at net.minecraftforge.client.model.ModelLoader$VanillaLoader.loadModel(ModelLoader.java:868) ~[ModelLoader$VanillaLoader.class:?] at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:149) ~[ModelLoaderRegistry.class:?] ... 20 more [15:58:47] [Client thread/ERROR] [FML]: Exception loading model for variant jrfinventions:Shadow#inventory for item "jrfinventions:Shadow", blockstate location exception: net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model jrfinventions:Shadow#inventory with loader VariantLoader.INSTANCE, skipping at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:153) ~[ModelLoaderRegistry.class:?] at net.minecraftforge.client.model.ModelLoader.loadItemModels(ModelLoader.java:325) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadVariantItemModels(ModelBakery.java:170) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:147) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28) [ModelManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.registerReloadListener(SimpleReloadableResourceManager.java:122) [simpleReloadableResourceManager.class:?] at net.minecraft.client.Minecraft.startGame(Minecraft.java:540) [Minecraft.class:?] at net.minecraft.client.Minecraft.run(Minecraft.java:386) [Minecraft.class:?] at net.minecraft.client.main.Main.main(Main.java:118) [Main.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_80] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_80] at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_80] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_80] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_80] at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) [start/:?] at GradleStart.main(GradleStart.java:26) [start/:?] Caused by: net.minecraft.client.renderer.block.model.ModelBlockDefinition$MissingVariantException at net.minecraft.client.renderer.block.model.ModelBlockDefinition.getVariant(ModelBlockDefinition.java:78) ~[ModelBlockDefinition.class:?] at net.minecraftforge.client.model.ModelLoader$VariantLoader.loadModel(ModelLoader.java:1184) ~[ModelLoader$VariantLoader.class:?] at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:149) ~[ModelLoaderRegistry.class:?] ... 20 more [15:58:48] [Client thread/INFO] [sTDOUT]: [jrfshare.classProxyClient:init:120]: Init jrfinventions I just want it to shutup and treat it like air.

Sadly, I must let you know that MC 1.7.10 is no longer supported on this forum (not my decision). If you can design your mod to 1.10.2 or 1.11, then you'll get much more help here (and probably won't even need help, because the shortcoming in harvest level was probably fixed two years ago). PS: The search function inside the site sucks, but Google can find necrotic threads and ancient forum posts for almost any issue. Play with Google until you find a past discussion of your problem. Sorry I couldn't be more encouraging

Version? Oh, and show us the whole method that has those lines, and the method that calls it (sometimes execution order is the catch, and it depends on context).

Even more clear than using Eclipse to see method references is to set a breakpoint on BlockFence's getActualState and then run Minecraft in the debugger. Step out of the method and see what called it and what variables have what values. Maybe set another breakpoint somewhere upstream and continue. The debugger is very powerful because it cuts through the fog of runtime polymorphism etc.

First of all, modded worlds often don't work well when ported to new versions. Block IDs can be completely scrambled (e.g. what were placed as a mod's blocks may appear as newly added vanilla blocks). Therefore, my first recommendation is to leave each modded world in whatever MC version created it. That said, there's an optional main mod class event after postInit that is designed to remap unresolved names. I think this is what you're supposed to use to replace all of the old names in a world with your new names. Jump to the declaration of the post initialization event and then look around for the other events declared nearby. PS: Mixed case mod IDs have been problematic for a long time. How did you get away with one? [Don't answer. That's just a rhetorical question.]

Are UP and DOWN valid directions for your spreading? If not, then you want to use the BlockHorizontal extension of BlockDirectional. It limits its property to the four compass points, and they're separately indexed 0..3.

I'm glad that griefing won't be a problem. Are those nested loops looking at every face of the device for each drop? It's probably not necessary to be more efficient, but if it were my method, then my old-school sensibilities would probably compel me to try anyway.

Doesn't vanilla MC already have a command to play a sound at a player? From another forum:

What I was thinking of was if any player had started working in a cave somewhere below, building a mini-base with chests, a furnace etc. Would your device eradicate everything, or will it only break certain types of blocks? If it does break a chest, will it vacuum the dropped contents and add those items to its output? For SP, these considerations don't matter much (other than protecting an output pipeline from clogging). However, in MP, this device could enable one player to seriously damage the work of another. Given its potential power, it's worth some thought to decide just how destructive you want to make it.

These might be silly questions, but what will happen to players and mobs in the area of effect, especially as the ground vanishes beneath their feet and lava is exposed? How will a player get to the mined drops if blocks all around have been destroyed down to bedrock? What does your excavator do to special blocks (chests etc) in the affected volume? What I am getting at is that besides us solving programming issues, we should help you avoid creating a device that's over-powered or suicidally dangerous to use (YMMV).

The Forge format DOES allow multiple tests. What it doesn't enable is disjoint rotations (one property setting x, and another property setting y). That's a vanilla limitation: Rotation is an atomic (indivisible) value having an x and a y value (zero if you don't specify). Maybe someday Forge can improve on the vanilla rotation array, but I'm not holding my breath.

Important caveat (something I just ran into): Vanilla Minecraft won't process updates for blocks with material AIR (it explicitly tests for them and aborts processing). So if you're spreading something like smoke (some variation of air), then scheduled (and random tick) updates will be ignored

In that case, what you have there is two devices in one (excavator and hopper, without GUI to access inventory). Look at how hoppers are placed (default output DOWN, but can be attached to blocks having inventory such as chests). Copy the hopper's functionality except for the GUI. Because you must contend with broken attachments, full chests etc, you'll still have an internal inventory (I recommend one slot per likely drop type), but you can hide it from the players. Mined drops won't be accessible until the machine is broken or can push them to an attached storage block. PS: Make sure your excavator doesn't break any chests. As a general rule, don't break any blocks where there are tile entities. What will you do with trees/logs in the vicinity?

Do you want your device to be like a furnace that fills a small inventory until a hopper or player pulls it away? Or, does it need to be like a hopper that can push items into a chest? Being passive and requiring a hopper beneath it to perform the movement task would probably be simpler to code, and that paradigm (parallel to furnace and brewing stand) would make good game sense.

You probably need to write to the author of the CoFH API (or post on a forum dedicated to it). When you encounter an issue related to Forge generally, then come back with your question/crash. PS: This site has a few mod-specific forums, so you may find some info there.

Stop for a moment and think about what that means... It is quiet without the assertion, but you hear about an error when you assert the truth about the method. As the designer, you KNOW that a method is (supposed to) override an inherited method. Therefore, when your IDE suggests that you remove the annotation, you KNOW that it's bad advice (like "curing" a fever by removing that pesky thermometer -- all you accomplish is that you turn off the alert; you wouldn't be fixing the problem). Now there are some methods that you are not allowed to override. If you are modding in unexplored territory, you might run into static and/or private (and maybe final?) methods. Then you need to get creative. However, onBlockActivated shouldn't be one of those. Follow the advice above: Copy-paste the exact method header. You can then change parameter names if you like, but don't mess with the return type, qualifiers or parameter types. And yes, every Java programmer should attach the @Override annotation to each and every method that's supposed be overriding an inherited method -- NO EXCEPTIONS. The first time you go through an upgrade exercise to a new MC release, you will thank your past self for pasting all those annotations where they assert the truth of your design (because they'll flag subtle inconsistencies created by vanilla code changes).

Sounds like your excavator is going to be an extension of BlockHorizontal. That'll give you a property that can be north, east, south or west (see the subset of horizontals within the facing enum). For the initial placement, see how a furnace does so. Take care to separate the block's logic from its rendering. Logic is mostly server-side (world not remote), and rendering is client side-only. Don't scramble their concepts in your mind either.

You assigned it to a model. Model is not texture.

Have you tried declaring defaults in your blockstates file? Is oak_bark really a model? Have you tried including an "inventory" variant?

For future reference, follow the advice to use the debugger. WHENEVER you (meaning anyone reading this thread) encounter a null-pointer exception, read the call stack back to your own code (perhaps in a "caused by"), go to the referenced line (in Eclipse, just click on the red line number), and set a breakpoint. Then re-run your code. After hitting the breakpoint, step through statements and into methods until you reach the exceptional line. All along the way, examine the values of variables being used. There's a good chance that palm will slap face at some point. If you're unlucky enough to have one of those statements that runs a thousand times before it causes an exception, then you may need to study about conditional breakpoints. If after stepping through code you still have an exception that you can't see how to fix, then post your crash report and what you learned while stepping through the debugger. People here will be so impressed that you used the debugger that they'll fall all over each other to help you