Mew

I would say you are right And I also couldn't see it on that list, sorry. I also know someone had made a topic for this awhile ago... There were a few if I recall correctly. One was a tutorials type thing, another was questions about it. Try finding those

Umm, i'll try? There is a rendering event that allows you to render models onto the player. Using this event, you render your models onto the player. I just can't remember the name of the render event....

Using the Something or other render event, you can render the model onto the player.

There are a few extra things with the interfacing way, with the NBTTagCompound straight from the player... I haven't really done that.

Lol.... Try using the PRE render event. And I know what I am talking about with those two statements I think you will find. Without them, openGL does NOTHING. But that about nearly covers what I do know about openGL... I can do translation, rotation and resizing. That is about it.

Well... You could do that I suppose, but that is a bit weird... But it also could be the best way to do this... What I would consider is changing the reach distance that the player has, but only when the item is held. Another thing you could is that when you left click, you get the animation of the item moving etc., and then send out an invisible projectile that gives off the illusion of the item reaching that far... Actually, there are lots of things you can do. But hey, just find one that you would rather work wit...

You need the push/popMatrix... So this: @ForgeSubscribe public void ArmorlvlTest(RenderGameOverlayEvent.Post event){ //========Resolution======== res = new ScaledResolution(mc.gameSettings, mc.displayWidth, mc.displayHeight); int width = res.getScaledWidth(); int height = res.getScaledHeight(); //========Resolution========+ this.mc.renderEngine.func_110577_a(new ResourceLocation("Num/Chintzy/Preview.png")); GL11.glPushMatrix(); GL11.glEnable(GL11.GL_BLEND); drawTexturedModalRect(width-120, height-80, 75, 105, 110, 50); mc.func_110434_K().func_110577_a(Gui.field_110324_m); GL11.glPopMatrix(); }

This is very possible. If you have lots of data that you want to store, than you can make a class that implements IExtendedEntityProperties ( or something similar to that name ). Or you can use NBTTagCompound playerNBT = playerInstance.somethingToGetNBT(); playerNBT.setInteger( "MyIntegerForSomethingToBeStored", myIntegerToBeStored );

That's just how things work isn't it?

Meh, I don't know. All I know is, ever since I read through Questology source ( which diesieben07 wrote ), I have been using preInit. And I also would tend to do what die says, he isn't very often wrong.

Uhh, no. That is not what die was saying... he said PREINIT Which is this one: public static Item CactiAxe; @EventHandler public void preInit(FMLPreInitializationEvent event) { CactiAxe = new ItemCactiAxe(*your args here*).setUnlocalizedName(*your unlocalized name here*); //and etc for the other items/blocks }

I would be inclined to agree with you on this one. @OP: Try changing them to "MagicInfuserItems" and "MagicInfuserSlots". Or you could do as MrrGingerNinja says and use your modid. But i would personally would do something more like: "*Modid*MagicInfuserItems" and "*Modid*MagicInfuserSlots" ( where *Modid* is your mod's modid ). But really, it is up to you.

NOOOOO!!!!!! Try something more like: EnumToolMaterial BEDRITE = new EnumHelper.AddToolMaterial("BEDRITE",3,2542,20.0F,3.0F,20); private static final Item toolPickaxeBedrite = new ToolPickaxeBedrite(5029, BEDRITE).setUnlocalizedName("BedritePick"); private static final Item toolShovelBedrite = new tutorial.generic.items.tools.toolShovelBedrite(5030, BEDRITE).setUnlocalizedName("BedriteShovel"); .... You need to learn java. Now, yesterday, THREE YEARS AGO!!!

And aside from contrary belief, that IS the right variable. I have used it in a spell API...... So yes, it does work

I shall jump in and help good sir! But really, it is a matter of java knowledge I am sorry to say... But here is what you will want: package com.example.demomod.network; import net.minecraft.entity.player.EntityPlayer; import com.google.common.io.ByteArrayDataInput; import com.google.common.io.ByteArrayDataOutput; import cpw.mods.fml.relauncher.Side; public class TestPacket extends DemoPacket { private int randomInteger; public TestPacket(String randomInteger) { this.randomInteger = randomInteger; } public TestPacket() { } // Be sure to always have the default constructor in your class, or the reflection code will fail! @Override protected void write(ByteArrayDataOutput out) { out.writeInteger(randomInt); } @Override protected void read(ByteArrayDataInput in) throws ProtocolException { randomInt = in.readInteger(); } @Override protected void execute(EntityPlayer player, Side side) throws ProtocolException { if (side.isClient()) { // Crap... Umm, aside from that, I can't remember what I am doing. You basically have to make it so that the GUI gets the integer... I really can't remember... I know I have done it before, but I would have to double check code. I believe that I remember thinking it redundant.... So don't think it's redundant. I will be back with some working stuff } else { throw new ProtocolException("Cannot send this packet to the server!"); } } } [** EDIT **] Well, here is the packet: https://github.com/ModderPenguin/MinePG/blob/master/source/minepg/rpg_common/rpg/network/packet/PacketPlayerInfo.java And here is where it gets sent: https://github.com/ModderPenguin/MinePG/blob/master/source/minepg/rpg_common/rpg/comm/ConnectionHandler.java ( Note that it is near the bottom of the class ) So basically, it was setting the data back to itself. Like I said, seems redundant. But it's not. It is basically telling the client what the new data is. Also, on the closing of the GUI, you would want to send the packet again ( but to the server ) etc. Basically every time you want to update the data between the two, send the packet. And yes, my packets are slightly different... Feel free to use my setup as examples. I quite like my packet setup actually, even though it was diesieben07 who I got it from. Thank him for it next time you see him

I would suggest getting the block that you are looking at... What I mean is, on item right click, get the block you clicked, and then using the functions of that block ( after checking that it is indeed a redstone wire that has been clicked ), set the power to max.

A very nice solution my friend. That is very well thought out. There are so many things one COULD do with a mod, but not many people harness the possibilities... Sorry for my soliloquy peeps

Try looking at my discontinued mod's packets, MinePG. link: https://github.com/ModderPenguin/MinePG/tree/master/source/minepg/rpg_common/rpg/network/packet

Why are you doing all that queue stuff? You just need to go OutgoingWormholePacket packet = new OutgoingWormholePacket(params); packet.makePacket(); and you should be good

Well... I have no idea. Could I see some of your code? Especially the code that is related to the sending of the packet, the packet, and the any data associated with the packet.

Try using diesieben07's advanced packet handling tutorial. It works like a charm for me. After being explained what packets do, I now see so many errors that I have had in my mods before Here is the tutorial http://www.minecraftforge.net/wiki/Advanced_Packet_Handling

No. No. and.... No. You are wanting the SERVER to tell the CLIENT that the fire has disappeared, so you want to have the BlockBreakPacket executed on the server and have the results sent to the client. So yes, I think you may need your own packets because you have to let the server know that the microphone is being blown and how strong etc. Then, in a handler that is server side, do the checks to see if the microphone has been blown enough to put out the fire and send the packet. So I am thinking you will only need one packet, but I may be wrong.

Are you sure it's not making it to the server? Its quite hard ( for me anyway ) to determine wether or not the packet has gone through...

Wish I knew I would agree with GotoLink, but the fact of the matter is that you still have to tell the server that a block w Actually, wouldn't the block break packet be sent from the server to the client? Because the WorldGen and block location stuff is all stored server side, the client just displays that information. That is probably why the first packet is not working. You are sending the packet from the client, back to the client again.

1, is extremely rare I believe. And 100 is fairly often. At least, that's what I remember it being