coolAlias

You seem to be doing a lot more work than is necessary. Take a look at this. It works straight out of the box, all you do is register your packets and initialize/post-initialize the packet pipeline.

Uh oh. The most eloquent description of an error I've seen, well played sir!

Draco, I know this is an old thread, but if you plan on updating to 1.7.2 or just want to improve your code, I thought I'd chime in with support for CJCutrone9's method; you don't even need to create a Teleporter, just use the default one. This way, you don't have to offset the player's position by some crazy amount (even 256 wasn't working for me). Check it out: // obviously make sure you are server side, then get the world server's default teleporter: ((EntityPlayerMP) player).mcServer.getConfigurationManager().transferPlayerToDimension( (EntityPlayerMP) player, 0, ((WorldServer) world).getDefaultTeleporter()); // get the height value so you don't get stuck in solid blocks or worse, in the void double dy = player.worldObj.getHeightValue( MathHelper.floor_double(player.posX), MathHelper.floor_double(player.posZ)); // still seem to need to set the position, +1 so you don't get in the void player.setPositionAndUpdate(player.posX, dy + 1, player.posZ); It works perfectly, and no freaking Nether portal!!!

If you only need to deal with things like recipes and options that don't affect your mod's Items / Blocks directly during pre-initialization, then you can simply check if the mod is loaded in postInit and do what you need to do there. Use Loader.isModLoaded("modid") to check if a mod is loaded.

^^ What he said. The basic premise is correct, though; use the armor tick update method and check that the player is wearing your armor in all 4 slots using getCurrentArmor. The indices above are correct, (0 is boots, etc), so be sure to compare the correct slots as well as null check or you will crash if the player is not wearing any particular piece. ItemStack boots = player.getCurrentArmor(0); // do same for legs, chest, helm if (boots != null && boots.getItem() == YourMod.yourSpecialBoots && // do so for the rest of them) { // add potion effect }

Not really, but there is the PlayerInteractEvent which fires for LEFT_CLICK_BLOCK, RIGHT_CLICK_BLOCK, and RIGHT_CLICK_AIR. Use that to check (on right click block) if the held item is an axe and do your thing from there.

Wherever you initialize and register your blocks, you also need to register your tile entity: GameRegistry.registerTileEntity(YourTileEntity.class, "uniqueTileEntityName"); Are you 100% sure that your data is not saving and loading correctly, and not just that you are not seeing it on the client when you reload? Custom tile entity data is not automatically sent to the client, so if you require your "color" variable, for example, to render your tile entity, of course it will be "reset" when you re-load the world, since the client side doesn't know about the server side values. I recommend you first put some debugging statements in your read from NBT method to print the variables stored in there. If those are printing correct values, then you need to add the following two methods to your tile entity class: @Override public Packet getDescriptionPacket() { NBTTagCompound tag = new NBTTagCompound(); this.writeToNBT(tag); return new S35PacketUpdateTileEntity(xCoord, yCoord, zCoord, 1, tag); } @Override public void onDataPacket(NetworkManager net, S35PacketUpdateTileEntity packet) { readFromNBT(packet.func_148857_g()); } That should synchronize the client-side tile entity when it is loaded from NBT on the server.

What I'm saying is that you don't need to store any Block in your crop class; just access them directly instead. Meaning your constructor should only have one or two arguments, none of which are Blocks. cucumberVine = new ModBlockVine(Material.vine, ModItems.cucumber) There you go. Also, are your Items initialized at this point? This just looks like a recipe for disaster.

Looking through the vanilla code is always your best bet for finding out how things changed.

Nice! Thanks.

That's not how it works. You can import classes, of which the items may be a field, but if the item is not a local field in your crafting handler class, then of course you cannot access it simply by typing it in there, not to mention you should follow standard code naming conventions. If you're using Eclipse, hover your mouse over the error and it will generally tell you what's wrong, from which point Google / Java tutorials can further help you resolve the issue

This is most likely the problem. cucumberVine = new ModBlockVine(Material.vine, cucumberVine, cucumberVineGrown, ModItems.cucumber) Look, you initialize cucumberVine, passing it a reference to itself and the currently uninitialized cucumberVineGrown, then you point cucumberVineGrown at a new instance of block. Why don't you just try using your blocks directly, rather than storing a Block within a Block? if (this == ModBlocks.cucumberVineGrown)

You need to give it an ItemBlock, or use ISimpleBlockRenderingHandler. // returns a generic ItemBlocK: Item.getItemFromBlock(yourBlock)

Hi, I've recently decided to attempt creating an API for my mod, but I can't seem to figure out how to build a deobfuscated version of the jar using gradle that I can then run through Eclipse and reference as a library; basically, a "dev" version of the mod. Thanks for any help!

You should be using the RenderGameOverlay event to render overlays, not a tick event. Also, don't create a new HaloRender every single tick; it only needs to be done once. Check the wiki tutorial for more about rendering game overlays; it's for 1.6, but still pertinent in 1.7.

What exactly is the problem, other than the horribly named parameters? You're going to have to give us more information.

Here is a tutorial about making a custom projectile. The easiest way is to extend EntityThrowable, since EntityArrow has lots of hard-coded features that won't work for you if you just try to copy them. As for rendering, the simplest yet again is to just register your entity to a new RenderSnowball(yourItem). That will render your item as a thrown object without having to do anything fancy; otherwise you will need to look at a variety of render codes / learn about openGL and figure out how you want your knife to render in the air.

Every packet class MUST have an empty constructor: public YourPacket() {} Otherwise you crash.

Right-click your en_US.lang file from within Eclipse, go to "Properties" and check that it is using the default encoding (should be "Cp1252"). And just to double-check, your lang file is located in "src/main/resources/assets/fallout/lang/", which should be the same "assets/fallout/" folder that your textures folder is in, correct?

Did you register your packet in the PacketPipeline class? If you don't register your packets, it can't process them. I do it in tandem with the initialization process: public void initialise() { this.channels = NetworkRegistry.INSTANCE.newChannel(ModInfo.CHANNEL, this); registerPackets(); } public void registerPackets() { registerPacket(SomePacket.class); registerPacket(SomeOtherPacket.class); } Also don't forget to call postInitialise() during post initialization. @Chibill - I have never had any problems with my packets getting sent in the normal client mode, nor in the regular Minecraft launcher; you must be doing something incorrectly.

^^ This, though it has been renamed to onArmorTick in 1.7. Never use a TickHandler / TickEvent when there is already one built in.

What I always do first when a build fails is run "gradlew --refresh-dependencies setupDevWorkspace" in my mod folder, then try again. It's worked for me almost every single time when I've had any kind of problem with my workspace. If that doesn't work, has your mod ever recompiled successfully say on the Forge recommended build 1024? You might want to give that a try as well.

That might be a problem with reobfuscation then. Try running "gradlew --refresh-dependencies build" and see if that helps, or even re-run "gradlew setupDevWorkspace" before building. On a side note, you can use event.source.getEntity() instanceof EntityPlayer as a more generic way to check if a player was the cause of damage, rather than only checking for damageType().equals("player"). The latter will not work for things like projectiles, while the former will.

Interesting. That works in 1024 as well. Guess someone derped on the "authors" tag. Thanks!

Hey again, Is anyone else having trouble with the "authors" from mcmod.info not appearing in Minecraft? All my other fields are working, and the file works in 1.6.4. The mcmod.info file supplied with Forge 1024 does not show the author field either. Is this just a quirk of Forge 1024? The Forge mods all show their authors correctly, though I haven't been able to figure out how to peek at the mcpmod.info file they use. Thanks for any tips.