coolAlias

<sigh> I have run this code many times just fine, but I doubt you will take my word for it. It's disappointing that you persist in your obstinance rather than either a) showing why I'm wrong, or b) admitting that you are wrong and gracefully accepting it and perhaps learning from it, as I will do if you demonstrate a fault in my code. There is nothing wrong with being wrong except for continuing to be wrong when you know or should know otherwise. Err, I wouldn't say that, but thanks There are plenty of things about Java that I have no clue about, but I get by with what I know.

Sure, but would you mind using the MCF forums to PM me? I find the interface easier to use.

Your remark indicates your lack of java knowledge. Please learn java and then correct people. Why can't you just admit when you are wrong? Look: for (int i = 0; i < 4; ++i) { ItemStack stack = new ItemStack(someItem); // stack is declared and instantiated as a new reference each iteration, it is NOT the same reference // and this code will work fine LanguageRegistry.addName(stack, "some name"); } Yes, that is exactly the same as what you suggested but with two lines instead of one, which is exactly what the OP is already doing. If you are so awesome at Java, then please, explain to me how that is wrong. I'm just a hobbyist, after all, whereas you are a self-proclaimed Java and C++ developer; enlighten me.

Yeah, sorry, as sequituri pointed out, what you stated there is a terrible idea, which I failed to mention in my post. Glad that's all cleared up.

