TheKingElessar

First off... I do have to use 1.8.9 because that's what the server is on. I'm using Forge 1.8.9-11.15.1.1722 with the classpaths from the 2.1 snapshot. I'm trying to make a client-side inventory managing mod. I can move ItemStacks around fine in single-player, but I don't think that's gonna cut it for multiplayer. I've looked through the mod InventoryTweaks (1.8.9 version), but none of the packets reveal anything. I'd rather not look through the entire mod because it's pretty complex. I looked at the vanilla packets, but I can't find anything either. Two vanilla packet types are sort of similar, C09PacketHeldItemChange and C10PacketCreativeInventoryAction, but neither handle moving items around in the inventory of a survival player. GuiInventory doesn't handle the moving of the items. GuiContainer seems to handle it, but only client-side, and doesn't send anything to the server. It looks like the most likely option is using the InventoryPlayer class to change the player inventory, and the ContanerChest and similar container classes to change container inventories. The boolean inventoryChanged and method markDirty seem to be sort of what I'm looking for, but I can't find where they're used in the vanilla code—my IDE (Intellij) can't find them, but maybe I'm not searching it correctly.

Okay, thank you!

So really, I should just use floats in most cases. I'm not super experienced in Java, and everything I found online suggested that you should use doubles by default and floats only in really intensive programs.

Minecraft is written using float instead of double, and I assume it's to speed up calculations. Do I need to worry about that, or only if my mod does a ton of calculations? Are modern computers good enough that it doesn't matter?

Assuming you're on Windows, you can get it by pressing the Windows key (the four boxes near the Alt and Ctrl keys on the left) and the R key at the same time, then typing in %appdata% and pressing enter, then opening the Roaming folder, then the .minecraft folder, then the logs folder, then copying the contents of latest.log to Pastebin or Gist or uploading the file somewhere.

If you mean specifying the level of tool needed to break it, that's in the Block.Properties class. Take a look at the Materials (might be just Material) class to help. I'm not at my computer right now, but I'm pretty sure all that's correct.

It never occurred to me to check the bounding boxes - I'll bet this had something to do with me not setting the proper origin in Blockbench. Thanks!

Go to https://pastebin.com/ and paste the contents of the debug.log file into the big area, then click "Create New Paste", then copy the link to the page and post it here.

No, it's maybe half a block beneath where the entity is rendered.

An Entity has a total height value. It also has an eye height value. I took what you said to mean that the eye height value is a percentage of the total height value. So, if an Entity's height is 10, and it has an eye height of .6, the Entity's eye height would be 60% of 10 (which of course is 6). However, that wouldn't make sense when the Entity's eye height is greater than 1, which the EntityPlayer's is (when standing it's 1.62). So, to try and reconcile this, I just looked at some other Entities. This may look like a long post, but it's nothing complicated. If you don't want to look at this you can skip to the end! It seems that EntitySheep uses a relative height. public float getEyeHeight() { return 0.95F * this.height; } EntityZombie uses a hard-coded one that depends on whether or not it's a child: public float getEyeHeight() { float f = 1.74F; if (this.isChild()) { f = (float)((double)f - 0.81D); } return f; } EntityEnderman is hard-coded even simpler: public float getEyeHeight() { return 2.55F; } EntityPig doesn't override the getEyeHeight method from Entity, so it uses the default one in Entity, which is a relative one: public float getEyeHeight() { return this.height * 0.85F; } Finally, EntityPlayer is much more complicated because of all the ways Player heights change: private float eyeHeight = this.getDefaultEyeHeight(); public float getDefaultEyeHeight() { return 1.62F; } public float getEyeHeight() { float f = eyeHeight; if (this.isPlayerSleeping()) { f = 0.2F; } else if (!this.isSwimming() && !this.isElytraFlying() && this.height != 0.6F) { if (this.isSneaking() || this.height == 1.65F) { f -= 0.08F; } } else { f = 0.4F; } return f; } An Entity's height is set using Entity's setSize method. Normally, for the EntityPlayer, it's 1.8F. Which means that the hardcoded eye height value of 1.62F should work for my purposes! Since it doesn't, I can only assume that it has something to do with my model or rendering, because of what I mentioned earlier: However, I can't see anything wrong with my rendering/model classes. I'll rename the question now that I have a better idea what's going on (or if that isn't possible I'll make a new one.).

I found this explanation here That's from here: https://bugs.mojang.com/browse/MC-103633

