TheGreyGhost

Hi As SanAndreasP said, you can pack multiple data into a single nibble so long as you don't try to cram too much in! If it helps you understand it, you can write all sixteen combinations out META binary STATE SIZE STATE SIZE 0 0000 0 000 off tiny 1 0001 0 001 off little 2 0010 0 010 off small 3 0011 0 011 off medium 4 0100 0 100 off large 5 0101 0 101 off big 6 0110 0 110 off huge 7 0111 0 111 off enormous 8 1000 1 000 on tiny 9 1001 1 001 on little 10 1010 1 010 on small 11 1011 1 011 on medium 12 1100 1 100 on large 13 1101 1 101 on big 14 1110 1 110 on huge 15 1111 1 111 on enormous His suggestion on using 4 different blocks is a good one, and it's not hard to do. If there will only ever be a few of your blocks (like chests), then TileEntities are fine. If you might have lots (hundreds or thousands) of your blocks lying around, like trees for example, then use the multiple blocks methods because the TileEntities will probably cause a lot of lag. -TGG

100 times per second! Yikes! Perhaps you should rethink your approach, there is no way you can accurately send 100 packets per second over a network. Luckily there's no need! All you need to tell the server is when the stream of bullets starts, and when it finishes (i.e. when the user clicks down, and when they click up). No need to send a packet for each one. Likewise, no human will notice the difference between a mouse click that lasts for 0.10 seconds and 0.11 seconds. Will it really affect affect your gameplay if you "only" check for mouse click / keypresses 20 times per second instead of 100? I also think that creating 100 entities per second is going to create ridiculous lag - imagine a single server with (say) 4 players firing at the same time - that's 400 entities per second, each sent to 4 clients, a total of 1600 entity updates over the network every time they move. What I'd suggest instead is that you forget entirely about creating bullets as entities. Let each client render the bullets as "fake" entities (similar to particle effects), and all the server needs to do is tell each client where the stream of bullets starts and when it finishes. The server does some basic hit calculations based on the straight line path of each bullet, and applies the appropriate damage. The client does the same calculations for the purposes of rendering the bullets and any hit effects (like ricochet sounds or puffs of dust or whatever). -TGG

Hi keen, glad you figured it out :-) I use IntelliJ and I think it's awesome. With the gradle build it's become really easy to set up. I've had no experience with Eclipse so I can't really comment, except that plenty of other folks use it so it must be good enough! -TGG

