jeffryfisher

Even after you get your shears to exist, they still might not behave exactly the same as vanilla shears. That's because some Minecraft objects depend on other objects knowing about them and coding special behavior for them by name (and not as instance of). These are technical violations of the "compartmentalization" aspect of O-O design methodology, but it's much easier to code that way when one is pressed by a deadline and not thinking about how difficult life will be for modders later. Therefore, test all behaviors that you care about. Try to enchant your custom shears, while in survival mode, with each enchantment you expect them to accept (using table and/or anvil+book as appropriate).

Food items can be used without acting upon a block, so what path do they take? Using the debugger, try to trace the execution path of a vanilla food item being eaten.

Right, the mesher's timing was very sensitive. Not only did it need to wait until Init, but it had to be in the right order with some other things and it was easy to screw up, hence it was deprecated (and there's a special level of modder Hell reserved for tutorial writers who subsequently told people to use it anyway). As several forum experts have mentioned in about 100 threads here over the last year+, the loader can and should be called in preInit. It is preferred because it's timing is not subject to the same disruption as the mesher.

In other words, you're writing a client-side mod to defeat the purpose and rules of a server (i.e. cheating). I think we're done here.

The debugger can be very slow, especially with breakpoints set on the client side. Just ignore the FPS until you get a compiled mod running in a real client-server setup. If your FPS is still slow after compilation, then you might have some IPC issues and will need to show us what you've invented that abuses the network.

That's up to you, using your experience as a programmer. If you don't have that experience, then look in a more general programming forum for ideas, because such low-level data mangling is not Forge specific. What you do need to know about Forge is that metadata is limited to int 0..15 (4 bits), and whatever you do to code state -> metadata must be reversed in meta -> state. After that, you also get to code the Get Actual State, which can take environment into account.

No, you din't read carefully. You need to DO what a certain method does, but you can't use that method itself because that method is client-only, and you're not (or shouldn't be). So go back to the drawing board, look inside the method, copy out its guts, and get rid of the call. Then get rid of the client-side annotation. Then clean up your code. Then run again. Then fix the first problem you encounter. Rinse repeat. Come back when you have a crash report (or runtime behavior) that you've tried to fix but can't.

JRE version? Are you using up-to-date Java?

What the 7 is trying to say is that the problem is not with understanding Forge/Minecraft but with understanding the basics of computer programming, something you should already know (or go elsewhere to get help with).

To be more precise, the main class was using an uninitialized block variable to construct the seed object, storing a null in that object. That null lurked in there like a ticking time bomb until the first time a seed was "used". The game then tried to place a block in the world, hit the null and exploded. As a very general rule, do not use any variable until after it has had something assigned to it. This is such a basic safety tip that a good IDE such as Eclipse should put red-flag warnings on lines like the one that passed the null to the seed constructor. As an experiment, you might reverse those lines again (temporarily) to see if Eclipse has anything to say. If not, then you should research Eclipse's settings until you can turn on such warnings. Then make a point of responding to them.

If running in Eclipse, go into Eclipse's run menu, select "run configurations" (or debug configurations) and look for a JVM options tab in the dialog (I hope it hasn't changed since my 3-yr old version). You shouldn't need this outside Eclipse because your error should be fixed by then.

Bingo! Grilled cheese, helm and boots also violate this rule. In general, you should never give an empty string. Just remove them, leaving fewer rows.

Did you match capitalization exactly? Show your main and proxy classes (and please enclose in code or spoiler tags to reduce clutter).

Can you find where the well's structural data comes from? Maybe instead of intercepting the control flow, you can monkey with the data instead (replace the whole well with something trivial like air and sand). Then when the game generates a "well", it just looks like more desert.

And make sure you're calling setCustomModelResourceLocation in or under preInit.