I don't think that's the case because a Player's eye height is normally 1.62. I played around with my entity some more, and now I'm confident it's related to my model or the entity rendering. The larger I set its scale (ModelRenderer::render), the higher it is. I think there must be some empty space beneath it that for some reason is part of the model. Here's my model class, can anyone provide some insight into why it's doing this? @OnlyIn (Dist.CLIENT) public class ModelMyEntity extends ModelBase { private final ModelRenderer main; private final ModelRenderer nose_pyramid; private final ModelRenderer main_body; private final ModelRenderer tail_pyramid; public ModelMyEntity() { textureWidth = 64; textureHeight = 64; main = new ModelRenderer(this); main.setRotationPoint(0.0F, 24.0F, 0.0F); nose_pyramid = new ModelRenderer(this); nose_pyramid.setRotationPoint(0.0F, 0.0F, 0.0F); main.addChild(nose_pyramid); nose_pyramid.cubeList.add(new ModelBox(nose_pyramid, 24, 33, -1.5F, -1.5F, -6.75F, 3, 3, 1, 0.0F, false)); nose_pyramid.cubeList.add(new ModelBox(nose_pyramid, 6, 42, -0.5F, -0.5F, -7.75F, 1, 1, 1, 0.0F, false)); main_body = new ModelRenderer(this); main_body.setRotationPoint(0.0F, 0.0F, 0.0F); main.addChild(main_body); main_body.cubeList.add(new ModelBox(main_body, 0, 14, -1.5F, -2.5F, -5.75F, 3, 1, 11, 0.0F, false)); main_body.cubeList.add(new ModelBox(main_body, 28, 0, -1.5F, 1.5F, -5.75F, 3, 1, 11, 0.0F, false)); main_body.cubeList.add(new ModelBox(main_body, 0, 28, 1.5F, -1.5F, -5.75F, 1, 3, 11, 0.0F, false)); main_body.cubeList.add(new ModelBox(main_body, 28, 14, -2.5F, -1.5F, -5.75F, 1, 3, 11, 0.0F, false)); tail_pyramid = new ModelRenderer(this); tail_pyramid.setRotationPoint(0.0F, 0.0F, 0.0F); main.addChild(tail_pyramid); tail_pyramid.cubeList.add(new ModelBox(tail_pyramid, 24, 28, -1.5F, -1.5F, 5.25F, 3, 3, 2, 0.0F, false)); tail_pyramid.cubeList.add(new ModelBox(tail_pyramid, 0, 42, -0.5F, -0.5F, 7.25F, 1, 1, 2, 0.0F, false)); } @Override public void render(Entity entity, float f, float f1, float f2, float f3, float f4, float f5) { main.render(f5); } public void setRotationAngle(ModelRenderer modelRenderer, float x, float y, float z) { modelRenderer.rotateAngleX = x; modelRenderer.rotateAngleY = y; modelRenderer.rotateAngleZ = z; } } Edit: The model was made with BlockBench.

EDIT: I'VE DECIDED THIS DOESN'T HAVE TO DO WITH THE EYE HEIGHT LIKE I SAID IN THIS OP, SO GO TO THIS POST IN THIS THREAD TO SEE THE LATEST DETAILS: I'm trying to spawn an Entity at a Player's eye height. Here's the y-level I'm trying to use: player.posY + (double)player.getEyeHeight() - (double)0.1F That's pulled directly from a constructor in the EntityArrow class. However, it's spawning the Entity way too high. If I replace the above statement with 0.95 it spawns at pretty much exactly eye level, but the eye level of a Player is supposedly 1.62 everywhere I look (Gamepedia, EntityPlayer::getEyeHeight and ::getDefaultEyeHeight, etc.). The Entity I'm spawning is custom - could this problem have something to do with my model (which is why it appears higher), or is there something I'm not understanding about the eye height of a Player?

This seems to be your problem. According to the documentation here, the proper type is "minecraft:crafting_shaped", not "crafting_shaped". It looks like that by leaving off "minecraft:" the game assumes you are using a custom recipe, which is why it's looking for the recipe type "sm:crafting_shaped" ("sm" must be your modid). If you're trying to use a custom recipe type, perhaps the name you gave it in your _factories.json file isn't "crafting_shaped" because you had a typo. On another note, it would be good to get a longer modid. You might be using a two-letter one because of a tutorial you followed, but there is pretty much no reason to not use a longer, more descriptive one. That will minimize the chances for conflicts between your mod and other mod!

Here's some code with explanations on how to send packets from the client to the server that I threw together. Sending a packet from the server to a client seems to use the same concepts. From the Forge documentation: // Sending to one player ModPacketHandler.INSTANCE.send(PacketDistributor.PLAYER.with(playerMP), new ExamplePacket()); // Send to all players tracking this chunk ModPacketHandler.INSTANCE.send(PacketDistributor.TRACKING_CHUNK.with(chunk), new ExamplePacket()); // Sending to all connected players ModPacketHandler.INSTANCE.send(PacketDistributor.ALL.noArg(), new ExamplePacket()); I don't actually know how a client would go about receiving a packet. I'd recommend looking at these two threads on these forums:

