TheGreyGhost

Awesome

Hi This link might be useful https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe60_network_messages/Notes.txt and this working example https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe20_tileentity_data/Notes.txt -TGG

Hi 1.7.10 or 1.8? If 1.8, these links might be useful http://greyminecraftcoder.blogspot.com.au/2015/01/client-server-communication-using-your.html and a working tutorial example https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe60_network_messages/Notes.txt -TGG

You're welcome Yes. But in general a model may have any mixture of faceQuads and GeneralQuads - it may have all faceQuads, all generalQuads, or a mixture of both. faceQuads is mostly useful for blocks which don't draw some of their faces when they are next to each other. For example stone. Two stone blocks next to each other don't need to draw the two faces where they are touching. General quads are usually for odd-shaped faces such as the torch, or the ladder. Yes - you need to find the offset corresponding to VertexFormatElement.EnumUsage UV. If it's the standard format, vertexToInts() in this class https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe15_item_smartitemmodel/ChessboardSmartItemModel.java gives you the info you need - also shows you how to go from float to int, you just need to find the function to go back the other way from rawInts to float If you want to code for any generic VertextFormat, I think you should be able to iterate through its elements, find the one for UV, and get its offset. No problem. Just create your own class extending IFlexibleBakedmodel and store your modified BakedQuads in it, then return it from handleBlockState. When your IFlexibleBakedModel instance is called i.e.getGeneralQuads or getFaceQuads, return your modified BakedQuads. -TGG