Sorry... but he is already creating a new instance of the ItemStack in each iteration of the loop, that is not the answer (it would be if he wasn't). @OP: Can you post your Block or Item code? I'm guessing your issue is you forgot to designate an ItemBlockWithMetadata or return appropriately distinct unlocalized names for each stack. Check here for an example of a block with subtypes. Using that your language registry will work just fine as it is.

Exactly the same way. DamageSource#getEntity() returns the direct source of the damage, which may be an arrow or even null (in the case of fire, for example); DamageSource#getSourceOfDamage() returns the ultimate source of the damage, so if an EntityPlayer shot an arrow, the first method returns the arrow, the second the player. If you want to be sure that the source of the damage is a player, use the latter method only: if (event.source.getSourceOfDamage() instanceof EntityPlayer) { EntityPlayer p = (EntityPlayer) event.source.getSourceOfDamage(); if (p.getHeldItem() != null && p.getHeldItem.getItem() instanceof ItemSword) { // do whatever } }

Also, you can't do this: p.getHeldItem().getItem() // CRASH if player's held item is null

I'm saying that you can't do this: EntityPlayer p = (EntityPlayer) event.source.getEntity(); if (p.someMethod()) { // CRASH because event.source.getEntity() might not be a palyer Welcome to the forums, btw - I've seen you around on MCF.

That has nothing to do with the topic, he is trying to use a method in EntityLiving, not EntityLivingBase, so he needs to check if the entity in question is an instanceof EntityLiving before casting. Stop confusing people with random comments. I don't find your attitude helpful. Perhaps you could keep your snide comments out of the fora. How is clarifying a statement that confuses the issue at hand being snide or unhelpful? I've seen you give people some excellent advice on challenging questions in other threads, but there have been several cases where you've been either plain wrong or providing extraneous information that diverts from the main point; in the latter cases, I feel it is indeed helpful to point it out and provide either clarification or correction as needed. When I say "stop confusing people with random statements", I'm referring to the latter; for the former, it is helpful to fact-check before posting replies to make sure the information you provide is accurate. If you consider that snide, well, that's your call.

Your EntityPlayers are not the same: 1. (EntityPlayer) event.source.getEntity() 2. (EntityPlayer) event.source.getSourceOfDamage() You never check if the first one is really an EntityPlayer, yet you try to use it as one right away in your if statement.

First, do all of your tools really need to be in different classes of their own, or could they share a single class? If they can't share a class for whatever reason, could they not share a prior class that implements all the NBT functionality for you, similar to how ItemAxe, ItemShovel, etc. all extend ItemTool, make your own "ItemCustomTool" that all of your other tools extend. Done, with those 20+ lines written only once but working for every single tool. That's a far cry from what I would call complex, but to each their own.

Forge gradle / Minecraft don't seem to get along all the time; when I've had similar exceptions, I was able to get it working by running the gradle commands with "--refresh-dependencies", for example "gradlew --refresh-dependencies eclipse" will refresh all of the class paths etc. If you run through setting up the workspace with refresh dependencies on all the commands and it still doesn't work, maybe try updating to a later version of Forge as sometimes it gets broken.

1. You don't need to send a synchronization packet to the server when loading your properties - they just loaded on the server. 2. You are using DataWatcher for your variables, so you don't need to send a packet at all - that's done automatically when you update the value, ON THE SERVER SIDE. Send a packet from your GUI to the server, rather than trying to set the data from the GUI: switch (button.id) { case 0: // BIG NOOOOOO!!! This is on the client! Send a packet with the information you need and set the data there ItemTalisman.pantheon = PantheonReference.NO_RELIGION; ExtendedPlayer.get(player).setPantheon(PantheonReference.pantheons[PantheonReference.NO_RELIGION]); // etc. // Should be: yourDispatcher.sendToServer(new UpdateReligion(newReligion)); // and in your UpdateReligion packet, in the handle server side method, you would then do // what you were doing in your GUI: handleServerSide(args) { // <- obviously don't copy that ExtendedPlayer.get(player).setPantheon(packet.religion); } So your GUI code would look like this: public void actionPerformed(GuiButton button) { YourReligionObject newReligion = PantheonReference.NO_RELIGION; switch (button.id) { // don't need case 0 anymore, that's the default case 1: newReligion = PantheonReference.GREEK; break; case 2: newReligion = PantheonReference.NORSE; break; . . . etc. } PantheonCraft.packetPipeline.sendToServer(new UpdateReligionPacket(newReligion)); } UpdateReligionPacket writes the religion to the buffer, reads it back in, and then uses that religion to set both the ItemTalisman and ExtendedProperties data, on the SERVER.

And....that call will only return the player that is using the client that code is on. It will not get other players within the client's view frustum. Yes, but I'm still not 100% sure that he's trying to get other players and not the one using the code. If so, then you are completely right and that solution will not work, but if it turns out the question was just worded poorly and he is, in fact, trying to render the original player, then it will work. By "EntityPlayer of any kind" I really meant any class, not from any client, though if onGround is working client-side for one player, I don't see why it wouldn't work if you grabbed the EntityPlayer instance from the other client with a ray-trace or something. Apparently it doesn't work, though I haven't tried it.

That has nothing to do with the topic, he is trying to use a method in EntityLiving, not EntityLivingBase, so he needs to check if the entity in question is an instanceof EntityLiving before casting. Stop confusing people with random comments.

The problem is you open another GUI immediately due to the way you are setting your keys / isOn. You shouldn't need to have the renderOverlayEvent at all - just open the GUI when the key is pressed. Btw, KeyBinding#isPressed() will still return true even after the key has been released for a certain amount of time; you want KeyBinding.getIsKeyPressed(), but you shouldn't even need that: @SubscribeEvent public void onKeyInput(KeyInputEvent event) { // gets you the key binding key code, if you want it int kb = Keyboard.getEventKey(); // Keyboard.getEventKeyState() returns true if the key is down, i.e. pressed // you can either use that in combination with the kb, or just use getIsKeyPressed // I've got Minecraft instance stored in a local variable from my constructor if (mc.inGameHasFocus) { // alternatively: if (kb == keys[CUSTOM_INV].keyCode) if (keys[CUSTOM_INV].getIsKeyPressed()) { // sending an open GUI packet to server will also open the GUI client-side yourPacketDispatcher.sendToServer(new OpenGuiPacket(yourGuiID)); } } The way you've got yours set up is quite unnecessary and not very functional, as you've just experienced.

Use your IDE and search in EntityPlayer, I'm sure you'll find something.

I mean you need to send a packet from the client to the server, but you can do it both ways using the exact same packet since you seem to have followed the same network tutorial I did // on the server side, this is how you send a packet to a single player: dispatcher.sendTo(new YourPacket(somedata), (EntityPlayerMP) player); // on the client side, this is how you send a packet from the player to the server // the handling on the server side is for the same player that sent it dispatcher.sendToServer(new YourPacket(somedata)); Note that those are both using the exact same packet, and you have two methods in the AbstractPacket class that you need to implement if you want it to work both ways: /** * Handle a packet on the client side. Note this occurs after decoding has completed. * * @param player the player reference */ public abstract void handleClientSide(EntityPlayer player); /** * Handle a packet on the server side. Note this occurs after decoding has completed. * * @param player the player reference */ public abstract void handleServerSide(EntityPlayer player);

ItemStack NBT. Only way, and it's fairly simple when you get used to it.

You don't know how to prevent class cast exceptions? It crashed because whatever code you ran is indiscriminately casting every single entity it comes across as an EntityLiving, when the entity may very well not be one, such as the EntityPlayerMP in your crash log. Solution: instanceof

You can't be serious... haven't you been paying attention to the thread at all? EntityLiving#setAttackTarget has been featured in probably every single bit of code that has been used in the examples.

Unfortunately, yes, that's what quite a lot of the code still looks like in 1.7.2, and even some in 1.6.4, but for the most part, even in 1.7.2 the most commonly used bits of code are entirely deobfuscated with human readable names; looks like you just found one of the more obscure ones Don't give up, it's not so bad!

Don't listen to what that guy said about registration - he obviously has no clue. Anyway, what you're doing wrong is you're setting the values client side, but your packet is set up to only sync data from the server TO the client, not the other way around. Easy fix is just allow your packet to be handled server side as well, reading everything from some bundled NBT that you send, but I do NOT recommend that. Instead, what you should do is send a packet directly from the GUI to the server, saying "button x was pressed, do something", and then parse through the button ids server side setting the data as you need. This will avoid the issue of possible bad packets from the client overwriting your server side data, and you should then be able to synchronize right away with your normal packet. I prefer to have dedicated packets for various things, rather than sending the entire properties data every single time, but that's up to you.

There I go again, quoting myself... if you add @Override to a method that you know is from the super-class and you are getting an error, it's because your method is WRONG. See quote above.

I don't think you know what your saying. ^^ You just said he doesn't know what he's saying, then later say "I know [that this is exactly what you {diesieben07} just said]" I'm befuddled by your contradictory statements, but I'm sure the OP will appreciate your IDE usage tutorial