coolAlias

I reckon your problem is that when you create the static array, all of the references are null. After initializing them later on, the array is not automatically updated, since it contains only null values and has no idea how to change what they point to. The best way to automate registration is via Reflection and, if your registrations are not all cookie-cutter look-alikes, probably with one or two interfaces. I have this in my mod's Items class, for example: private static void registerItems() { try { for (Field f: ZSSItems.class.getFields()) { if (Item.class.isAssignableFrom(f.getType())) { Item item = (Item) f.get(null); if (item != null) { ZSSItems.registerItemComparatorMapping(item); String name = item.getUnlocalizedName(); GameRegistry.registerItem(item, name.substring(name.lastIndexOf(".") + 1)); if (item instanceof ICustomDispenserBehavior) { BlockDispenser.dispenseBehaviorRegistry.putObject(item, ((ICustomDispenserBehavior) item).getNewDispenserBehavior()); } } } } } catch(Exception e) { ZSSMain.logger.warn("Caught exception while registering items: " + e.toString()); e.printStackTrace(); } } The above only makes use of one (custom) interface, but that should suffice as an example. There is similar code in the ClientProxy for renderers, as well as for my blocks, and those both involve a few more interfaces. As for automating creative tabs... what's the point? If you're worried about extra lines of code, then why not just inline the call to setCreativeTabs when you initialize your block/item?

You shouldn't need to notify the client, if that's what you're asking. I don't know if this is the source of your issue, but you are using an insane amplifier value for the move slowdown effect. Typically, you must remain within the specifications set out by each individual potion, most of which only accept amplifiers in the range of 0-2 and some up to 3. I don't know of any offhand that can go up to 4, let alone 70, and using values like that will certainly have the possibility of resulting in unintended consequences such as not working.

Can you not use FOVUpdateEvent for your particular purpose? That would be the ideal method of handling zoom.

I stored whatever IBlockState the block is supposed to render as as a field in the block's TileEntity, then fetch it in the ISmartBlockModel: @Override public IBakedModel handleBlockState(IBlockState state) { if (state instanceof IExtendedBlockState) { IBlockState renderState = ((IExtendedBlockState) state).getValue(YourBlock.RENDER_STATE_PROPERTY); // obviously you'll have to change this if (renderState != null) { IBakedModel renderModel = mc.getBlockRendererDispatcher().getBlockModelShapes().getModelForState(renderState); if (renderModel instanceof ISmartBlockModel) { renderModel = ((ISmartBlockModel) renderModel).handleBlockState(renderState); } return renderModel; } } return defaultModel; } It works for the 99% of cases, but obviously there will always be some that won't work. Personally, I just use it for solid, cube-shaped blocks.

Not unless you recreated every single Entity class there is, including for mods, which is obviously impossible. Otherwise, you will replace, say, EntityCow with your new entity class, and suddenly it is no longer a cow. You either have to modify the base Entity class that every other entity class extends from, or find a different way. Creating a new Entity class only works for new entities, not any that already have a class inheriting from the original Entity.

No, the way you are doing it is not possible. You can't just make a new Entity class and override stuff expecting it to affect other entity classes - that's not how inheritance works. If you change the actual Entity class itself, however, then yes, but that would require modifying the vanilla class. Another option would be to replace all web blocks with a custom web block that simply overrides #onEntityCollidedWithBlock to do nothing, as opposed to calling #setInWeb. Either of those 2 options will completely remove the effect from the game, however, for every entity. You could also try subscribing to LivingUpdateEvent and setting the entity's #isInWeb field to false, either via Reflection or a 'dirty' accessor class, but whether that works or not depends on the order in which the methods are called. If the Block method is called first, then the living update, and then, finally, current motion is modified, it will work, otherwise it won't. This option would allow you to control which entities can move freely in webs, if you wanted.

