coolAlias

Too old to be a Jedi, mmm? Update you shall I might just have to try my crazy abstractification attempt again.

To avoid further block updates like shadowmage4513 mentioned (e.g. for redstone), my solution was to use flag '2' when setting all my blocks, as this flag notifies the client without updating neighbors. For doors, if I remember correctly, the top half has the same metadata value as the bottom half plus 8. The Minecraft wiki "Data Values" section will have more precise information on metadata values for all the blocks, so I would double-check there.

Interesting, I got the same exception while trying to make an abstract version of a Message and was told it's because Netty doesn't like abstractions, but you're getting the same thing with a straight implementation :\ Sorry I don't know the answer, but this makes me wonder if the IMessage system is still somewhat broken? When Forge 1.7.2 first came out, it was totally broken, which is why various other network solutions came out (which apparently have memory leaks), but now it still seems to be a bit funky. I guess we just don't know how to use it... Btw, I like what you did with your PacketHandler for methods and the discriminator - I did pretty much the exact same thing

Hi TGG, Thanks for the welcome I was pretty busy moving and starting a new job, so didn't have much time for modding. I'm pretty sure that the IMessageHandler#onMessage method is the final method called in the chain, so it will be either on the client or the server depending on which direction the packet was sent. Granted, I have only just started messing around with this whole message system (since apparently the first Netty tutorial has a memory leak, though no one has bothered to explain where and why), so I could be wrong, but I assume that when MessageContext.side == CLIENT, that I am actually on the client side so Minecraft.getMinecraft() shouldn't be a problem; otherwise, how could anyone do any client-side processing of their packets? :\ Re: registering of message handlers, I don't think you need to worry about partitioning those into the proxy classes; the registration process looks to me like it should work by registering during the FML initialization events without worrying about Side at all, except for as an argument to pass to the method. As far as I understand, IMessageHandler should be implemented by each packet (message), not as a generic catch-all handler like some people used in 1.6 and earlier. All that being said, I've only played with this message stuff for about 2 hours so far, so take all of the above with a grain of salt Cheers, coolAlias

Hi, I faced this problem before, and it has two facets: the first, jabelar already explained, the other is that you must make sure that there is a block to which the torch or door can attach, or it will 'break' and fall as an item. In my case, I solved it by generating the structure in two steps, one to place all regular 'solid' blocks, and a second pass to place things like torches, paintings, and other things that might rely on the structure already being in place. You could think of it as 'building' and 'decorating' Cheers, coolAlias

You need to send a packet to all nearby clients (players) and spawn the particles there, too; spawning particles on the server doesn't do anything (which is sort of strange... you'd expect that, similar to sounds, it would automatically broadcast to all nearby clients, but it doesn't).

It's because those mobs don't use AI; LivingSetAttackTarget only works with AI, and not necessarily all AI-enabled mobs -> for example, if a mod is using a modified version or completely custom AI, it may or may not obey the rules.

Yeah, I understand - I just think it would be even more magical to have the EntityPlayer passed directly to the IMessageHandler#onMessage method (which is also a basic programming practice - passing variables that will likely be needed), but if for whatever reason that's not possible, it's not exactly difficult to create a local reference to a field. It's just irksome At any rate, I was just curious if there was a way restructure it for myself using generics, both because it's an interesting exercise in Java and the result would appease my urge to economize the amount of typing I must do and the number of lines in my code. Most certainly not necessary, but an adventure in personal preference, if you will. Certainly you've restructured things to suit your personal tastes, before, no?

Use world.scheduleBlockUpdate(x, y, z, block, block.tickRate(world)) to immediately schedule an update tick; you may also want to notify neighboring blocks of the change. It's what most redstone blocks use to constantly tick, and I've used it to force tick updates on blocks when I want (for instance activating switches with a boomerang).

I guess I need to update my Forge version then (1060 still... yeah, I know >.<); all I have is ctx.getClientHandler(), which doesn't even have a player field, and ctx.getServerHandler(); no generic version exists unless you count ctx.netHandler, but that also doesn't have a player. Well, that will be one annoyance out of the way, sort of; I'd still prefer to just have the player as a parameter, but maybe that's just me. Thanks for the reply, though.

