jeffryfisher

I've just reached the same point myself. Using Eclipse's F3 function to go to the class definition, I see that "public class ItemMultiTexture extends ItemBlock". That tells us all we need to know. Just instantiate ItemMultiTexture where you would otherwise instantiate with ItemBlock (and then use your Java-sense to satisfy its demands, such as supplying it with a name array or a naming function containing an "apply(stack)" method).

That console output is bizarre. One thing (might not matter): Your main class does not even have the @Mod annotation, so I can't imagine how it even gets loaded. Add the annotation to main (and make sure that no other class has one). If you still have a problem after that, then go to the file system to get the log file. It has more info than the console. If it doesn't reveal the problem to you, then post it for others to see. I understand the difficulty keeping up with mc updates, especially after you've made several mods. I myself abandoned 1.8.9 when I discovered that opening a 1.8 world in it would scramble all of my custom blocks. Because of the time lost, I skipped 1.9 completely so I could get a new mod in. However, having completed that mod, I'm now upgrading to the latest and will create a whole new server world when I am done. Now that I know that no modded world can survive a Minecraft version change without glitching, I'll probably upgrade on alternate major releases (when my friends and I are ready for a new world).

In that case, each mystery concept should prompt you to do a Google search of this forum to do some serious reading (the forum's own search function tends to bury you in haystacks of crash reports that are not helpful, so use a smarter external search engine). Read about proxies. Research side-only versus isRemote as they pertain to the dev environment versus client-server. Find out why custom resource location is better than the mesher. Try running in the debugger (with a breakpoint at your print) so you can see which thread is executing each call, and so you can analyze the call stack. The proxy acts on behalf of your main mod class. "Common" proxy can be trivial because your main mod class can do common things for itself. However, there are some classes won't even be loaded on a dedicated server in a true client-server installation. Just importing such a class is toxic on JVM running a server with no client. Hence the client proxy that can be loaded only in the presence of a Minecraft client. It quarantines client side-only code such as rendering and all associated graphics resources. From mc 1.8 forward, proxies are essential for mods that add items (and/or blocks, since almost every block implies an item). At the very least, your client proxy will set a custom resource location for each item (don't do the mesher thing -- "why" is something else to look up). In mc 1.8, I think you still get a trivial ItemBlock automatically. Beginning in (I think) mc 1.9, you must explicitly declare your own. In 1.10 I gave my mods code to replace the automatic ItemBlock for blocks that don't get non-trivial ones. BTW, You should, if possible, use the latest (stable) version. Skip mc 1.8 & 1.9; go directly to 1.10.2. First, there's an expectation here that old versions have answers available in old threads we should find for ourselves. Second, working on a recent version lets you filter Google results to get recent threads, reducing the haystack. Good luck!

Wow, several of those methods are very close to what I came up with. They neatly encapsulate several instructions that would otherwise be copy-pasted over and over somewhere else. I also notice that most methods in those proxies are entirely generic (mod independent), meaning that it might be possible to promote them to higher-level classes outside any one mod. The common proxy would be usable by any mod as is, and any mod should be able to derive its client proxy by extending the generic client proxy. Of course, sharing code between mods has its downside... Your example also answered (I think) another question I was pondering: Do we still need to set unlocalized names in 1.10 where we are using registry names. It seems that we do.

I'm looking at the dynamic test block constructor. If it were ever called more than once, then multiple blocks would get the same name. Perhaps it could prepend some text derived from the input material. I'm just starting my own upgrade from mc 1.8 to mc 1.10.2, so I'm looking at ways to handle changes like the explicit ItemBlock requirement and the shift to set/get RegistryName. Is there really any gain from iterating a List of blocks? My gut says that building the List in the first place will be about as tedious as having each block call a shared setup method. Even so, I'll keep it in mind. BTW, The OP doesn't mention having any blockstates file, so the mod probably needs to add one. If anyone knows where the new JSON rules for 1.10 are described in detail, please point. (I'm still digging out from under a pile of changed package names, so I haven't gotten there yet).

Also look at how doors stand 2-high, rotate both halves when right-clicked, and can be broken by hitting either top or bottom.

"missing" is the model used when you've screwed up the JSON stuff so that it doesn't know what model to use for a block. If missing is missing, then something is seriously wrong. Are you using a core mod? If not, then you may need to start over from setupDecompWorkspace. However, before you go that far, it might help to post your entire log file (not console!) in a spoiler section.

Have you declared which Forge version each mod version is allowed to run under? When you ran SP outside of Eclipse, did you create a brand new world to test each version? Forged worlds tend not to travel well between mc versions (blocks get scrambled and items disappear). The next step would be to focus on mc 1.10 and describe one symptom in greater detail, providing the log file (in spoiler tags).

You've already set a breakpoint in deserializeNBT and run in the debugger, right? What happened when you stepped through that method? If you didn't even reach that method, try again with a breakpoint set high enough in its call chain that you can see how and why the program branches around the call.

Instead of retexturing a glass block, look at how a glass block became transparent in the first place. Also, how different will your block be compared to yellow glass? Maybe you can start with yellow glass and then go on to change the illumination, hardness etc. Do not give up so easily. Unless the redstone incompatibility is in the redstone code, your mod should be straightforward. If the redstone code is hostile, then an event handler might still defeat it. You need to explore the code and see where the decisions are being made. Then use your extensive Java knowledge to override each decision.

1) Examine the code for at least one vanilla block for each of the qualities you want to imitate. Discover what code gives it that quality. Be aware that some graphics qualities may be in blockstates and other resource files. 2) Decide whether your new block is close enough to any of those vanilla blocks that you can extend it. If not, then extend something more generic. Since redstone and transparency have historically been incompatible, you might indeed be better off extending from a generic. Realize that bedrock is unbreakable. If you want your block to be tough but not impossible to break, then look at obsidian. For light, look at glowstone. Mobs spawn at level 7 and below, so choose level 8 or above. For semi-transparency, see glass and its resources. That leaves redstone. There are two issues: Placing redstone on your block, and enabing your block to receive weak redstone power. Search the generic Block class's methods for mentions of redstone and then override behaviors you want to change.

