coolAlias

Hate to ask the obvious, but does your 'MyMessage' class implement the correct 'IMessage'? Btw, did you get what you needed from here? Seems like you may not have seen it.

I'm pretty sure the entity passed in does not take any damage from the explosion, as it is the one that 'caused' it, and since you're passing the player, well there you go You'd have to look at the Explosion class to make sure, though, but that's how I remember it working.

Here's what I've gathered from my modding experience - anyone feel free to add on to or correct me on any of this. IEEP gives you certain advantages: - Automatically calls its saveNBTData method every time the player data is being saved - Automatically calls its loadNBTData method whenever the player data loads - The class you make for it is a handy place to store your data for use between save and load cycles Now, you could certainly do some work to get similar results with getEntityData, such as nesting it in a class with some functions and storing your variables, but since you have no hook for the player save, you will have to write to this compound every time one of your variables changes value. I do use getEntityData occasionally, but only for sort of 'one-time' things, like marking a vanilla entity as 'already spawned' if I'm doing something like having it spawn in with a buddy or whatever. Anything that I actually want to access during the game, I use IEEP.

The last parameter should be 'true' to destroy blocks. Also, make sure you create the explosion only on the server side, i.e. when the world is NOT remote, otherwise you will end up with 'ghost' blocks of various sorts.

If you can, play the sound on the server directly via worldObj.playSoundAtEntity or worldObj.playSoundEffect (both of which will automatically play the sound for nearby clients, though I haven't looked into the exact mechanics going on under the hood); otherwise, you need to send your sound in a packet to the server and from there re-broadcast the packet to nearby players.

Thanks - I'll tinker around with it when I get some time. Pretty neat-looking mod, btw - that clay soldier looks like a fun opponent

@jabelar That's just the thing - I have never seen anywhere someone point to what, exactly, is causing the memory leak in the pipeline code; not to say that there isn't one, but if no one can point it out, then... Many people are writing their own implementations, but without the amount of scrutiny that went in to discovering(?) the pipeline leak, who's to say that those implementations do not also have memory leaks? If there is a leak, it must not be very severe, as I've sent many many packets over the course of several hours without any adverse effects, but I am certainly no expert in the matter. I can't help but feel like the pipeline code has been wrongly maligned... At any rate, I'm looking forward to Lex's rewrite, if that's indeed what he is rewriting - we could certainly use a stable 'Forge-team-certified' network code.

You shouldn't have a constructor for your main class - you should be using FML events only: // No: public IronManMain() { // this is a class constructor, which you don't want in this case } // Yes: @EventHandler public void preInit(FMLPreInitializationEvent event) { // Config and most other things should happen in the PreInit event // you can put all your code here, basically } Also, you don't need IDs for your items anymore, and you should be declaring your Items and such separately from the initialization of such: // No: public static Item ironmanMk1Helmet = new IronManMk1(IronManMk1Mat, ironmanMk1helmID, 0).setUnlocalizedName("IronManMk1Helmet"); // Yes: public static Item ironmanMk1Helmet; // declare @EventHandler public void preInit(FMLPreInitializationEvent event) { ironmanMk1Helmet = new IronManMk1(IronManMk1Mat, 0).setUnlocalizedName("IronManMk1Helmet"); // initialize, also removed ID argument }

@SanAndreasP Tried giving them the same discriminator, but it had the same result; oddly, one of the packets I send gets sent fine to the client but fails to play sound, and the other gets sent to the server and works, but can't be sent to the client for some reason. Anyway, I think I've just about had it with SNW - it seems every step of the way I run into something that just doesn't work the way I think it should. While the implementation from the wiki may indeed have a memory leak, it has never caused any problems that I can see and has always worked flawlessly for everything I need it to do, so I may just stick with that one until something better comes along. Maybe if I get enough time, I'll poke around and see if I can fix whatever is causing the memory leak Thanks for the reply (you too, Kwibble).

Hello again, While updating one of my mods, I noticed that IMessage/Handlers with SimpleNetworkWrapper don't seem to allow for the possibility that one may need to send the same packet to both sides (at different times, not simultaneously). I tried something like this: instance.registerMessage(handlerClass, messageClass, 1, Side.CLIENT); instance.registerMessage(handlerClass, messageClass, 2, Side.SERVER); but the packet seemed to only work for one side while in the game. Obviously I can copy the class and make one for each side, but they both require exactly the same fields / data (and some are even handled identically), so I'd rather not do that if possible. Is it even possible to do something like this with SimpleNetworkWrapper, or do I need to write my own network implementation? Cheers, coolAlias

