jeffryfisher

If you want it activated by placement, then you'll want to instruct your players to place a certain block last (like the wither or golem/snowman). Since netherstars are rarely placed anywhere, you could set your event to detect netherstar placement and run your detection code then. Alternatively, you could require ignition as in a nether portal and run your code then. Or you could create a new item whose use upon a certain part of your structure activates it, running your detection code whenever the item is used.

Realize that there's only one block instance to represent all of the blocks of each block class everywhere in the world. In that respect, all class fields act sort of as if they were static, so those fields had better describe the whole class of blocks. For individual block variation, one must put data into the world. That's why we go through the contortions to use properties translated into and out of metadata (limited to 4-bits, the values 0..15) and tile entities. In essence, Minecraft hoists a feature of the object-oriented language up to its our code level to allow it to super-compress the long-term storage requirement of each block. Coding and storing millions of blocks "normally" would bust bandwidth, RAM, and maybe disks.

The Forge wrapper *is* a core mod. In fact, it is a general-purpose core mod that mods the core so you don't have to. Like other core mods, it is prone to conflicts with other mods that try to mangle the vanilla Java. Imagine coding a hook for an event only to have the vanilla class replaced by another mod that never calls your hook... Because it is general-purpose, it tends to conflict with anything and everything that tries to mod the core. Therefore, it does not guarantee interoperability with other core mods, and even warns that installing other core mods is probably a Bad Thing (i.e. leads to unpredictable results up to and including infinite loops that can eat all your memory and crash your OS with total loss of unsaved work). Clear?

Client-Server architecture takes a few knocks to wrap one's head around, especially when Eclipse runs both on a single machine sharing a single JRE. For most classes and their constructors, it doesn't matter. If yours is coughing up a lung (and it's not an obvious rendering action crashing the server), then start wrapping your head... Look into the way that vanilla entities spawn. See how the dance is done so that the server makes decisions and the client follows its lead (an entity's image is on the client, but its soul is on the server). Usually, if your mod operates at the right level of abstraction, the client-server interaction (messages etc) are handled for you. If you happened to discover a class or method that looked useful but is down in the weeds, then you might accidentally be short-circuiting the process.

Did you know that you can click on the "126" to go directly to the problem line? Have you set a breakpoint there? Have you used the debugger at all? As my signature used to say (before the site "upgrade", we had signatures), the debugger is an essential development tool. No matter how weird and mysterious it seems, you must pierce the barrier to its use. Just dive in and start reading its help pages. Once you discover its stepping and its runtime variable examination, you'll wonder how you ever lived without it.

Set a breakpoint on the offending line, run in the debugger, and then examine everything there when you hit it

Don't trust the console to give you all warnings. Dig up the log file to see missing textures.

Aha... My experience is with shaped recipes, so I didn't know that. I wonder why the interpretations differ. Silly me, I had expected both to convert blocks the same way. In fact, had I been coding it, I would have tried to call the same method in each case, but that may just be me being old-fashioned.

Sounds like the Mending enchantment. Find its code and see what it does.

What if you used just a sapling, not in an itemstack?

You might also create a villager profession (junk dealer?) who offers custom trades (takes damaged tool and returns its repair item). Then your players would not only have a way to recycle, but they'd have new motivation to find and develop villages.

