jeffryfisher

How do you know it stopped generating? Did you set a breakpoint? And when repeating a test, did you delete your nether files (or start a new world) so the chunks had to be generated again?

If you don't have a crash, then the console might not have enough information. Dig up the file logs and look for warnings. The text in the blockstates file is extremely delicate. It needs to match names perfectly (including capitalization). Many resource names need to be qualified with their resource domains.

Or maybe also when your thorns enchantment kills something while your hand is empty. Speaking of hands, shouldn't the code be looking at main and off-hand? In other words, what should happen if a player is holding the vorpal sword in his off-hand?

You've said that before, but I know from experience that a left-behind import statement alone can cause a class loading error (at least when running in Eclipse's debugger).

Eclipse probably got around to cleaning up your imports so that the renderer class is no longer loaded. If you really need that renderer, then you should still use it, but only call it from your client proxy. Don't mix it in with actions that must execute on the server. Your problem was where you chose to make the jump to the proxy, not the need for it. Get those initialization things sorted between common and client. Why do you bother with an EntityHelper class? Are any of those methods ever called from more than one place? Can't you just put their guts into the proxies from which they're called? PS: Put @Override annotations on all methods that are supposed to be overrides. PPS: private static int entityID = 3467; Looks like bad form. I think you should allow the system to allocate your entity ID and return it to you. Forcing any static ID for anything is just asking for trouble. How old is the tutorial you're working from?

What's wrong with the ticking system? Maybe you should visit the Forge repository at gitHub and start leaving comments and/or offering upgrades.

The experts don't teach core modding here. If you want to use Forge, then learn Forge (a wrapper that core-mods the game so you don't need to).

That looks suspicious. I'm amazed it even allowed you to connect before it started barfing.

Sentience itself could be a new enchantment that works much like Mending -- not available on the table, perhaps not even available in found magic books, siphons XP orbs when in player's active hand (or otherwise intervenes when used). Being an enchantment might make it easier to act upon vanilla items / itemStacks

How many times have you stepped through the creation / spawning in the debugger? Does that number bear a remarkable resemblance to your level of understanding? Set breakpoints (in your constructors and in vanilla EntityPainting constructors) and run the debugger.

It looks like you've solved the Forge mysteries and need Java help. Search online for how reflection is used to access private fields. If you want to learn how Forge might reach your goal via a different route, then tell 7 what you are aiming for.

AI priorities are like a hierarchy of survival. They tell the mob what to think about, but not what to do. That's what each AI routine does when those above it have decided that they're not needed at the moment. If you look at vanilla mobs, you'll see emergency survival decisions at the top and aimless random wandering at the bottom. Player interactions fall in the middle, pre-empted by emergencies but more important than aimless wandering.

You should start over in a new thread rather than resurrecting one that was dead and buried almost four years ago.

In 1.10.2 it was this when extending Enchantment: @Override public boolean canApplyAtEnchantingTable(ItemStack s) { ... }

Looks correct to me. What was I supposed to notice?

I agree with Draco. You need breaks in the tick, activate- and can- Repair methods to see the sequence of when they're being called. From what I saw, the code doesn't smell right. It looks as if activate is being called much more often than needed, and it looks as if shouldUpdate is being set false just as often. It also appears as if activateRepair and canRepair are being called in rapid succession without the tick having a chance to run. Things are just not in order (or else I'm not reading it right). Ideally, you would activate such a timer when the talisman is placed into (player) inventory. It would then continue ticking until removed. Each time the tick count reached 20, it would repair all items (and reset the counter to zero). To do that, the itemStack would probably need to remember what inventory it is in. It would also need to store its tick count when unloaded from the world. I haven't used capabilities yet, so I am unsure how much of that is handled for you. Optionally, you could have it also tick while in some other inventory (such as a chest, NPC mob or anvil) so it could repair items there as well.

If you're using Eclipse, and you see one of those reports with the Java line-numbers in it, you can click on the line to jump right to it.

You need to look into the jukebox's code, set a breakpoint or two and step through what happens when you pop your disc into it. In particular, you need to see whether the handling derails on the server or spawns a message to the client to be derailed there. If the latter, then you need to hunt down the message handler and set another breakpoint or two and run again in the debugger. The vanilla handler might be making an assumption that simply does not support having discs beyond the vanilla ones (The situation with paintings is like that). In such cases, custom handlers or even custom messages may be required.

Comp-sci for the curious: Each block position in the world gets a 2-byte (16-bit) integer to tell what it is. 4 bits are the metadata, and 12 bits are the ID. That gives you the ranges 0-15 for metadata and 0-4095 for block ID within which we must work. I 2nd the motion to use metadata wherever you create sets of blocks by color or wood or any other simple parameter. Otherwise those bits go to waste.

There's a whole tangle of code associated with being a player, so I think you're going to need to go with an extension of EntityPlayer. That means try the substitution(s) and re-skin.

How did you put the item in your hand? Can you be sure that it is really your item? Try dropping it and picking it up again. Also hover on the item in your inventory. How is it labeled? Please show us the entire method in which you instantiate the item object (new item of your class). It's probably in your main mod class, but might be something called from there. For the debugger, you might trace the call stack from which your methods can be called, then set your breakpoints somewhere upstream so you can see what data / decisions are affecting whether execution reaches you.

Or, if you can be somewhat flexible, compare using instanceof. This will match modded block classes that extend your block of interest.

Your registry naming is twisted. The new get and set methods are supposed to eliminate that need for substring(5). Read prior threads on that topic and then refactor. With a new installation, your run config will need some parameters / switches. Google each of the run config tabs in the context of Minecraft + Forge + Eclipse to see prior discussions / tutorials.

Don't you need to check hands (main hand) now? What version are we working in here? What tool/item did you want this to work with? Are you trying to override all silk, or just silktouch on a new custom item (e.g. a pick made of some new wonder-material)? If the latter, then you might have more options. If you hit a dead-end, then you might try block substitution whereby you hook a chunk-generating event to replace all vanilla spawners in the game with spawners you've modified.

You declared fields (pos, facing & title) in a class and never gave them values. I told you above that you need to get data from the message m. What did you expect would happen when you passed uninitialized arguments to that constructor? Why are you even posting the crash here when it points directly to a face-palm level programming omission? Your effort here is looking more and more like cargo-cult programming, which will leave you wondering why you stop getting help in this forum. You've left the realm of Forge learning and entered the realm of either Java ignorance or just plain laziness. Put some effort into understanding Java, and the plain English meaning of your error message, and the "logic" of your own program sequence before asking for any more help.