The WeaponAttributes that you 'recovered' probably has a whole ton of code implementing the actual mechanics to get those things to work. Do you know how to use the various Forge Events yet? Those will go a long way in allowing custom mechanics to work in general for all mobs and players, rather than being limited to just your custom ones. Fire is easy: override Item#hitEntity(ItemStack stack, EntityLivingBase target, EntityLivingBase attacker) and use target.setFire(time). Attack speed could be done in either of the following ways (and probably others that I haven't thought of): 1. Specifically, as in you implement it in each of your custom Item classes as a timer/cooldown (stored in the ItemStack NBT) and simply prevent the item from being used or swung, but not affecting the player/mob if they switch to a different item, OR 2. Generically, using events such as LivingAttackEvent and EntityLivingBase.attackTime or your own custom timer via IExtendedEntityProperties, in which case you can choose whether the timer affects only the specific Item used, or if no attacks can be made until the timer runs out Knockback could be trickier, but you might try LivingHurtEvent and see if you can add velocity in the opposite direction (probably super buggy) or, probably a much better solution, grant the mob a temporary knockback resistance bonus (it's a SharedMonsterAttribute) when struck with your item (using Item#hitEntity from above and then LivingUpdateEvent or a tick event with a Map of affected mobs so you can remove the bonus in a timely fashion).

SOLUTION: Update Forge to 1121 or later; on 1060, the IMessage system is apparently still broken, as the following generic class worked perfectly as soon as I updated! Though some may view it as pointless, I think it's pretty f-ing sweet. Now if only I could change the names of fromBytes and toBytes to include 'read' and 'write'.... Original post: Hey all, So, I decided to attempt to make an abstract class implementing IMessageHandler to do some of the monotonous work for me, like so: While the code seems like it should work and compiles fine, netty/FML can't seem to figure out what to do with it: I know it's not really necessary, but I find it quite tedious (and messy-looking) having to write out "ctx.getServerHandler().playerEntity" every time I want to get the player, as well as recall which side I'm supposed to be on so that I get the correct player (yeah, it's not that hard, but I prefer it to be REALLY obvious). Making the abstract class do that work for me would just be sweet Does anyone have any idea how (or if it's even possible) to get this working? Much obliged, coolAlias

I wouldn't recommend that as a blanket statement, it really depends on what your event handler is supposed to do. Most of my events are all normal priority and don't receive canceled; some are set to LOWEST priority so they are called last in the line, because I want to make sure every other mod gets to modify that event first, for example, and perhaps don't even want to handle it if another mod cancels it; I only use HIGHEST if the event should be handled first, but if everyone set theirs to HIGHEST, it would break this unspoken 'contract', and thus potentially break / interfere with various mods. For the majority of events, you will want NORMAL priority and don't need to receive canceled, in my opinion, unless you have specific reasons for doing otherwise.

Looks like this issue was fixed with the latest version of Forge - probably thanks to you pointing it out

You need to add the dependencies to your build.gradle file: dependencies { compile files ( "lib/pircbot-1.5.0.jar" ) }

You don't need to send packets for switching tabs or doing anything that changes what is presented on the screen; you DO need to send packets any time you want to change something on the server from the client, which usually includes things like changing what ItemStacks are in an inventory, but if you set up your inventory properly with a Container, then the Container will do all that work for you and you don't need any packets for that. For item duplication, it seems like you are not differentiating correctly between your tabs, as in each tab is referencing the same set of slots in your Container. I suggest you look more closely at the GuiContainerCreative class as an example of a similar system.

No guys, it's much simpler; the OP is creating a custom entity, so simply override the Entity#fall method to do nothing. @Override protected void fall(float distance) {} This is how vanilla mobs such as the chicken take no fall damage.