First, forget about all that try/catch and the DataIn/OutputStreams - that whole paradigm is not really used anymore. Please search for updated packet tutorials like I mentioned earlier. EDIT: Just to be clear, I don't mean that try/catch is no longer used at all, I mean specifically in this context it is not needed anymore. For this particular case, you don't even need custom packets; use S35PacketUpdateTileEntity, which needs an NBTTagCompound - easy way is to just call your te's writeToNBT method and send that, but it's better to only send the data you need (i.e. write whatever you need to an NBTTagCompound, which you then send).

Any event posted to the bus will be seen by all mods, should they listen for it; are you sure you registered your event listener properly in the second mod? How do you know the 2nd mod doesn't receive the event?

If that is for a TileEntity, then use the getDescriptionPacket method instead, and onDataPacket for receiving the packet; otherwise, I suggest you search around here for tutorials on SimpleNetworkWrapper or look at other implementations of Packet systems that you could adapt to your needs.

There is a method in the Block class: setBlockBoundsBasedOnState(IBlockAccess world, int x, int y, int z) Use the world and x/y/z parameters to get the block metadata, and set the block bounds accordingly.

Ah, I thought you meant 'like vanilla mobs', not 'for vanilla mobs'. Here is a tutorial on events, and more can easily be found by searching Google or YouTube.

Did you look in EntityZombie at all? You should be able to find the method 'protected void dropRareDrop(int par1)' - use that same method in your custom entity.

I've found you can use KeyBinding#getIsKeyPressed() to reliably check if a key is still held down. isPressed() actually does not do what you think: it checks the press TIME, decrements it, and returns true if it is still greater than zero, whereas getIsKeyPressed simply checks whether the 'pressed' field is true or false.

The problem is that to check if space is held, you must be on the client side, but to affect the fall distance, you must be on the server side, so your checks are incompatible. Two solutions: a) Set your item in use via right click and check if the player is using the item before setting fall distance b) Check each tick if space bar is still pressed and send a packet when it is first pressed, to set the item in use or something, and then another when it is released; this will give the server the information it needs in your item's onUpdate method.

And again, diesieben07 saves the day! Seriously man, you're like a super-hero the way you deliver solutions to everyone's modding troubles. Major kudos to you yet again.

I store when my custom keys are pressed, and loop through that each tick to see if they are unpressed, rather than all the keys. The best way I've found is still using the custom objects, so when I press my 'special attack' key, it activates an instance of special attack or whatever, and that object is then updated each tick (charging up or whatever) and checks as it updates if the custom key is still pressed or not; this way, I'm only checking keys that I know were pressed. You could do the same with a dynamic list of currently pressed keys, or if you made an array for your keybindings it would probably be more economic to simply run through it each tick instead of adding and removing entries to a list, depending on how many keys you have.

The event is only for rendering the health bar - canceling it and drawing your own will only change how it LOOKS, not change the underlying game mechanics for health.

There's not much that can be done that I know of; for my own mod, I took the following approach: 1. Rethink my implementations to do the work when the key is pressed instead of released 2. For those that absolutely must use keyUp type functionality, attempt to encase it in a custom object that can be updated each tick when necessary, but also removed when no longer needed so as not to waste time every tick. Example: a skill that activates when key is released -> create a skill class, instantiate the object during key input event for that key and, now that the object exists, it updates each tick checking if the key is still pressed; as soon as it isn't, the skill does its thing and removes itself as needed. 3. Failing all the above, use a solution such as that in the topic you mentioned. Sorry that may not be very helpful, but those are the only things I was able to come up with to attempt to replace the sadly extinct keyUp method. I hope we see it make a come-back some day.

TickEvent and LivingAttackEvent are not on the same event bus... register to MinecraftForge.EVENT_BUS.

Minecraft.getMinecraft().thePlayer is the client side player; use the entity from the event and cast to EntityPlayer: if (event.entity instanceof EntityPlayer) { EntityPlayer player = (EntityPlayer) event.entity; }

The zoom effect is handled from EntityPlayerSP, and you can modify it using FOVUpdateEvent.