TheKingElessar

Do you have the code used for the berry tree? That might be useful. I'd probably make an apple Block (with the appropriate model/texture). Then, add these abilities to it: When right clicked, the apple Block should disappear, and an apple Item should be added to the player's inventory. Every [whatever] seconds/minutes, an apple Block should have the chance to generate underneath oak (for now) leaves, provided they are connected to a tree and there's not already something there. To create a Block, see the documentation here. You'll want to extend the Block class and override the necessary methods. Then, register it. Here's an example of registering something: @ObjectHolder(MAINMODCLASS.MODID) public static Block APPLE_BLOCK; // This is a placeholder for when you register it later. This is the object you'll access whenever you want to reference/use the apple Block. and @SubscribeEvent public static void registerBlocks(final RegistryEvent.Register<Block> event) { IForgeRegistry<Block> blockRegistry = event.getRegistry(); blockRegistry.register(new BlockApple(Block.Properties.from(Blocks.OAK_LEAVES))); // This creates it with the same properties as Oak Leaves. } (This is for 1.13.2, but I think it should still be similar if not the same for 1.12.2.) Since you have the Block you can do other stuff with it now. Here's the documentation on player interaction. As to generating it on leaves; you'd probably want to look into Capabilities (if using an already existing tree/leaves) or adding it directly to your custom leaf block. I don't have experience with that so don't know what the best practice for it is. For the specifics, maybe take a look at the BlockCrops class, which implements/extends a couple of other classes that might be useful. You could probably extend the BlockCrops class if it fits your needs.

Okay, looking over tags I can't find any explanation of how they're used. However, I did suddenly realize that I could store the information in the entity's class... except, I can't. When I try to access what I've stored it's null, which means that the instance of the Entity used in doRender and the instance used when I spawn it in the world are two different ones, even when I store it in the entity's class after it's spawned. I'm not quite sure what to do now!

I want to change how an Entity is rendered based on some conditions in the world when it's spawned. I tried adding a Tag to it right before calling spawnEntity, but then, in the Entity's doRender method, the size of the tags is 0. Here's what I tried with the Tags. toSpawn.addTag(message.blockSide); // message.blockSide is a string that tells what side of a block it's being spawned on Then, in the Entity's rendering class' doRender method: Set<String> tags = entity.getTags(); System.out.println("Tags length: " + tags.size()); // Prints "Tags length: 0" What are some ways I can accomplish this?

Haha, fair enough! I still need to update. I've been avoiding it.

Alright, I figured out what it was. An Entity's rotationPitch field controls the pitch of the entity's head, not the entire body. EntityEvokerFangs don't have a head; therefore, there wasn't any pitch to set, so I wasn't seeing any change. So, in order for me to do what I'm trying to do, I'm going to have to do a bunch of rendering stuff to rotate an entire entity. That should be fun. If anybody has any suggestions on changing the pitch of an entire entity, feel free to send them my way!

Unfortunately, since 1.7.10 was released almost 5 years ago it's no longer supported on this forum. Why not switch to 1.13?

I don't know what the forum's opinion on bumping topics is, but if anyone has any insight on this I'd appreciate it!

To get the block activation from the block side (as opposed to the item side), for example if you're making a new block, then use onBlockActivated. See here. If you want to do it from the item side, use onItemRightClick. To get the block you're looking at you can use the client's (Minecraft.getInstance()) objectMouseOver field. If that doesn't have the block, you might have to get another field from objectMouseOver, probably a RayTraceResult (if I recall correctly). If you take this route you'll probably have to send the result from the client to the server using packets.

Did you do all of this? (for some reason on my end the quote isn't showing up correctly, hopefully it works) If you did follow it exactly like that paragraph, you would have created a new profile with a different directory. That means it would have separate mods, worlds, logs, etc. then whatever other directories you might have. If you want to access worlds in other directories, you'd need to copy the world save file from your old directory (where its currently located) to the saves folder in the new one you just created with the fresh Forge install.

I'm trying to spawn an entity, in this example EvokerFangs, and have it be rotated. I can set its yaw (turning left/right) fine, but not its pitch (up/down). Since rotationPitch is a field I assume it's possible. Here's my code: EntityEvokerFangs toSpawn = new EntityEvokerFangs(senderWorld); // senderWorld is a world retrieved from the context of a packet toSpawn.setPosition(message.x, message.y, message.z); toSpawn.rotationPitch = 45F; System.out.println("Pitch: " + toSpawn.rotationPitch); // Prints 45 toSpawn.rotationYaw = 45F; System.out.println("Yaw: " + toSpawn.rotationYaw); // Prints 45 senderWorld.spawnEntity(toSpawn); // Spawned with a 45 yaw but not picth What's going on here?

@Cadiboo @Draco18s Alright, thanks! It was an easy question with a simple answer!

In the documentation for 1.12 it mentions proxy classes. However, in 1.13 it doesn't. There are a bunch of changes between the two versions' documentation related to Sides, so with all the changes does that mean that separate Proxy files are no longer needed? I watched a couple of YouTube modding tutorials, and they had me set up the Proxy files, but since they used Common and Client proxies I don't think that's accurate (since Common proxies don't make any sense, and because of the changes in the documentation). However, I've been looking at the Iron Chest mod (since it's open source and updated for 1.13), and they have Server and Client proxies. The Server proxy has only one method aside from preInit (which is empty): public World getClientWorld() { return null; } The client proxy has stuff related to rendering the mod's tile entities. They then register it using this (which admittedly I don't understand the intricacies of, but it makes sense): public static ServerProxy proxy = DistExecutor.runForDist(() -> ClientProxy::new, () -> ServerProxy::new); However, is this technique the preferred and agreed-upon (in the community) way of doing it?

Oh, okay. That makes sense. Sort of like how you want to initialize Items in an @ObjectHolder as null, but then assign them in the registration. Okay! I'll look into functional interfaces!

Actually, could you go into this a little more? I'm not quite understanding how you can avoid a static variable but still let it be referenced by an Item that's created.

So the class extending net.minecraft.item.ItemGroup (in my case ModItemGroup) is created, the IItemProvider "icon" contains a null Item because the Item it refers to hasn't been registered yet, then createIcon is called after Item initialization, which creates a new ItemStack from the Item stored in "icon". This last part I'm not quite understanding: when the ItemStack is created, doesn't it use the null Item? As far as I can tell it doesn't recreate it or refresh it or whatever. I was about to ask why you wouldn't do it after all the items have been registered, therefore avoiding this entire problem, but then I realized when items are registered they have to be initialized, meaning they have to be assigned (if you want them part of one) to an ItemGroup. Okay, I think I understand it all now except for my above question. Thanks for the explanation!

So I was able to get the @ObjectHolder annotation working for my Items, but my ItemGroups are still using static initializers. Since you don't register ItemGroups how should I do this with them?

Awesome, thanks! I'll take a look!

@Draco18s Thanks! Could you point me to an explanation for how to avoid using static initializers?

It took me a good while to finally wrap my head around the lambda statement, but I finally understand it! Your solution works great. Question: Why is this? How is this different from my original (not working) method? Does it have to do with this code in the ItemStack constructor? this.item = itemIn == null ? null : itemIn.asItem(); When modItem hasn't been created yet and modItemGroup is created, does it set the modItemGroup's ItemStack's Item as null? If so, how does it then update it? I could be very far off the mark for why it works, though, so please correct me. Another question: I'm pretty (completely) new to Forge, what are some alternatives to static initializers? Is the static keyword even needed? That's just what I saw being used in one case online.

This picture shows it perfectly. The item's texture works fine, but when it is used in an ItemGroup it doesn't show up. There's nothing in the log that indicates a problem. The ItemGroup is created with the item shown there using this: public static final ModItemGroup modItemGroup = new ModItemGroup("ModItemGroup", new ItemStack(ItemInit.moditem)); Which refers to this: public class ModItemGroup extends net.minecraft.item.ItemGroup { private ItemStack icon; public ModItemGroup(String label, ItemStack icon) { super(label); this.icon = icon; } @OnlyIn(Dist.CLIENT) @Override public ItemStack createIcon() { return icon; } } The item it's using is very simple, but just in case I set it up incorrectly here it is: public class ModItem extends Item { public ModItem() { super(new Properties().group(ItemGroupInit.modItemGroup)); } } What's going on here?