Daeruin

It sounds like you want it to work basically the same as a bow, but with a left click (and it's not ranged). Is that accurate? Are you talking about doing this for a custom weapon, or making a generic mechanic that could potentially apply to say a vanilla sword that you're using in two hands?

Sweet! Glad I could be of help.

Personally, if I smashed a filter into a solid block of stone, or started beating someone over the head with it with murderous intent, I would expect it to be somewhat damaged. This is your custom item, correct? Have a look at all the methods in the vanilla Item class and see which ones seem like they'll do what you need. Your IDE can tell you where the methods get used. You'll benefit a lot from doing this kind of research and figuring out how things work for yourself. For example, in 5 minutes, I found Item#onLeftClickEntity. It looks like you could override that method in your item and simply return true to make nothing happen when someone tries to attack an entity with your item.

When I made slabs, I ended up extending ItemSlab to create my own item class for the slabs. I needed to do that because I needed custom behavior in onItemUse, but you might be able to make an ItemSlab directly by passing in a block, half slab, and double slab. ItemSlab extends ItemBlock, so you would then register an instance of your ItemSlab instead of making a generic ItemBlock. You'll probably have to do something custom in your registry to detect when your ItemSlab is being registered.

Unfortunately for you, EntityPlayer#attackTargetEntityWithCurrentItem can't just be rewritten like that (unless maybe you replace the player entity completely). Many times, Forge supplies an event that does what you need. In your case, check out the very first line of attackTargetEntityWithCurrentItem. You can see that there is a Forge hook called onPlayerAttackTarget. You can hook into that event, and then do whatever you need to (possibly copying portions of the original method, possibly canceling the event when you are done with your stuff, to prevent the vanilla code from running). Basic documentation on using Forge events is here.

Well, I'm going to mark this one solved for now. Hopefully it doesn't cause trouble in the future to go without the light map enabled. Thanks again for your help. I probably wouldn't have stumbled upon the answer to this one without you.

Thank you so much for your help! I was starting to despair. I'm totally new to this rendering stuff and have very little idea what most of the code does. I've been trying to figure it out, but it's quite a learning curve for what I thought was going to be something simple. I tried disabling blending, but there was no change. I then commented out the line where the light map is enabled (enableLightmap), and like magic the rain turned blue. Which makes me wonder what I'm getting out of it. Why use that method at all? I did have to replicate the light map code, because I couldn't refer to the vanilla method statically. The only thing I had to change was the reference to the lightMap texture, since the variable was private, which also forced me to create a new DynamicTexture for the light map. I've never heard of dynamic textures before, but it appears to get updated in updateLightMap(), which only seems to be used when updateTorchFlicker() sets lightmapUpdateNeeded to true. So I'm not sure why that would affect what I'm doing. Unless I need to refer to the exact DynamicTexture created in EntityRenderer? I have been slowly working on refactoring the variable names, but some of the code is pretty obscure. For example, I think I have the variable names used in this line of code figured out: double d5 = -((double) (PrimalClientTickEvent.rendererUpdateCount + xDistFromEntity * xDistFromEntity * 3121 + xDistFromEntity * 45238971 + zDistFromEntity * zDistFromEntity * 418711 + zDistFromEntity * 13761 & 31) + (double) partialTicks) / 32.0D * (3.0D + this.random.nextDouble()); But I have no idea what the math is really doing. Based on where d5 is used—in a BufferBuilder.tex() call—I think it's something to find the right part of the texture to render? But the math itself is very obscure, and I'm mostly guessing on the purpose of tex() so I don't really know what to change d5 to.

By playing around with the color values on the lines that look like this: bufferbuilder.pos((double) l1 - d3 + 0.5D, (double) l2, (double) k1 - d4 + 0.5D).tex(0.0D, (double) k2 * 0.25D + d5).color(1.0F, 1.0F, 1.0F, I have gotten the color to change to dark red and black. Which makes me reasonably sure these lines are not the issue. I've gone back to the theory that it's some kind of texture error. Like, it can't find the textures or something. I had originally left the texture fields the same as they are in vanilla: private static final ResourceLocation SNOW_TEXTURES = new ResourceLocation("textures/environment/snow.png"); I then tried copying the PNG files into my mod's texture folder and adding my own mod id, but that didn't work. I double checked the spelling on the folders and file names. private static final ResourceLocation SNOW_TEXTURES = new ResourceLocation("primalcraft:textures/environment/snow.png"); Any other ideas what's going on here? I don't WANT to muck around with particles and renderers. I just want to make snow appear at reasonable times.

I created a rendererUpdateCount field in my ClientTickEvent and update it once a tick. That seemed to be the right thing to do, since the original gets updated during Minecraft#runTick. (I didn't bother with addRainParticles() since it's already called from EntityRenderer#updateRenderer.) I'm not getting any crashes or errors. However, when it rains and snows the particles are red, like it's raining blood. I'm guessing this is a problem with renderUpdateCount not being the right value. At first I thought it was a problem with the texture, but after fiddling with that for a while I couldn't fix it. I also tried implementing addRainParticles() in my ClientTickEvent, but it didn't seem to do anything. Here's my IRenderHandler code, if it helps:

I've been fiddling around with seasons and weather stuff, and I'm trying to change when precipitation is rendered as rain vs. snow. I don't want it to be controlled solely by biome temperature. After a bit of research, it seemed like creating my own weather renderer might be the thing to do, so I can sidestep the way vanilla relies on biome temperature to decide whether to render rain or snow. I created a class that extends IRenderHandler and just copied the vanilla code for EntityRenderer#renderRainSnow. However, the vanilla code contains a reference to a private variable called rendererUpdateCount. I don't really understand what the variable does—any insight into that would be appreciated. In vanilla, it gets updated in EntityRenderer#updateRenderer, and I assume I would need to use that value as it gets updated. Or can I, like, create my own variable and update it somehow...?

I made a custom inventory GUI using Gimp. I started with the vanilla texture, then selected parts of it and moved them around. Some of it is pixel-by-pixel work. That's how I did the little arrows on my GUI, attached. I expect those four slots at the top of the screen you posted were done pixel by pixel, just like many item and block textures are done. Kind of tedious, but not too bad considering each inventory slot is only 16x16 pixels.

Well, that was easier than I thought it would be. You made me awfully grumpy at first, but after taking your word for it and thinking about it for a while, I realized that after calling the super's constructor, I could just clear all the old inventory slots using List::clear and start over, so all my old code still works fine.

Tried it (I assume you mean ContainerPlayer). ContainerPlayer's constructor doesn't work for me since I'm adding and moving around slots.

I have a custom player container that has a full 3x3 crafting grid, and I'm updating to 1.12.2. It worked great before, but now it seems that changes introduced with the recipe book are causing me trouble. Specifically, when pressing E to open the player inventory, I get a crash: com.daeruin.primalcraft.inventory.PrimalContainerPlayer cannot be cast to net.minecraft.inventory.ContainerPlayer at net.minecraft.client.gui.inventory.GuiInventory.initGui(GuiInventory.java:72) ~[GuiInventory.class:?] The line in question is a new bit of code for the recipe book GUI that includes a cast to ContainerPlayer. This doesn't work for me since I'm replacing the container player with my custom one. I have tried/considered a few things. I tried just overriding the initGui method and casting to my custom player container instead, but there is a call to super.initGUI(). Since I'm extending GuiInventory it ends up processing the super's hard-coded cast to ContainerPlayer anyway. I think I need the call to super, because it goes way up the chain of inheritance to do lots of stuff like displaying potion effects and setting the location of the GUI. Unless maybe I need to duplicate all that stuff in my override instead? I tried making my PrimalContainerPlayer extend ContainerPlayer instead of Container. Unfortunately ContainerPlayer's constructor doesn't work for me since that's where all the inventory slots are created. I need different slots. I considered making my GUI extend InventoryEffectRenderer instead of GuiInventory, but that would require me to copy a ton of vanilla code. That seems like bad style since vanilla code could get change with an update, and my copied code wouldn't automatically reflect the changes. Is that the best choice here, or is there another solution? My player inventory GUI class: My container class:

Just ran across this example after reading this.

Here is a great example of how to use the new registry system. It doesn't demonstrate biomes, but all the concepts are the same.

If you're talking about me, I haven't released any mods yet. The one I'm working on is a really big idea that's taking me a long time. I only have a few hours a week to dedicate to this hobby.

Now that I'm doing it right, there is still a noticeable pattern: the colors form a 4x4 grid along the Y axis. However, it isn't that big of a deal since I decided I want to add more colors anyway.

I should not be trying to code when it's this late. I need to choose randomly among four or five options. getPositionRandom returns a long. I don't understand what it's doing to generate the random number, or if it could potentially generate a negative number. But I guess I need to do some maths like this? Math.abs(MathHelper.getPositionRandom(pos)) % 5;

Thank you for the correction. I misunderstood.

I started learning Java with Codecademy and reading through Oracle's Java tutorials. There are also a bajillion websites and blogs that will teach just about anything you need to know. While larsgerrits's advice on learning and getting comfortable with Java first is good, I think the amount of time you need to spend getting comfortable varies from person to person. I started modding almost immediately, with the philosophy of "learn by doing." I'm not a programmer, but I had some coding experience to rely on that let me get up to speed pretty fast. I still did more copy-pasta than I'm proud of in the beginning. And I'm still learning a lot as I go. You should probably spend more time learning Java than you feel like you will need. There are also a bajillion tutorials on modding with Forge. I started with Bedrock Miner. His tutorials are pretty comprehensive and great for beginners, but they are for 1.8.9 so a little out of date. Shadowfacts has great tutorials for beginners. Also check out Jabelar's website, Mcjty, Choonster's TestMod3 on Github, and The Grey Ghost's Minecraft by Example.

Yep, using that method does indeed make the issue go away. I used it like this: Random random = new Random(MathHelper.getPositionRandom(pos));

OK, one wrinkle with this, I guess because of how the math works out. If I only provide four leaf colors to choose randomly from, and use the BlockPos as the random seed, every block along the same Z axis ends up the same color. Easily solved by providing one extra color, but something to be aware of if someone is reading this later.

Often the best way to fix problems like this is to look at the vanilla code for a block that does the same thing. For example, check the code for pistons.

I don't think a lot has changed with respect to GUIs since 1.8.9. I don't recall changing much at all when I updated from 1.8.9 to 1.11.2. Jabelar's GUI page is probably still quite relevant.