jeffryfisher

You've reached the conclusion that I saw yesterday. Since you seem to want to preserve the weapon recharge rule, but still use hitEntity, I suggest this: Write a simple event handler that detects your sword, peeks at the cooldown percentage, and then stores it somewhere to use a moment later in your implementation of hitEntity. Because the code-path between storage and use is so short (within one method), you might even be safe using a public field inside class ItemAmethystSword. If you nest your event handler class inside your sword class, then the field might not even need to be public. Then rewrite hitEntity to implement the partial damage and also compensate for or bypass the mob's temporary immunity.

The method hasSupport get's called in the updateTick method like explained above. I got that before. What I can't see is the recursion that you said existed. Recursion can be tricky, so I wanted to trace it. Where do any of your methods call in a circle? That's because multiple blocks are changing. Something in your code was written with an assumption that is no longer true as soon as you have more than one block changing. In particular, the appearance of stairs somewhere disagrees with a get blockstate for some position. The stairs block has its method called, but by the time that method gets blockstate from the world, the blockstate is air that doesn't have the properties expected by the stairs. Something you can try: Wherever you fetch the blockstate of a pos and thin k you know what kind of block it is, first check the block in the state to verify your assumption. If/when you encounter an "exception", either handle it gracefully or else print a warning. You might even call a debugging method so you can stop execution for hands-on analysis of how you got there. By stale state I meant stale data. That's a variable that's holding a value that no longer matches what's in the world. It's easy for variables to become invalid when blocks are being replaced. In fact, there was at least one such bug inside vanilla Minecraft 1.8 (but it never crashed simply because no vanilla block did anything more than air did). By "step through recursion" I mean that you should set a breakpoint within the recursive calling cycle (typically at the test that breaks out of the cycle, thus starting the unwinding of the call stack). Since I still can't see where the recursive call is (a method calling itself or another method in its own stack), I can't tell you where that is. BTW, Since recursion can be devilishly tricky (e.g. modifying static data becomes a no-no), I recommend commenting recursion thoroughly. As you step through the unwinding of the recursive call stack, pay attention to the use of any variables whose values were set before the recursive call. Are those values still valid? Is any method using a static variable whose value may have changed (but was assumed to be unchanged)? Do any other face-palms jump out at you? Writing re-entrant code requires some extra discipline, but this forum isn't really for teaching Java or how to do such general programming technique. If what I've written is still unclear, then do some outside research on recursion and its pitfalls. Also become completely comfortable with the debugger as a frequent and handy tool to use at the drop of a hat. Whenever you encounter a runtime problem, you should ask yourself, "How can I investigate further in the debugger?" -- And then do so.

I think you need to step through a few cycles of recursion to see where blocks are changing before a stale state variable is used to get a block that may no longer be where it used to be. BTW, could you point out where the recursive call is? I'm just not seeing it (I must need a nap).

I'm unsure about that. getDamageVsEntity() seems to be called only when a mob is deciding whether or not to pick up a fallen item (and wants to compare it to what it already has). Does it also figure into the player's attack calculation? One could try setting a break point to see if it is called during combat. I actually like using the hitEntity method to deal the extra damage. One thing to look out for though: You might then be bypassing the weapon cool-down, re-enabling the hit-spamming that was nerfed by Minecraft's combat upgrade. Decide if you need/want to mimic the partial damage of quick hits.

Example: import net.minecraftforge.client.model.ModelLoader; ... ModelResourceLocation res = new ModelResourceLocation (i.getRegistryName (), "inventory"); ModelLoader.setCustomModelResourceLocation (i, 0, res); Google setCustomModelResourceLocation along with keywords like Minecraft and Forge. You should see plenty of earlier discussion. When all resources are missing (even the lang file), it's probably because of some little error in directory structure or a string value in code. There should be some warnings in the log file (but maybe not in console). Hunt down the log file on disk. If you can't see any failures to open resource files, then give us a link or else post it here (inside tags).

Yup, especially when Eclipse might even offer to write the cast for him as a "quick fix" when he hovers on the ambiguous null.