I highly recommend that anyone using tile entities should, at least once in their lives, set a breakpoint in createNewTileEntity and then step into/through the whole process (including following the return to see what happens after that). Trace the whole gory execution path to see what's called and/or set when. Only then can one begin to understand perverse phenomena such as why createNewTileEntity() can never do anything fancy, and the TE trash-on-update problem (and its converse gotcha, the TE that's never cleaned up). If you pay attention, you'll also see how an unsuspecting modder could accidentally create an endless loop. Take notes so you can connect all the dots (like overriding the function that replaces the TE with every state change) and avoid all of the pitfalls (make sure your TE is marked dirty when it needs to be saved, and make sure it's deleted on time.)

I did exactly that, learning Java from scratch by setting up Forge and diving into modding. However, I come from a background with decades of professional coding experience in a dozen other languages including at least three object-oriented ones. My advice is that if you want to dive into modding in order to learn Java, then first go get yourself 20 years' of professional programming experience as a foundation, and then come back and talk to us. Otherwise, you should listen to the 7 and get yourself some solid Java training that includes a thorough treatment O-O programming concepts. You can do that in two parts: 1) If you're not already an expert in O-O programming, take a semester-length course somewhere that teaches it. It may require an intro to programming course as a prereq. 2) Work through a Java tutorial online to translate the language used in your course into Java.

Your error is in canConnectTo. You use "block != this", which will limit each wall's connection to itself. You probably want "instanceof BlockWall" (or BaseBlockWall) so all your walls accept every other wall. I also recommend that you optimize that expression, but that's probably my OCD kicking in

If you're using Eclipse, then each of those line references in the console output is a clickable link to a place in code. Use them to see what led the exception. Set breakpoints and rerun in the debugger so you can examine variables as you step toward the offending line. PS: Do not scold the people here for not responding in under 10 minutes. You're not paying us enough for that. We're just other hobbyists who tune in maybe once or twice a day, sometimes less. Therefore, if you hit a wall and must seek help here, you are possibly done for the day. At the very least, you should take a break to go do something else for a while.