I was trying to bind a texture to a custom Entity and read the page here on ResourceLocations. It says: "When ResourceLocations refer to textures in models, the paths are taken to be relative to textures/ (e.g. examplemod:blocks/test → assets/examplemod/textures/blocks/test.png)." So, if I wanted to reference the file assets/mymodname/textures/entity/test_mob.png, I should do: private static final ResourceLocation TEST_MOB = new ResourceLocation("mymodname:entity/test_mob"); However, when I do that I get a FileNotFoundException. Doing this, however, works perfectly: private static final ResourceLocation MOB_TEXTURE = new ResourceLocation("mymodname:textures/entity/test_mob.png"); What's going on here? Am I misinterpreting the documentation?

I'm not familiar with the cause, but it'd probably help if you clarified this: By unusable do you mean that you can't open the GUI again or that the crafting ability doesn't work?

It looks like you want your EntityThrowableSlimeTorch class extends the EntityThrowableTorch class. However, based on what you posted here you haven't imported the proper class. Without being able to see the rest of your code, I think what's happening is that EntityThrowableSlimeTorch looks for EntityThrowableTorch in the same directory that it's in (because it hasn't been imported), which means it's looking for de.krokoyt.throwabletorchmod.EntityThrowableTorch. I guess that EntityThrowableTorch isn't in that location. Try importing the EntityThrowableTorch class using something like: import de.krokoyt.throwabletorchmod.some_other_thing.EntityThrowableTorch Obviously use the actual file location, though.

When I started learning to mod a couple of months ago I found this channel. As far as I can tell (I only watched the first couple of videos) it's not super bad, but there are several things that you'll want to change, such as the proxies we've already mentioned in this thread. It looks like there are a lot of concepts covered in the series, so it's probably a good starting point to teach you the more specific parts of larger concepts covered in the official documentation. Keep in mind that the tutorials are for 1.13.2, not the latest 1.14.2. The documentation hasn't been updated, either, but it's really valuable once you start to understand how modding the game works. You're going to need a good grasp on the Java language in order to be able to do what you want - just copying/pasting code from the forums won't get you anywhere in the long run! Are you using Eclipse to write/organize the code? If so, when you enter "gradlew runClient" in the terminal there should be a log output into the terminal.

You probably want the ItemTool, ItemTiered, and ItemAxe classes. Edit: Didn't see this was for 1.14. Draco is right. As for Properties, look at the Item.Properties class. It's exactly what it sounds like, things such as max stack size, whether or not it can be repaired, etc.

What Minecraft version? It doesn't look like this is for 1.13 or later. I'm noticing several things. You use CreativeTabs instead of ItemGroups (CreativeTabs are for older versions, I don't know exactly when it changed). You're using a Common proxy, which goes against the idea of a proxy. If a common proxy is run on both the client and the server, why do you need a separate proxy?You're using an IHasModel interface. See #3 here. You're using an ItemBase class instead of separate classes for each Item, which seems kind of weird to me, though I don't know if it works or not (I'm not too experienced in that). I'm not sure what's causing the problem, though. Assuming you're using an IDE, when you try running it through the terminal (using "gradlew runclient") can you give us the output?

Is player.getServer() returning null, or is the player you want from the event returning null?

Yeah, I got what I wanted working by changing how it was rendered, but it suddenly occurred to me yesterday that I could look into the "Dinnerbone" nametag code. I'll take a look at those things!

Awesome, that's what I need! I spent a while looking at Capabilities, but I guess that's not the solution. I'll take a look at IEntityAdditionalSpawnData! Thanks!

If the mod isn't open source, which (as far as I can tell) it isn't, it's going to be tough to get the code. You'll probably have to implement it from scratch! Earlier I recommended looking at the BlockCrops class, but I'm not sure that's actually the best base to build off of, since you just want one type of apple that appears, not one that grows over time. Instead, you probably want to look at dirt and dirt with grass, since dirt can turn into dirt with grass in Vanilla Minecraft. It looks like the class BlockDirtSnowySpreadable will be what you want. It may look complicated at first, but if you really take some time to understand how the vanilla code works it will help. I'd recommend getting the code working before you worry about aesthetics. Use a normal, solid block model (like Stone) with a simple texture (like completely red). Then, once it's working, you can worry about modeling it (which I'm not sure how to do, I'm sure somewhere on these forums or elsewhere online there's a good explanation).