What those worthies are saying is that meta has 4 bits, and facing is going to use up 2 or 3 of them. That leaves you at least the 1 bit needed for a boolean value. With that much Forge knowledge, you should be able to figure out a way to pack both values into the 4-bit meta and then unpack them again (that's fundamental programming technique, sometimes taught here, but you should get into the habit of finding external references for standard techniques).

Indeed, only "items" can appear in inventories such as creative tabs, even if those items look like blocks and get replaced by blocks when "placed" (used against a solid surface) in the world. That's why we have item-blocks, which are items used to represent blocks. From the point of view of a player, a world-block, a floating broken block itemStack entity and an inventory itemStack of item-blocks are all "blocks". However, from a programming standpoint, each is a distinct class of objects with differing storage. It's the programming that replaces one with another when certain actions are taken. The floaters are blessedly automatic, so if we've made itemBlocks for inventory, then we don't need to do any more, but we are still on the hook to declare the itemBlock for each block type that is to appear in inventory. In rare cases, such as when I made a device that gave off smoke blocks, I deliberately withheld the itemBlock (making it unobtanium like air, water and lava).

Read the docs: blockstates Use a JSON validator tool

First: When overriding any method, always use an @Override annotation so later version changes will flag mismatches. If you haven't already invested heavily in your update to this ancient code, then you should go back to the original and annotate every override. Then update the annotated code instead. Also: Definitely learn how to get the most mileage out of your "editor" (IDE = Integrated Development Environment, which is editor + precompiler + compiler + linker + debugger). For instance, in Eclipse for Java, you should be able to highlight any identifier (class, method or object) and right-click for a context menu of things you can do to learn more. In this way, you can teleport throughout the Forge version of the Minecraft code learning what these methods need.

You say you get an error, but not what it is. Learn enough Java to interpret simple errors. Come back when you have a Forge mystery. Isn't "codechicken" a core mod? If this mod is using an API to a core-mod, then Forge might not be right for you. If this isn't even about a Forge mod, then the Forge forum is definitely not the right place to find help.

Please learn to use code or spoiler tags to encapsulate long patches of code. Also learn how to use your IDE to trace simple semantic errors like using the wrong arguments to a method. This is a Forge forum, not a Java hand-holding class.

No. Eclipse will tell you where inconsistencies have cropped up. Outsiders like us simply eyeballing code without tools? We're at a severe disadvantage. When you see the error codes, you should be able to fix most yourself. When you don't understand something, search (use Google, not the forum's search) for the threads that already explain version changes in detail. Please don't spam the forum with naked code asking for us to do your work for you.

Orientable? Try subclassing BlockHorizontal, which uses just your compass points. In your variants, each model needs to be fully qualified (have your mod name before a colon). Where's your code? Where's your crash report?

This might cause you problems

I think the mod will need to go the other way, adding stone metadata (stone / granite / diorite / andesite) to each ore rather than adding ore metadata to each stone. Then replace every vanilla ore block with the new variable ore. Figure out how to generate those ores within the other stone variants (if not generating already), copying metadata from the stone variant to the ore variant. It would be simplest to create each texture combo in Paint (each is only 16x16 pixels). However, it might also be possible to do layers. Maybe 7 ores times 3 new variants is 21 little textures; paint is easier. Other mods' ores (copper, rubies etc) probably can't be included.

What package were you trying to open (and in what version of mc & Forge)? If that message comes up for MC or Forge packages, then you might have setup a dev workspace instead of the decomp workspace. If that could be the case, then you should replace your Forge installation. The decomp workspace will show you Minecraft and Forge code, but if you drill down to system level or other external packages, then you'll still get that error message. You shouldn't need any source code at the system level, but some external packages may be findable on the 'net if you're wondering what they do and how they do it.

That's not happening without a server mod. In general, the server is authoritative (keeps "real" data on a world and makes decisions about what to change) while clients are GUI terminals (display what the server says, and relay player input to the server for interpretation). For the most part, the only local control is over display parameters. Hence, client-only mods tend toward X-ray vision hacks that can get you perma-banned from most servers. For that reason, every time someone shows up here asking about client-only modding (an attempt to circumvent server authority), it attracts special interest and (sometimes stern) warnings. However, there are some useful information mods like recipe look-up that don't need anything on the server. If you wanted to do something like that, then you might find help here.

I recommend finding the vanilla mob AI classes, setting some break points, and then tracing the "thought" processes of a few animals and monsters as the game runs in the debugger. Watching variables such as speed and acceleration will give you benchmarks.

BTW, using a TE will not get you away from states and properties. It only serves to truncate the metadata value stored with a block. Another dodge is if one of your properties can be calculated from looking at neighboring blocks (the way walls connect). If for instance your facing depended on neighboring blocks, then it need not be stored in meta. PS: Does vanilla already have a BlockHorizontal class from which you can subclass?