imadnsn

Understand what the error says, getSubItems is not being recognized, make sure you're extending the correct Item class, it might be a reference issue.

He wants to get notified of health changes client-side. I don't know if there is a way to get notified from the DataWatcher without coremods, I've never used it. I'm sure things other than health would need some vanilla packet handling which I'm not aware of whether it is possible or not. And the fact that SP uses a server doesn't make "logically" client-only mods in need to interact with it, it is client-side only...

If you want to use a texture that is not 256x256, you should use this method instead of drawTexturedModalRect, which I grabbed from somebody else in this thread: /** * Draws textured rectangles of sizes other than 256x256 * @param x The x value of the top-left corner point on the screen where drawing to starts * @param y The y value of the top-left corner point on the screen where drawing to starts * @param u The u (x) value of top-left corner point of the texture to start drawing from * @param v The v (y) value of top-left corner point of the texture to start drawing from * @param width The width of the rectangle to draw on screen * @param height The height of the rectangle to draw on screen * @param textureWidth The width of the whole texture * @param textureHeight The height of the whole texture */ protected void drawNonStandardTexturedRect(int x, int y, int u, int v, int width, int height, int textureWidth, int textureHeight) { double f = 1F / (double)textureWidth; double f1 = 1F / (double)textureHeight; Tessellator tessellator = Tessellator.instance; tessellator.startDrawingQuads(); tessellator.addVertexWithUV(x, y + height, 0, u * f, (v + height) * f1); tessellator.addVertexWithUV(x + width, y + height, 0, (u + width) * f, (v + height) * f1); tessellator.addVertexWithUV(x + width, y, 0, (u + width) * f, v * f1); tessellator.addVertexWithUV(x, y, 0, u * f, v * f1); tessellator.draw(); } Also, you should use either Post or Pre of RenderGameOverlayEvent or else it will draw twice a frame (this will be noticed if the overlay was rendered with transparency)

A new topic wasn't needed, but what are you trying to do? You originally wanted to know whether onLivingHurt event would work on Multiplayer, it will if you use it correctly, what do you want to do? If you're only altering player's health amount, you can do it easily by changing player's health server-side, as Minecraft uses DataWatcher for updating entities' health to client, which is not the same as the ordinary way using packets.

How do you register the class where this method is in? You might be doing it only in your client proxy. As AFAIK this event is only called on (logical) server side.

Optimization is never bad, but it shouldn't be done too much. TheGreyGhost tips are actually useful. In Minecraft, optimization wouldn't make much difference except in some cases: 1- You're doing it stupidly, such as calling code everywhere unnecessary. 2- You're doing something big, which is very rarely the case. 3- The user is using over 150 mods, which is not your problem. Answering your question, there is no this-or-that simple answer, it depends on a lot of things that neither is more important than the other, this means you shouldn't worry except if it lags when testing or if it is too obvious. Optimization should be the last thing to do, it is time-consuming and some things might get deprecated overtime, in which case all the time used in optimizing them gets wasted.

Why would you use NBT and PlayerInteractEvent? Why not casting world.getTileEntity to your TileEntity in the block's overridden onBlockActivated method and use your tile entity's public fields and methods that give you a list of players who already used the block? Also, you can get the player's UUID from player.getGameProfile().getId().toString().

:D LOL I feel stupid now, very stupid :D turned out that I set onDead() without !worldObj.isRemote check

Strangely enough, it gets called perfectly when spawned client-side. It means everything is registered correctly, just that the server is not notifying the clients. Also I now noticed that onUpdate is called only once, since anything printed there is printed once even if it is called in both sides.

The Entity spawns correctly, and goes where it should go (I made it print where it is every update), could it be because it is server-side only? Entity spawn code: EntityElementCharge charge = new EntityElementCharge(player.worldObj, player, 5, 5); // server-sided only player.worldObj.spawnEntityInWorld(charge); Common Proxy (nothing is done here): public class CommonProxy { public void preInit() { } public void init() { } } Client Proxy: public class ClientProxy extends CommonProxy { @Override public void preInit() { RenderingRegistry.registerBlockHandler(new TestRenderer()); } @Override public void init() { FMLCommonHandler.instance().bus().register(new KeyInputHandler()); RenderingRegistry.registerEntityRenderingHandler(EntityElementCharge.class, new RenderElementCharge()); Initialization.registerKeyBindings(); } } Proxy's declaration and base mod's init-preinit: @SidedProxy(clientSide="insnmods.client.ClientProxy", serverSide="insnmods.common.CommonProxy") public static CommonProxy proxy; @EventHandler public void preInit(FMLPreInitializationEvent event){ //... registering blocks and items ... EntityRegistry.registerModEntity(EntityElementCharge.class, EntityNames.ENTITY_ELEMENT_CHARGE, eid++, Magematica.instance, 75, 3, true); proxy.preInit(); } @EventHandler public void init(FMLInitializationEvent event){ //... registering crafting recipes ... proxy.init(); }

