jeffryfisher

Why does it seem that you're not doing it right? You haven't told us what happens versus what you expected. You haven't told us what you saw happening as you stepped through in the debugger. What's "not right"?

Aha! Jabelar was extending the reach of a sword, not extending the mouse event class. Go back and take a closer look at the tutorial and then start over.

You crash log lists several core mods. Core mods often don't play nice with Forge.

When run-time behavior is unexpected (but not a crash), it is instructive to set breakpoints and run the debugger so you can step through the spawning process. Each chunk is supposed to have a max number of any given mob. You want to step through the code that should be enforcing that. To find a good place to set your break point, hunt for spawn-list references.

Post the new crash. Better yet, read it and do some debugging. Also: Please ack where I first said you ref'd client-side Minecraft on the server. Given your posted error message (class Minecraft did not exist!), that should have fixed you.

Even more fun would be to render the item as a burning furnace! Waving a flaming furnace would look so awesome as to make recent troubles worth the effort.

A lightning bolt is an entity. Would Forge's EntityJoinWorldEvent give you a chance to detect each bolt, look at its coords and do your actions? I haven't traced lightning's execution far enough to see if it is spawned on that path, but it may be worth a try (or further research).

It looks like you've attempted to use a client-side class (Minecraft) on a server where it doesn't exist. That's not strange at all, so you might want to edit your subject line.

First do a simple mod so you can get through all of the basic steps and see what it takes to make them work (without complexities clouding problems in your handling of the basics). Once you understand the basics well enough to interpret common error messages and explore vanilla source code on your own, then you can attempt something complex. BTW, you can filter out most 1.7 and 1.8 writings by using your search engine's advanced features to look for articles written/updated in the last few months (a year at most).

I should clarify: When my event handler decides to change the anvil output, the change will cause a large part of vanilla anvil behavior to be skipped. My handler, not wanting to change all that behavior, then needs to do everything that the vanilla method would have done. Unfortunately, there are a couple of branches in that vanilla code that respect the player being in creative mode. Imitating those special cases is the only reason my handler needs any player data. A creative-mode boolean would suffice for my current mod, but I can imagine other mods where various player conditions could affect anvil behavior for that player. As it stands, when my mod's custom enchantment is applied via anvil, a creative mode player will be subject to survival-mode cost and limits, and the repair might become impossible (which interferes with my testing). I've never written a pull request. How much detail do I need to provide, and where do I submit it? BTW, this issue also came up during 1.8 about a year ago. I don't know if a request was made then.

I think you need to set registry name. The registry name will contain your modid so that you don't need to add it yourself in those other places. You can call getRegistryName().toString instead.

Fascinating... I wonder what the actual source code looks like. It might be something that looks complex on the surface but gets reduced and optimized so that our decompiled source looks like the above. That can happen when a complex situation in one version (the initial introduction of blockstates) gets simplified in a later version, but some patches of code retain bloat.

And then keep going so you can escape from being "positioned". Call up all of the nearby vanilla classes to see where to inject a server-side sound to play regardless of where the player is. Now, if you want other nearby players to hear this sound as if it's coming from the triggering player, then you have the case much like the minecart (where the server follows an entity and updates a sound's position for all to hear).

The AnvilUpdateEvent does not have a getPlayer() method. Is there any way to detect that the anvil user is in C-mode? Without a way to detect creative mode, I don't think it's possible to inject new behavior for a mod and still respect creative mode privilege (or invoke any other player-dependent behavior). Here's the critical statement from the AnvilUpdateEvent class: "If the event is not canceled, but the output is not null, it will set the output and not run vanilla behavior" (emphasis added). That means that if my event handler sets anvil output, then the handler is on the hook (so to speak) to emulate all bypassed behavior. I'm stumped because the bypassed behavior includes some creative-mode privilege to which the event seems to be blind (or am I blind?). If this is a gap in Forge design, should I post something elsewhere? PS: onAnvilRepair, which does specify a player, is not an adequate replacement event. By the time it is called (picking up from an anvil output slot), it is far too late to control what enchantments should be allowed from books or how many levels the repair will cost.

Yes the 2nd... Then it seems that you want to use a lower-level client-side sound method and avoid "positioned sound". Just feed a sound into the sound engine. Rather than looking at the minecart, which plays a continuous moving sound (position updated as minecart moves), you want something like the background music or GUI feedback sounds that are a purely local experience not heard by other players.

I think you'd foul the timing of everything in the game if you mess with settings at that level. Why don't you look inside the repeater (diode) instead?

I don't see an override of shouldRefresh in your TE class. Will the default behavior (replacing your whole TE whenever the state changes) do what you want?

Your panes extend BlockPane, so they should inherit connecting behavior. However, your blocks extend BlockBreakable. Why not extend BlockGlass? Your block is not a full cube; I think that's the hitch. Your panes might connect if your glass block extends BlockGlass instead of BlockBreakable. It might even be enough to make it a full cube. Also: Test vanilla panes with your glass blocks. The canConnect method can coax your own panes to connect, but I think that vanilla panes will fail to connect to a non-full cube.

The examples in vanilla code are variable blocks like stone. Each has an associated enum, and each enum has a set of arbitrary names (e.g. stone, andesite, diorite...) bound to numeric (metadata) values. That's why I said that the strings are something you write. They're usually an essential aspect of your mod's concept, so they're something that you are making up. You're the one making the mod, so only you know what your variants mean. You create the names from your own imagination. The names describe what you set out to code in the first place. It shouldn't be this hard. I'm reminded of a line from the movie Cool Hand Luke: "What we have here is a failure to communicate..."

You also want to getRegistryName instead of forming a resource location from a fragment of getUnlocalizedName. PS: Unless the subject line says otherwise, we will usually assume you're using the latest mc version. Even then it's nice to have it in there.

I may be wrong, but it looks like we're supposed to write the array of strings and then feed it into the constructor. That's how we tell the class what our variants are named. So think about what you're trying to do and then write it.

Did you read the ItemMultiTexture class and its constructors? Just instantiate one as your iblock and give one of the constructors what it wants.

Actually, using "this" is a good habit because it will sometimes remind you when you that you have a static vs instance conflict (at least it will have you thinking about it). Well, you might never do anything that careless, but if I revisit code after months away doing something else, I sometimes break it, and I like having Eclipse tell me so sooner rather than later.

I think those backgrounds are the slots -- what should show outlines when empty. Even your empty leggings slot is broken. Go back through your code and avoid messing with them. Perhaps you inserted your own domain (modid) somewhere you didn't need to? However... the helm in normal inventory also has the missing texture behind it. That's super weird. I think it's time to post a full log file (not mere console output), your armor class, and anything you're rendering.

You asked about an NPE without posting the crash report. Perhaps the forum needs a banner or sticky rules to warn against that again. As Draco says, we're not psychic. Rerun your code in the debugger (setting a breakpoint ahead of the crash point). Examine the fields about to be used in the crash. See what is null. Fix it. Further, since order of execution is often the cause of an NPE, we need to see whole classes, not just lines out of context. You could also put print statements in both your get and set to see which runs first (then use the debugger to examine the call stack). Finally, when referring to a class's methods and fields that are not static, get into the habit of prefixing them with "this."