Each player has the option to change vanilla hot-key bindings anyway. I for one have changed my movement, jump, sneak etc keys so I can use the arrows, num-pad and nearby function keys on an idiosyncratic keyboard. If a mod messed with my choices, it would incapacitate me. However, if a mod assumed specific keys and my custom bindings foul it, then the mod wouldn't work (for me or anyone else who customizes keys). I recommend that you not use keys at that level. Instead, have your mod work at the abstract key (e.g. "sneak" or "jump") level so that physical keys can be translated by a player's custom bindings before your mod does anything to them. OTOH, If you're creating new hotkeys, then do both levels (an abstract key function and a default physical key). Players who add your mod can then change your default to suit their own keyboards and playing style (and resolve collisions with their existing customizations), but your mod will still work based on the layer of abstract key functions. If some modders come up with some generally useful key functions, I wonder if Forge will have a key dictionary someday (like the ore dictionary) that can enable mods to sync on "common" added keys. Wait, if that's a good idea, then Forge probably already has one.

1) Learn Java. 2) Do at least 2 Forge tutorials (the most recent you can find). 3) Try a "starter" mod, doing as much as you can yourself before getting stuck. 4) Google Forge + keyword to find other threads here covering the exact same problem you're experiencing. Fix that error yourself based on what you read. 5) When you encounter a problem where Google fails you, come back to this forum, posting your code and your crash log under an informative subject line. 6) After your easy starter mod is complete and running error-free in MP mode, then try the mod that you really want to do. Ask us for help when you get it to step 5.

BTW, In class EscortRequestNPC, is interact being called when it should be? Do you ever clear ifTrigger to false? Does anything ever test for being at the XYZ so you can stop executing?

Glad you fixed it. For future reference, the server should be telling the client when a block breaks, not vice versa. The server owns its world, and the clients display it. That makes the server the authority on changes to that world. The client should be telling the server what a player is trying to do in the world, not asserting what the effect is. That's because the player's attempt may be foiled by other actors (or server rules). It's the server's job to reconcile the activities of many players and other entities. If a bunch of clients all try to assert authority, then messy things happen (just look at the long Mojang bug thread about boat desync that only recently got fixed). Security could also be breached if a sever accepted a client's word about a change to the world.

Two suggestions: 1) In the decompiled workspace, find a vanilla example of what you want to mod. Open it in Eclipse. Use Eclipse's "find references" and other tools to walk through the code surrounding your topic of interest. Even better, set a few break points while you're there and then run the program in the debugger so you can then step through processes you want to learn. You can then envision subclassing a vanilla thing and changing its behavior. Along the way, you may also notice calls to Forge event handlers. Make note of them; each is an opportunity to change select behavior in the vanilla classes. 2) Find Jabelar's tutorials. See if he has written about what you want to mod. But never trust any tutorial. Minecraft is a moving target, so tutorials become obsolete within months (sometime weeks) of being written. Do my 1st suggestion anyway, even if you read some tuts first.

By this point, you should have an idea what this kind of error means and how to go about investigating. Hint: When it is on your screen, you can (in Eclipse at least) click directly on the "java:271" and be taken there to see what that line is. If it's not obvious what's null, then set a breakpoint there and re-run in the debugger. Better yet, look at the call stack and set a break somewhere upstream so you can step into the chain, looking at variable and argument values along the way. Also: Sometimes it helps to chop a complex statement into pieces that assign subexpressions to explicit local variables that can be examined in the debugger. The debugger is an essential tool. Learn to use it. Try to exhaust what you can learn with such tools before running to the forum here. You'll become a better developer if you master more of the tools at your fingertips.

Since the error log says "file not found", we have to suspect some subtle spelling mistake in the file name(s). Show the part of the directory with those names. Did you add or drop an underscore?

Rendering (display) and common proxy to not go together. Rendering should be limited to client proxy only.

In updateTick, try assigning your random numbers to a local variable so you can set a breakpoint there and examine the values in the debugger. If you never pass your test, then you should revise your formula. If you do pass your test, then step into setBlockState to see what's happening in there (e.g. flag usage).

Vanilla's JSON format has improved in 1.9. Just go with it unless you have some awesome variant to add to what you've already shown.