Jump to content

TheKingElessar

Members
  • Posts

    45
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

TheKingElessar's Achievements

Tree Puncher

Tree Puncher (2/8)

1

Reputation

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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.
  6. 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!
  7. 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.
  8. No, it's maybe half a block beneath where the entity is rendered.
  9. 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.).
  10. I found this explanation here That's from here: https://bugs.mojang.com/browse/MC-103633
  11. 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.
  12. 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?
  13. 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!
  14. 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:
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.