Hi You could try something like this (In your Item class:) private static Icon itemIcon1; private static Icon itemIcon1; @Override public void registerIcons(IconRegister iconRegister) { itemIcon1 = iconRegister.registerIcon("myMod:itemIcon1"); itemIcon2 = iconRegister.registerIcon("myMod:itemIcon1"); } @Override public Icon getIconIndex(ItemStack thisItem) { int evolutionMeter = thisItem.getTagCompound.getInteger("evolutionMeter"); // add error -checking here yourself... if (evolutionMeter >= 30) { return itemIcon1; } else { return itemIcon2; } } Disclaimer: I haven't tried to compile this code so it might have some errors in it, but the concepts should work. (Based on GotoLink's answer, just that the method name was slightly wrong) -TGG

Hi Perhaps something to do with this? http://greyminecraftcoder.blogspot.com.au/2013/07/rendering-non-standard-blocks.html (i.e. perhaps the flags are not being reset properly?) -TGG

Hi I'd suggest you should use preInit, Init etc to explicitly control when your variables are initialised and items registered etc. Static initialisers can bite you in the butt if they don't run when you expect and your registrations etc occur at the wrong time. A bit more info here http://greyminecraftcoder.blogspot.com/2013/11/how-forge-starts-up-your-code.html It's for 1.6.4 but the concepts are the same for 1.7.2 -TGG

Hi This link might be of some help http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html especially http://greyminecraftcoder.blogspot.com.au/2013/09/custom-item-rendering-using.html and http://greyminecraftcoder.blogspot.com.au/2013/09/sample-code-for-rendering-items.html -TGG

Hi This link might help http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html In particular http://greyminecraftcoder.blogspot.com.au/2013/08/rendering-inventory-items.html .getIcon is called by the renderer every time your item is rendered. If you override getIcon to return a different texture, the item will be rendered using that different texture. -TGG

Hi This link might help a bit http://greyminecraftcoder.blogspot.com/2013/10/user-input.html You have to be careful with isPressed(), it is poorly named. .isPressed() which returns true if the key has been pressed. It should really be called retrieveKeyPress() or similar: KeyBinding counts the number of times that user pushes a key, i.e. pressing and holding for 2 seconds still only counts as a single push. Each time isPressed is called, it decreases this count by one. (A better name for .pressTime would be .pressCount, similarly.onTick() would better be called incrementPressCount() ). just read .pressed instead (is true if this key is being held down) Perhaps you could describe in more detail what you're trying to do. It is possible to get more control over right clicking, but it is complicated and a bit of a hack, and might not be necessary for you. -TGG

Hi PHP huh? You might be just the person to write the web-based interface that replaces MCPbot... seriously... http://www.minecraftforge.net/forum/index.php/topic,15823.0.html http://www.minecraftforge.net/forum/index.php/topic,13353.msg81827.html#msg81827 http://www.minecraftforge.net/forum/index.php/topic,13353.msg81663.html#msg81663 If you could figure out a way to let modders do the deobfuscation / renaming using their IDE and just upload to the server instead of relying on chatbot, with some sort of quality control / voting / reputation etc to prevent sabotage, it would take a huge load off the MCP guys and probably speed things up enormously. MCPbot is better than nothing but it's pretty cumbersome. -TGG

Hi You can get the direction that the entity is looking in using EntityLivingBase:: /** * interpolated look vector */ public Vec3 getLook(float partialTick) I would suggest the following algorithm: (1) calculate the displacement of the player relative to the entity (i.e. create a Vec3 of [playerx-entityx, playery - entityy, playerz-entityz]. You can get their positions using EntityLivingBase.getPosition(partialTick). (2) Calculate the dot product of the displacement vector with the look vector (use displacementVector.dotProduct(lookVector)). If the dot product is negative, the two vectors are pointing in opposite directions and so the entity is facing the wrong way to see the player. (3) if the dot product is positive, calculate the canEntityBeSeen method to check whether there are walls etc in the way. If you want to narrow the entity's field of vision below 180 degrees, perform normalize on the two vectors first, and compare it to the cosine of half the angle of vision. For example: you want the field of vision to be 120 degrees. cosine of 120/2 degrees is 0.5. So dotProduct = displacementVector.normalize().dotProduct(lookVector.normalize()); if (dotProduct >= 0.5) { // he's looking at me -TGG

Hi In that case, I suggest you try to trace through the vanilla code when it goes to render your item. This diagram for 1.6.4 might help you. http://greyminecraftcoder.blogspot.com.au/2013/08/rendering-first-person-view-items.html ItemRenderer:: // JAVADOC METHOD $$ renderItem public void renderItem(EntityLivingBase par1EntityLivingBase, ItemStack par2ItemStack, int par3, ItemRenderType type) { GL11.glPushMatrix(); TextureManager texturemanager = this.mc.getTextureManager(); Item item = par2ItemStack.getItem(); Block block = Block.getBlockFromItem(item); IItemRenderer customRenderer = MinecraftForgeClient.getItemRenderer(par2ItemStack, type); // breakpoint here if (customRenderer != null) If customRenderer comes back null, you've got a registration problem. By inspecting customItemRenderers in MinecraftForgeClient you should be able to figure out what you've done wrong. -TGG -TGG

Hi Try looking in CommandWeather That's how vanilla turns rain on & off -TGG

Hi From memory, the packets sent from the server to the client only update entity position and velocity, not on ground. Entity.moveEntity contains logic to set .onGround, but perhaps it is not called for client-side entities (I'm not sure). Basically, it tries to move you in the negative y direction, finds that there is a block in the way, clips your new y to the block position, and then compares how far you actually moved to how far the caller asked for; if they don't match, you're on the ground. Anyway you could probably copy the onGround logic from moveEntity and run it yourself before rendering. -TGG

Hi Depending on what you want to do, it might be fine to assume that the entity can see the player if (and only if) the player can see the entity. If you're not happy with that, check the vanilla EntitySenses and EntityLivingBase.canEntityBeSeen for inspiration... -TGG

Hi It looks to me like your backpack is rendering fine, it's just that it's using the vanilla renderer instead of your custom renderer. This probably means you haven't registered the renderer properly. MinecraftForgeClient.registerItemRenderer(Config.itemBackpackID, new RenderItemBackpack()); Is Config.itemBackpackID correct? Did you try our suggestion of putting a breakpoint or System.out.println in your RenderItemBackpack methods? -TGG

Hi. If you search this forum for "using missing texture" you'll find a heap of people with this problem. Generally boils down to * texture name not set properly, or * textures stored in the wrong folder, or * the upper/lower case don't match exactly. -TGG

Hi At a guess, you're probably counting both the pre ticks and the post ticks. ("Phase = start", "Phase = end") public static class WorldTickEvent extends TickEvent { public final World world; public WorldTickEvent(Side side, Phase phase, World world) { super(Type.WORLD, side, phase); this.world = world; } } from /** * Every tick just before world and other ticks occur */ public void onPreWorldTick(World world) { bus().post(new TickEvent.WorldTickEvent(Side.SERVER, Phase.START, world)); } and /** * Every tick just after world and other ticks occur */ public void onPostWorldTick(World world) { bus().post(new TickEvent.WorldTickEvent(Side.SERVER, Phase.END, world)); } -TGG

Hi I find the best way to figure out unknown parameters is to have a look what the callers of that method provide. So for example: Item.onUpdate called by ItemStack.updateAnimation called by InventoryPlayer.decrementAnimations this.mainInventory[i].updateAnimation(this.player.worldObj, this.player, i, this.currentItem == i); which gives you a pretty obvious indication of what the last two parameters are. -TGG

Hi I don't understand what you mean. You can store anything you like in a TileEntity. You write the NBT serialisation code yourself and can put whatever you need into it. TileEntities are specifically designed for exactly what it sounds like you're trying to do. Fair enough :-) Actually this is probably pretty easy since you only need to prevent spawning on the server, which is also the place you record your block placements. So the client doesn't need to know about your hash table at all. Just a comment - you are using the inbuilt Java hash tables, yeah? (HashMap, HashSet) Why haven't you been able to test it? (i.e. what's stopping you?) -TGG

Hi My Forge 1.7.2 version is a lot less obfuscated than yours so I can't see the functions causing the problem. My guess is that your Item (ItemBlock) hasn't been registered properly. I haven't done that in 1.7.2 yet so I'm stuck there. -TGG

Hi I agree with GotoLink. If you need a byte of storage per block, just define 16 new blocks which all inherit from the same base. 4 bits of metadata and 4 bits of block ID and you're there. Far more robust than trying to code up something yourself. Your idea sounds like it might work with a lot of effort; I think the "proper" way to do it would be to modify the chunk data storage to add an extra metadata array, and let vanilla handle the hard work of storing and reloading the chunk data. There was a bloke asking about this on the forum a couple of weeks ago and he seemed to be pretty far advanced, perhaps he'd have some gems of wisdom. Multiplayer becomes harder again because you have to synchronise the data stored on the server with the client. It can be done but requires a fair bit of effort. -TGG

Hi I really don't understand what you mean by that. IItemRenderer is designed for use with Items, and once the renderItem is called, you can render it any way you want. What do you mean that this code doesn't work? Do you see nothing at all, or do you see something but it is wrong? Have you tried inserting breakpoint or System.out.println into renderItem or backpacks.render to see if it's called? The problem might be what you're doing with (Entity)data[1] eg for equipped it's the entity holding the item, not the item itself (since there is no entity for the item itself when it's being held) /** * Called to render an item currently held in-hand by a living entity. If * rendering as a 3D block, the item will be rotated to a 45-degree angle. * To render a 2D texture with some thickness (like default items), see * net.minecraft.src.ItemRenderer. In either case, rendering should be done * in local coordinates from (0,0,0)-(1,1,1). * * Data parameters: * RenderBlocks render - The RenderBlocks instance * EntityLiving entity - The entity holding this item */ EQUIPPED, Some more info on IItemRenderer here, http://greyminecraftcoder.blogspot.com.au/p/list-of-topics.html see the Item Rendering sections -TGG

Hi You could look to see how these folks do it, assuming one of them is open source. http://www.minecraftdl.com/timber-mod/ http://www.minecraftdl.com/tree-capitator-mod/ http://www.skydaz.com/timber-mod-installer-for-minecraft-1-6-2/ http://www.skydaz.com/whole-tree-axe-for-minecraft-1-2-5/ It's obviously a pretty popular idea... -TGG

Hi This has some useful code http://www.minecraftforum.net/topic/1419836-131-forge-4x-events-howto/ Not sure how you would cancel the event, it doesn't seem to be cancelable like normal events, unless I'm missing something. You could perhaps use @ForgeSubscribe public void entityTarget(LivingSetAttackTargetEvent event) { if (event.target != null && event.target instanceof EntityPlayer) { event.entityLiving.setAttackTarget(null); } } Not sure if that will work since the call to setAttackTarget is reentrant, i.e. will trigger another LivingSetAttackTargetEvent. Also, setting target to null like this might perhaps cause a crash. And, probably, the mobs will just stand around doing nothing instead of ignoring the player. But it's worth a try :-) -TGG