And remember to both initialize and reset pressTime to zero somewhere so you can do your magic first time and every time

As chance would have it, I just finished (I hope) debugging a goat that will mow my tall grass for me. I chose to implement its spawning along with other registration calls by adding a static method to my mob's parent class (I have a parent-child class structure because I'm planning to add similar mobs that will share code). This gets called during my main class's preInit(): static protected void regEntityEtc (Class<? extends classEntityBrowser> clazz, String name, int[] egg, BiomeGenBase[] biomes) { int weight = 3; // TODO: Parameterize these when I add more mob species int min = 2; int max = 4; EntityRegistry.registerModEntity (clazz, name, mod.getNextEntityId (), mod, 80, 3, true); EntityRegistry.addSpawn (clazz, weight, min, max, EnumCreatureType.CREATURE, biomes); // TODO: Implement egg after upgrade from mc 1.8 } As you can see, "biomes" is an array of BiomeGenBase. I chose to declare one statically in each mob's child class: protected static final BiomeGenBase[] biomes = { BiomeGenBase.plains, BiomeGenBase.forest, BiomeGenBase.forestHills, BiomeGenBase.savanna }; If you have just one mob, you can collapse my parent-child class structure into something simpler.

Alternatively, you could develop a new slab to use as ceiling tiles, and have them emit level 15 light. I think the sea-lantern texture and animation would look really cool.

I don't really understand how ticks work... You said yourself that you want Minecraft to continue, so you must allow it to continue ticking. However, your thinking has been at the (virtual) machine stop level, which is the wrong level of thinking. I'm reminded of how DOS programmers stumbled when they first encountered the Windoze "message loop". It took a while to wrap one's head around the idea that one's "program" was really just one subroutine among many being called repeatedly by the real master program. In that case it was the OS, but in this case, it's Minecraft. Since your method may not hog the CPU all to itself for several seconds of GUI interaction, you must write code that can run in a series of blinks, somehow storing intermediate results for later resolution. In effect, Minecraft keeps ticking right along, but some sequence of your actions is spread out over time. That's what tick handlers do. Your logic wakes up, looks at the world and its own preserved thoughts, increments tick counters, make decisions, take actions, stores (or wipes) data for next time, and then exits to allow the rest of the program to continue.

If you setup a decomp workspace, then look under Referenced Libraries forgeSrc... The java files mostly start with net.minecraft, so scroll down to see those. You can't edit them, but you can see how things work so you can either derive your own versions or (where Forge callbacks exist) subscribe to their events and provide handlers where you may modify behavior.

Are those the Y vals where it tried to spawn, or where it actually spawned? What did your method return when it had those Y values? What were the sky values? Find a cave coordinate in your test world. Use the debugger to pause at the point where spawn coords are chosen, and then set the spawn coords to your cave's x, y, z. Then step through the program to see what happens and why. Be sure that your player entity is far enough away to allow creature spawning. Also: Get help with the debugger. It is an essential tool for most non-crash bugs. Find somebody who can visit you (or whom you can visit) to spend an hour or two getting a feel for the basics (setting breakpoints, examining variables, stepping into / over / out of methods, conditional breakpoints, and poking values into variables). You're not a complete Jedi modder until you can wield the debugger.

Post your client proxy (and any of your mod's item model registration code called from it).

Here's your problem: Caused by: java.lang.ArrayIndexOutOfBoundsException: 5 at net.minecraft.item.ItemAxe.<init>(ItemAxe.java:19) at com.PlasticMod.items.ItemPlasticAxe.<init>(ItemPlasticAxe.java:11) Look at the demands of ItemAxe.java:19 and then fix ItemPlasticAxe.java:11

This topic has come up within the last year, so a Google search should show you the earlier discussion(s) to get you started.

If I understand earlier comments correctly, Mojang is sometimes using the "deprecated" annotation as a poor-man's abstract method qualifier. In other words, it indicates a need to override so that it will never be called naked. Maybe there was some language rule preventing Mojang from using the abstract qualifier.