I'm pretty sure that's just the Eclipse test environment - unless you specify a username or full login, it gives you a semi-random username each time you launch the client, but it sounds like it uses the same player data file in the background regardless of user name. As I said, I haven't tested that, but your code looks like it should work fine. If you can, try running the test Server via Eclipse, then connect via both your computer and one other computer via LAN - each player should have their own IEEP data.

At this point I would check your Items, e.g. 'BaseClass.InrPwrHL' - have they been initialized and registered? Was that done BEFORE registering the renderer? Do they have textures? Did you override #getIconFromDamage to return anything other than the default icon? I mean, at the very least you should be getting the missing texture texture rendering... how are you spawning the entity?

That is not the correct way - static means only ONE instance of that variable exists for all instances of the class, so if one TileEntity changes the speed, EVERY TileEntity changes its speed. The correct way is to keep it as a regular class member or, and possibly better, change it to a function, e.g.: public int getCurrentFurnaceSpeed() { if ((blockMetadata & == 0) { return celestialSpeed; } else { return regularSpeed; } } Then you can call that from your Container / Gui classes when determining the progress bar status. The nice thing about using a method like the above is that the client also knows the current block metadata, so you don't need to worry about synchronizing your class field for the speed.

You can create a class extending WorldSavedData and add your information to that, though it sounds like you're creating new Item instances on the fly which is a big no-no (they need to be registered and all that during FML pre-init). How will players receive these items? In chests? Because if you are, you can create the items beforehand and then control how they generate, e.g. by making a List of possible items and removing one at random each time a chest generates until none remain, and save the remaining contents (or lack thereof) in your world saved data class. You may want to check out Draco's Artifacts mod (don't have the link atm) - it creates unique items using the ItemStack NBT and is really damn good at it.

There ya go! Nice work

I'm not sure why your entity isn't rendering, but I have to ask: if you are using an Item-based renderer for your Entity, why not just use the RenderSnowball class? At the very least, you should try using it to rule out errors in your custom Render class code.

It takes some time / practice to understand, but learning about how bits work is really fundamental to a lot of programming concepts (e.g. compression). Anyway, your meta value logic is all messed up // These 2 values should be identical, for one int direction = world.getBlockMetadata(x, y, z); int meta = tileentity.getBlockMetadata(); // Why only metadata == 11? Do you realize what that means? // Furnace meta values = 2, 3, 4, or 5 // Your bit toggle = furnace meta +0 (default texture) or +8 (celestial texture), so: // 2, 3, 4, 5 = default texture facing one of four directions // 10, 11, 12, 13 = celestial texture facing one of four directions if (meta == 11) { // so this is only celestial texture facing direction 3... direction |= 8; // and this does nothing, because bit 4 (value = is already set, so direction still = 11 meta = meta & 7; // what's this doing here? you don't even use this variable anywhere world.setBlockMetadataWithNotify(x, y, z, direction, 2); // so now you set the metadata to the same value it was, 11 } else { direction = meta; // probably already equal, as noted above world.setBlockMetadataWithNotify(x, y, z, direction, 2); // so this does nothing } Is that the only place you change the metadata? Because it doesn't look to me like you are changing anything...

Looks about right, so the problem is probably in your rendering class - post that. Also, you are using an outdated method of persisting IEEP - your 'magicPlayerData' map in the CommonProxy can be replaced by subscribing to the PlayerEvent.Clone and copying the IEEP data from the old player to the new.

Keep the original function, but put this: boolean useCelestialTexture = (meta & > 0; // true if bit 4 is set meta = (meta & 7); // remove bit 4 because it is throwing off all of your meta values // rest of getIcon function contents here, EXCEPT: ... blockIcon : this.front)); // change to: ... blockIcon : (useCelestialTexture ? this.celestial : this.front))); Or whatever the texture name is.

Did you fix the other issues with your proxy setup? Because that is surely affecting it as well. Once you've fixed it, post your latest code.

Yes, but that's what the OP said he was trying to do:

Please read the wiki on furnace metadata states. You can't use 2 or 4 - they are taken. The value 8, however, at bit location 4, is free, so you can use that as a flag similar to how buttons have an 'on/off' toggle. That's exactly what you are doing here. And yes, it goes in the update section, not when you place the block. When the block is placed, nothing is in it, so you don't care about setting the last bit, just leave it at the default 'unset' state.

Personally, I don't have a package named 'common', as everything not in the client package is, by default, common. Not that it makes any difference, really, but compare the 2 structures: main |_client |_other client packages and classes |_common |_ other packages and classes that both sides use Main.java, possibly some other stuff main |_client |_other client packages and classes |_ other packages and classes that both sides use Main.java, possibly some other stuff [code] In the end it's up to you, and as I said, it doesn't matter, but I don't see any benefit to having that particular package; many do, you may, too. Even the client package isn't really necessary, but it can be helpful, especially if you have lots of client-side classes or need that extra reminder that your code is only going to be on one side. Just do whatever makes sense for your project now, and change it later if it no longer fits - it's not the end of the world to restructure your packages. The only real advice I can give you is this: look at LOTS of other peoples' projects, both Minecraft- and non-Minecraft-related. Non only will that help give you ideas about package structures, but if you read the code you will also learn a lot about various design strategies - and those, I would argue, are much more important and will greatly influence the way your packages turn out. Plus, as you read others' code, you will see styles you like and styles you don't. Don't get bogged down in it, though - the most important thing you can do is simply start writing code. The more you write, the more you will learn. Sure, you'll make lots of mistakes. Everyone does. Whether / how you learn from them will determine your level of success.

If you're not familiar with bitwise operations or what things like AND, OR, XOR, etc. mean, then I suggest you look them up. It helps even more if you understand binary, as bitwise operations work on individual bits: 0 0 1 1 (4 bits, value = 3) 1 0 1 1 (toggled bit # 4 to on [ reading from right to left ], value now = 11) 0 0 1 1 (toggled bit # 4 again to off, value now = 3 again) The example above is pretty close to what you would write in actual code, except you would get the first metadata value from the World instance, e.g. world.getBlockMetadata(x, y, z) or whatever it is. Then, based on the state of your TE, you either add or subtract 8 (which is effectively what those 2 bitwise operations do) and set that as the new metadata. That's it.

Timers shouldn't be affected by meta-data, but you need to store the rotation data as well, which is why I suggested using bit number 4 (i.e. value=. Are you familiar with bitwise operators? e.g. int meta = 3; // some facing information, original texture meta |= 8; // add flag for your custom texture, keeping all original data; meta is now 11 meta = meta & 7; // removes everything but the first 3 bits (values 0-7), meta is now back to 3, the original rotation You need to do something like that when you set the metadata.

It is possible, just not with the KeyInputEvent - make a public static reference to your KeyBinding somewhere, and then override the #keyTyped method in your GUI class: @Override protected void keyTyped(char c, int keyCode) { super.keyTyped(c, keyCode); if (keyCode == KeyBindings.yourKey.getKeyCode()) { mc.thePlayer.closeScreen(); } }

Almost that simple, yes - you just need to call the setBlockMetadataWithNotify method using your TE's worldObj. Make sure to set it back when there is not a valid celestial recipe being smelted.

In the methods that check the current smelting recipe, you can alter the furnace's smelting time requirement based on the recipe, e.g. in #getCelestialSmelt, before returning 'true' set the furnace speed to 120 or however long you want it to take. Be sure to set it back for regular recipes. As for having a different texture, in the same methods as above, you could change the block's metadata (bit 4 should be available, unless you used that for active vs. inactive) and then return the face texture based on that flag.

You are correct - the client side entity does not exist when the server side reads from NBT, but there are 2 possible solutions: 1. Send the packet from EntityJoinWorldEvent instead of from the readFromNbt method 2. OR, and this is much better, implement IEntityAdditionalSpawnData and send the entity's size with the spawn packet; this data is sent every time the entity's spawn packet is sent to the client