I've also been using the network code from that Netty tutorial and haven't noticed any problems. Looking at cpw's SimpleNetworkHandler, it seems easy enough to use, but honestly, I prefer the tutorial code, since I can create a packet that I can send to either side, whereas cpw's you have to provide the Side when you register the packet, as well as manually enter the discriminator bytes. I also prefer how each packet is its own handler, vs. cpw's system of registering a handler with a packet. There doesn't seem to be an easy way to get the player after receiving a packet on the server, either, but I probably just missed that. Anyway, my overall impression of cpw's code is that it is more complicated and cumbersome than it needs to be, at least in comparison to what I have been using. Surely whatever memory leak there is in the tutorial code wouldn't be hard to fix? EDIT: After seeing EE3's setup, I guess cpw's system is more straightforward than I had gathered from the documentation. Though Pahimar didn't use one, it's easy enough to use a self-iterating index during registration, but still, it would have been nice to have the discriminator self-indexing built in, like with the outdated tutorial code. I also still dislike how the packet needs to be registered with a Side; sure most packets are only sent one way, but sometimes I need one that is sent in either direction.

Add the blocks to a List, then it's just one single if statement in your event to check if whatever block is being broken is breakable. Much better than tons of chained else-ifs, though you still need to initialize the list by putting all the allowed blocks you want in there. However, why do you need to make a list when there is already the 'isToolEffective' method? Surely that's enough for your needs, as you are only trying to restrict players from breaking blocks with fists, clumps of dirt, etc., right? EDIT: I saw your code in another of your posts; you don't need to setCanceled(false), because the default behavior is to not be canceled. Besides, I'm pretty sure all of those blocks you checked for don't need a tool to break anyway, so isToolEffective will return true, and the event will not cancel, allowing the block to be broken by hand.

Basically what that means is you can't use the isToolEffective method when the player is not holding anything, because it expects an ItemStack, not a null pointer; so, if the player is not holding anything, or the currently held item is not effective against the current block, then cancel the event. Translating the above statement into pseudocode: if (currentItem == null || isToolEffective(currentItem, etc.)) { cancelEvent; }

Looks like you didn't read far enough down: Caused by: java.lang.NullPointerException at coalpower.core.CPTab.<init>(CPTab.java:33) ~[CPTab.class:?] at coalpower.core.CPTab.<clinit>(CPTab.java:27) ... 40 more That's a lot of null pointers in your CPTab class... mind showing us that code?

Easy way: 1. Create custom egg Item with subtypes for all your entities. 2. Create custom tab. 3. Add custom spawn eggs to that custom tab. Forget about using the vanilla spawn eggs - the EntityList system was apparently never intended to accommodate modded entities, which is a real shame, imo, and should be fixed so we can use the vanilla eggs, summon command, etc. Of course, you can still use it if you really want, in which case you need to get the IDs, and if you have been modding for two years, I find it hard to believe that you don't already know how to get your custom global entity IDs from the EntityList (which is actually a bunch of Maps).

Those are the same entity; use the DamageSource provided to get the entity that caused the damage, if any. DamageSource#getSourceOfDamage() returns the entity directly responsible for the damage (e.g. the EntityArrow for an arrow, a mob that physically struck the player, etc.), whereas DamageSource#getEntity() returns the entity that is ultimately responsible for the damage (e.g. the player that shot the arrow). Sometimes both methods return the same entity (e.g. EntityDamageSource), sometimes they return null (e.g. fall damage has no entity), and sometimes the rules may be completely different (e.g. a mod with custom damage sources that was poorly designed to not follow the standard).

Pretty much what you would expect from the name - any time any EntityLivingBase suffers any amount of damage.

SoundHandlers are a thing of the past - they used to be used because sounds needed to be added to the sound pool during startup, but no longer. The SoundLoadedEvent really doesn't have a use anymore, as far as I can tell. Personally, however, I still create a "Sounds" class filled with public static Strings for my sound file names, for ease of reference. Looks a bit like this: public class Sounds { // BLOCK SOUNDS public static final String BREAK_JAR = ModInfo.ID + ":ceramic"; public static final String HIT_PEG = ModInfo.ID + ":hit_peg"; // etc.