It looks like some blocks are in the process of being replaced, so one block's (stairs') method is being called while another block's (air's) state is at that position. Apparently, some stairs were replaced by air (or air is about to be replaced by stairs that aren't really there yet), and the air can't answer the demand for direction information. It's time to reveal a lot more of your mod's code so we can see where you might be using stale data. Let's see the entirety of class BlockCollapse.

Look at particles (e.g. sword slash). Weather lightning is an entity that can interact with other entities. If your wand's only effect is on a known target block (and the lightning is merely a visual effect) then particles may suffice. Also look at how a fishing rod casts its line (and how the line is rendered).

Or you can declare a local variable of the needed type and initialize it to null before passing it as the argument to the call.

I think that's the graphics library. Either your workspace is corrupted, or you are missing a switch somewhere that would tell Eclipse where to find it. You may need to fuss with project -> properties -> Libraries.

You can do this by design, so it's a info message, not necessarily an error. Just make sure that you either provide an item model json or an inventory variant in your blockstates json.

If your block is a variation of clay, then maybe you could extend BlockHardenedClay instead of extending Block?

I think it means that you must list the Cartesian product of the state's properties (4 facings * 2 halves = 8 variants) so that you can put both x and y into a single rotation array for each.

UCHIJAAAA JEI{3.7.8.234} [Just Enough Items] (jei_1.10.2-3.7.8.234.jar) Is Just Enough Items a core mod? Forge often doesn't play nice with other core mods.

#inventory is for display in (you guessed it) inventory. Put the item in a chest and see what it looks like.

Only your java needs to parse the details of the state's properties. The blockstates JSON file can be presented with integers 1-10 if you like. Remember the "getActual..." method and that you can hide properties from blockstates. You have a lot of flexibility to know what you need to know in your own code while presenting a concise list to the renderer.

You also want to learn how the Forge alternate blockstates format works. It spares us some of the Cartesian product hell that Mojang gave us in 1.8.0.

*IF* method 'A' happens to have a Forge hook in it, then you can see what event it spawns and write an event handler (method 'B') whose result can cause the remainder of method 'A' to be skipped. If not, then you probably can't get there from here. Which method do you want to hijack?

Set a breakpoint upstream from the crash, and then run in the debugger. Step through (and into) the suspect code until you see the infinite loop described above.

Now you can move your 4 IBlockState's to the class level, adding static and final attributes (It's really not necessary to construct them every time that method is called). Likewise the item-stacks.

Accidental infinite loop or recursion somewhere (like when generating ore for the spawn-area's chunks)? How far can you get in the debugger? If you put a print into the ore-gen, does the log fill as in infinite loop / circular calling? Calling circles can occur when your program calls methods you're not expected to call. If their calls then come back to your method, the program gets stuck in infinite recursion. Then again, maybe your ore-gen has a loop with an exit condition that sometimes can't be satisfied (like when an ore isn't allowed to replace anything, so the method keeps trying different randoms forever attempting to find a place for it).

I see opportunity here: p_sound = net.minecraftforge.client.ForgeHooksClient.playSound(this, p_sound); if (p_sound == null) return; That thar is a Forge hook. You can write an event handler to do almost anything with that incoming p-sound, and then return null so that the vanilla method quits without doing anything else.

Are you creating a new world after each addition? Try stepping through your pre- and initialization methods in the debugger, paying attention to what's assigned where. Debugger stepping is much better than naked-eye code analysis for spotting run-time errors.

You need to be running in debug mode. What did you try to do, and where did you set your breakpoint(s)? How much experience do you have with debugger tools? Then you want to step through the neighbor change.

new ModelResourceLocation("random/"+ block.getRegistryName(), "inventory")) 1) You must set the registry name before you can get it (if you had shown more code with that in it then I wouldn't be telling you this). 2) The registry name will automatically get your modid prefixed to it. If you want "random/" in the path, then you might try putting it into the name string you pass to setRegistryName and then see what happens.