Hi the getTexture method is not generally used for rendering the block - it is used (for example) for the 'exploding shards' that you get when you destroy a block by digging it. In order to change the texture, you will need to change the BakedQuad data (each BakedQuad in your BlockModel is made up of four corners (vertices) - and at each vertex, it records the [x,y,z] position as well as a texture coordinate [u,v]. All of the textures for blocks and item models are "stitched together" into a large texture sheet, see the "Texture Coordinates" diagram on this page halfway down http://greyminecraftcoder.blogspot.co.at/2014/12/the-tessellator-and-worldrenderer-18.html You will need to create your BakedQuads with the correct texture coordinates of the new texture An example of how you can do this is in MBE15, this class works for the faces of the cube https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe15_item_smartitemmodel/ChessboardSmartItemModel.java see createBakedQuadForFace(). FaceBakery.makeBakedQuad() can be useful for generating quads If you want to change a model with arbitrary quads (not just the NEWSUD faces of the cube) then you can probably read the quads from the base model one by one, convert the int arrays to vertex data, replace the [u,v] with the new [u,v], and create a new list of BakedQuads from it. Haven't tried it, but it should work. -TGG

Added a ISmartItemModel tutorial to MinecraftByExample in case you are still interested. https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe15_item_smartitemmodel -TGG

This link might help http://greyminecraftcoder.blogspot.com.au/2015/03/troubleshooting-block-and-item-rendering.html -TGG

The MBE01, MBE03, and MBE11 MinecraftByExample project literally shows you exactly what to do for blocks, items, blocks with variants, items with variants. You just need to spend a bit of time understanding what it does and how it works. -TGG

The look vector won't work because it will be behind the player's head, not behind the player's body. They are often not pointing the same way. That's why you need to use player.rotationYaw. The math in the player.getLook() is the same as what you want to do, except you use rotationYaw instead of head's yaw, and can ignore pitch. -TGG

Some examples of typical recipes https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe35_recipes/StartupCommon.java with pictures here http://greyminecraftcoder.blogspot.com.au/2015/02/recipes.html -TGG

If you are trying to send from the client to the server, you will need a custom packet. For example, in GUIrepair.renameItem() this.mc.thePlayer.sendQueue.addToSendQueue(new C17PacketCustomPayload("MC|ItemName", (new PacketBuffer(Unpooled.buffer())).writeString(s))); which is processed on the server in NetHandlerPlayServer.processVanilla250Packet(C17PacketCustomPayload packetIn) else if ("MC|ItemName".equals(packetIn.getChannelName()) && this.playerEntity.openContainer instanceof ContainerRepair) { ContainerRepair containerrepair = (ContainerRepair)this.playerEntity.openContainer; if (packetIn.getBufferData() != null && packetIn.getBufferData().readableBytes() >= 1) { String s = ChatAllowedCharacters.filterAllowedCharacters(packetIn.getBufferData().readStringFromBuffer(32767)); if (s.length() <= 30) { containerrepair.updateItemName(s); } } else { containerrepair.updateItemName(""); } } or for the example of a merchant trade else if ("MC|TrSel".equals(packetIn.getChannelName())) { try { int i = packetIn.getBufferData().readInt(); Container container = this.playerEntity.openContainer; if (container instanceof ContainerMerchant) { ((ContainerMerchant)container).setCurrentRecipeIndex(i); } } catch (Exception exception2) { logger.error("Couldn\'t select trade", exception2); } } I think you will need to create your own custom packet and perform a container check (similar to above) on the EntityPlayerMP that you are given in the message handler. Here's a working example of network messages that might help https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe60_network_messages/Notes.txt Also some background info http://greyminecraftcoder.blogspot.com.au/2015/01/the-client-server-division.html (and its sub-topics) -TGG

Are you sure your NBT load/save code is correct? (remember to call super.readFromNBT() as the first line?) Are your getDescriptionPacket() and onDataPacket() correct? A working example: https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe20_tileentity_data/TileEntityData.java -TGG

hi double posX = (double)player.posX + (double)(this.rand.nextFloat() * player.width * 2.0F) - (double)player.width; double posY = player.posY + 0.8D + (double)(this.rand.nextFloat() * (player.height / 4)); double posZ = (double)player.posZ + (double)(this.rand.nextFloat() * player.width * 2.0F) - (double)player.width; these [posX, posY, posZ] tell your particle where to spawn. currently you are choosing values centred around the player pos. eg posX = player's Xpos, plus a random value from 0 to 2* players width, minus the players width i.e player's Xpos plus a random value from minus width to plus width You need to choose values centred behind the player, and also probably have a start velocity pointing away from the player. player.rotationYaw will tell you which way the player is facing. You can convert an angle (yaw) to a deltaX, deltaZ using these formulae float deltaZ = MathHelper.cos((float)(-yaw * 180.0/Math.PI - Math.PI)); float deltaX = MathHelper.sin((float)(-yaw * 180.0/Math.PI - Math.PI)); -TGG

If Ernio's excellent advice doesn't work, post your error log... -TGG

Sure you can: [nobbc][/nobbc]. [nobcc][nobbc][/nobbc][/nobbc] works like magic ha - that's the same mistake I always make bbc not bcc... -TGG

my guess: you're allocating a new one every tick and not discarding the old ones. -TGG

Fixed it... Thanks for the bug report Cheers TGG

OK, I will try to reproduce the problem here, sounds like it's something simple. The deprecated stuff (IBakedModel) is just because there is a newer Forge interface that's intended to replace it (but to be honest I think 95% of modders will have no interest in), I think you can safely ignore the deprecation warnings. Thanks for the feedback! -TGG

Oh, you mean- when you use the camera item after updating forge to 11.14.1.1402, it no longer works? But it did work before? I updated it with a couple of bugfixes recently but perhaps I broke something. I will test again... And you're talking about the camera item in MinecraftByExample, not the standalone GitHub ItemTransformHelper (or PlanetMinecraft d/load)? -TGG

If your items are all identical except each one has a different texture, then yeah I would use the ISmartItemModel. Create one model file with 130 defined textures, then your ISmartItemModel tweaks its bakedquad list to choose the correct texture coordinates -TGG

Ah that's annoying, a regression bug perhaps... What version did you try that didn't work? (where did you get it from?)

Hi Funnily enough I'm working on this right now... it's very similar to MBE04 - uses ModelBakeEvent to inject itself into the model registry. I am just figuring out how to generate the BakedQuads algorithmically; based on this code https://github.com/MinecraftForge/MinecraftForge/blob/master/src/test/java/net/minecraftforge/debug/ModelBakeEventDebug.java (The test code is a pretty good example to learn from, too) If your 130 variants are made up of a few simple components, ISmartItemModel is probably the best way I reckon. Alternatively, if you are just (say) changing colours like eggs or potions you could use the item layers instead. -TGG

Hi These links might help a bit with the background logic behind TileEntities and especially Containers http://greyminecraftcoder.blogspot.com.au/2015/01/tileentity.html http://greyminecraftcoder.blogspot.com.au/2015/01/gui-containers.html Simple information can be sent from the server container to the client container using the crafters member variable of the container - icrafting.sendProgressBarUpdate() and icrafting.updateProgressBar() - if you are just sending a single number. This tutorial project has a working example for 1.8, almost identical for 1.7.10. https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe31_inventory_furnace and especially /* Client Synchronization */ // This is where you check if any values have changed and if so send an update to any clients accessing this container // The container itemstacks are tested in Container.detectAndSendChanges, so we don't need to do that // We iterate through all of the TileEntity Fields to find any which have changed, and send them. // You don't have to use fields if you don't wish to; just manually match the ID in sendProgressBarUpdate with the value in // updateProgressBar() // The progress bar values are restricted to shorts. If you have a larger value (eg int), it's not a good idea to try and split it // up into two shorts because the progress bar values are sent independently, and unless you add synchronisation logic at the // receiving side, your int value will be wrong until the second short arrives. Use a custom packet instead. @Override public void detectAndSendChanges() { super.detectAndSendChanges(); boolean allFieldsHaveChanged = false; boolean fieldHasChanged [] = new boolean[tileInventoryFurnace.getFieldCount()]; if (cachedFields == null) { cachedFields = new int[tileInventoryFurnace.getFieldCount()]; allFieldsHaveChanged = true; } for (int i = 0; i < cachedFields.length; ++i) { if (allFieldsHaveChanged || cachedFields[i] != tileInventoryFurnace.getField(i)) { cachedFields[i] = tileInventoryFurnace.getField(i); fieldHasChanged[i] = true; } } // go through the list of crafters (players using this container) and update them if necessary for (int i = 0; i < this.crafters.size(); ++i) { ICrafting icrafting = (ICrafting)this.crafters.get(i); for (int fieldID = 0; fieldID < tileInventoryFurnace.getFieldCount(); ++fieldID) { if (fieldHasChanged[fieldID]) { // Note that although sendProgressBarUpdate takes 2 ints on a server these are truncated to shorts icrafting.sendProgressBarUpdate(this, fieldID, cachedFields[fieldID]); } } } } // Called when a progress bar update is received from the server. The two values (id and data) are the same two // values given to sendProgressBarUpdate. In this case we are using fields so we just pass them to the tileEntity. @SideOnly(Side.CLIENT) @Override public void updateProgressBar(int id, int data) { tileInventoryFurnace.setField(id, data); } -TGG

I reckon the first thing you should do is to write down a couple of paragraphs on how the algorithm is supposed to work. Maybe draw a sketch on a piece of paper too. You might realise halfway through you've made a wrong assumption. -TGG

By crikey dude, there's no chance of me helping you debug that without some proper commenting to explain the algorithm you are using. -TGG