I have an entity extending EntityThrowable, I made a special renderer for it and I can't seem to let it work, the doRender method doesn't even get called. I should mention that I didn't call super.onUpdate(), but I rather copied the code in it (and called onEntityUpdate which is called in the Entity class), because I wanted to change some things in the original update call. Here's my EntityThrowable class: Here's the renderer class (nothing fancy, just testing): Registering code:

I was going to add something like "when it can't" after "doesn't consume it" but I forgot

Some blocks have different multiple drops, and some have different dropped metadata, so block.getDrops is better.

That actually was perfect, it makes every sense. So basically, one should return a boolean in the first method to whether the block can use bonemeal but doesn't consume it. However, if he wants it to consume bonemeal anyway but grow the block by chance he should return true or false in the second method. It makes a lot of sense now, I'm sure Mojang did this code in 1.5 in the huge bonemeal nerf after they wanted their saplings to grow by chance because it was too OP when it grew fully every time.

The way I've done it is the same as the way BuildCraft has done it. You first get drops by calling block.getDrops(), then you get drop chance by calling ForgeEventFactory.fireBlockHarvesting() which is the same fired by forge when a block breaks and is being harvested. Then at last you make another empty list and iterate over the drops list and if a random generated number (every time) is less than the chance you add the drop to your other list. After you get the drops, iterate over them and spawn each by using world.spawnEntityInWorld().

Exactly, it does it for EntityFXs too. It doesn't call them for IItemRenderers because rendering custom items is totally made by forge, so it is not in vanilla Minecraft code, and apparently, forge doesn't call startDrawingQuads() and draw() when calling IItemRenderers's rendering methods.

You may be able to do it for EnderIO conduits if you use tile entities' NBT, you'll have to do an if statement for every case but it might work. See EnderIO code to see how it stores it, or simply use an NBT explorer to see how EnderIO does the conduits in a world.

you don't have to startDrawingQuads or draw, Minecraft code already does this when calling your method to render the block. It gives you already Tessellating when you put startDrawingQuads because Minecraft calls it before calling your method, and it says not tessellating after you remove it because Minecraft tries to call draw after calling your method, but you already have called it.

I've heard the limit is 32kB or 64kB, A lot can be sent by such limit, and it would be perfect if time didn't matter. TheGreyGhost told me here once that Minecraft sends 5kB (at most) data of chunk updates to clients per tick.

If it is a custom block, in the block class, override onBlockPlacedBy, it has EntityLivingBase argument, check if instance of EntityPlayer, cast it to EntityPlayer and then do getDisplayName(). If it is a vanilla block it is more complicated, I'm not sure how its done but I suggest looking at PlayerItemUseEvent.Tick.

If you want AI behavior like vanilla, look at vanilla mobs. Probably what you want is EntityAISwimming, which is what pretty much every swimming mob using, e.g. zombies and skeletons. If you want similar but not exact behavior, it is easy concept, the way Minecraft handles swimming is by entity's jump, if entity is under water and it jumps, it goes up. This way all you have to do is to use entity.getJumpHelper().setJumping() and it will go up on water and when it hits the surface, it will start going up and back to water just like how skeletons and zombies do.

You need custom AI for that. Extend EntityAIBase and override it methods. EntityAIFollowOwner and EntityAIMate have somewhat close functionality to what you want, look at them. All what you have to do next is adding your custom AI in you entity's tasks in the constructor and return true in your entity's isAIEnabled overridden method (see vanilla mobs to know how exactly).

getUniqueID is per session or per world (not sure what exactly), it is for every entity and isn't actually UUID. I believe it gets reset after respawn (also not sure). what you want is getGameProfile().getId().toString() (UUID is a class)

How and what are you trying to do?

No, you need it in client, but the operations on it must only happen on server, then the server should synchronize the data with the clients so they would know what is the data on the server. the reason your code gave 12 messages is because onItemRightClick is called on both the server and the client, you have to check whether you're on the server or the client to get 6 messages from server only. You mainly know whether you're on server or not by world.IsRemote (if you have a World instance) which is false when on server. You need to know more about clients and servers and what happens in them, you also need to know about client-server communications mainly using packets. There are pretty much a lot of articles and tutorials out there. coolAlias have a pretty good IExtendedEntityProperties tutorial which I found quite similar to WorldSavedData in concept, check it out.