LexManos

It puts the files into the current working directory. So however you have java assigned to run is where things go. Typically it's the directory that has the file.

what launcher are you using? seems to me like you've installed the wrong launch wrapper version for the Forge version. Which shouldnt be possible unless you're using a odd install/launch method....

interesting this looks like your player is in a dimension that is not known to the game. Try deleting your player.dat file and connecting again

Are you REALLY gunna have more then 4096 blocks loaded at a single time.. I think not. And if you do, either the modder should be shot or you need to reign things in. 'Unlimited' never exists, there will ALWAYS be a limit, this one is in place based off the save format.

why?

Back from Minecon, catching up on BS that happened while I was gone. Anyways to answer simple question. AGAIN Block IDs are moved into a central registry, and when it comes to how you REFERENCE blocks and items. Don't be stupid you should not query the registry for EVERY access, that would be a massive waist of time. This is a example of vanillai: REGISTRY.register(256, "minecraft:iron_shovel", new ItemShovel(IRON)...); REGISTRY.register(257, "minecraft:iron_pickaxe", new ItemPickaxe(IRON)...); REGISTRY.register(258, "minecraft:iron_axe", new ItemAxe(Item.Tier.IRON)...); REGISTRY.register(259, "minecraft:flint_and_steel", new ItemFlintAndSteel()...); REGISTRY.register(260, "minecraft:apple", new ItemFood(4, 0.3F, false)...); public static final Item IRON_SHOVEL = REGISTRY.get("minecraft:iron_shovel"); public static final Item IRON_PICKAXE = REGISTRY.get("minecraft:iron_pickaxe"); public static final Item IRON_AXE = REGISTRY.get("minecraft:iron_axe"); public static final Item FLINT_AND_STEEL = REGISTRY.get("minecraft:flint_and_steel"); public static final Item APPLE = REGISTRY.get("minecraft:apple"); And as such you simply do itemStack.getItem() == IRON_SHOVEL and you're done zero fucks to be given about ids. IN Forge we will most likely completely and utterly ignore the first parameter to REGISTRY.register, vanilla adds it manually so they can keep old world compatibility. In Forge we can ignore it and assign IDs ourselves. NOWHERE else in code should IDs be referenced, ever. If you guys dont get it.. then well ya.. try harder...

Run the installer from the console, and then paste the log here.

Make sure you do not have any other server processes running. This ha;penes when two or more MC server are reading from the same folder. If this is not the case after shutting down ALL MC servers that could possible interact with it go into your world folder and delete session.lock

You didnt install them correctly or they are not packed correctly, or they are not real mods at all. Cant really help you without LOGS!

As the mojang blog post said, the major changes: IDs go bye bye, Networking System switched to netty, Sound system overhaul. So yes when it comes to packets, things will change.

We may be doing something unofficial, so stay tuned to Direwolf/slowpoke/me on twitter and we'll announce if we do anything. Sadly, time is a bit tight as it's just a two day con and we have other panels/business to attend to but we would love to have a meet and greet. I do advise anyone there to attend the modding panels! I will at least be attending most of them!

There are no plans to ever add in any update checking, or any other call-home style functionality to Forge. Its just not something that I personally agree with, and considering that TONS of mod packs use older versions of Forge, i'd have to write in a disabling mech and then people will want to use the same code for there mods/server.. it;'s a pain Just check the page once a day, or less. We typically announce any major releases {Recommended builds}. Once we hit the stable releases it's usually non-critical updates. Anyways, there has been some work twards 1.7 on the MCP end, and we're progressing pretty good on the gradle stuff. Nothing actually useful to the end users/modders yet, but as I said in the original post, most of us are busy getting ready for Minecon WHoo!

Caused by: java.lang.NullPointerException at codechicken.core.asm.FeatureHackTransformer.transformer001(FeatureHackTransformer.java:31) Broken ChickenCore mod.

This is exactly why you use the installer.

2013-10-27 17:09:29 [sEVERE] [Minecraft-Client] Using missing texture, unable to load: speedytools:textures/items/WandIcon.png, (assets\speedytools\textures\items\WandIcon.png); That's just redundant data...

Abrar has done most of the hard work, we have a functional dev workspace for FML. And then two more for working WITH Forge/FML {For modders, so it doesn't decompile Minecraft} After that, it's just cleaning up the code and making it pretty/configurable. This is nothing to do with Minecraft itself, it's just the automation so you don't need to know anything about minecraft specifically. My main issue is that, I am still learnign the basics of Gradle. Especially it's internal API and how tasks are created/cached/tracked. Most of the functionality is all done, just needs glue/organization.

Try removing morph and see what happens.

It's linux "Minecraft_server.1.6.4.jar" != "minecraft_server.1.6.4.jar" Cases matter -.-

at codechicken.nei.LayoutManager.objectUnderMouse(LayoutManager.java:142) Not a Forge issue, it's a NPE in NEI, talk to chickenbones.

Go to your mods folder.. And delete the file -.-

Well, looking into it, this is caused by the AI Task running even though it's conditions would evaluate to false. The only way that happens is if one of your mods, adds an extra AI Task that resets the condition after it's been evluated. Namely, if they reset the entity's target to null. If you're willing, and could send me a zip with your world/mods/everything and can explain how to reproduce this I can try to track it down. However, this doesn't really look like a vanilla or Forge issue as I said, it would require your mods to add a AI task that doesn't take into account other tasks.

Again, this is typically a modder issue, remember, ZipFiles ARE case sensitive, Windows is not. Also, remember that domains, as a arbitrary decision made by Mojang, are REQUIRED to be lower case. So your issue is probably stemming from the capitol M's. As for gathering a list of tried paths, The better solution would just to print out the root 'paths' of all the resource packs as they are loaded into the debug console. And people can abstract where there folders should be from there. However, part of that issue is that the path your output gives is actually the WRONG path for the development environment. Where you WOULD want to put it is in the SOURCE folder that you have linked in eclipse, and then while compiling, eclipse will copy your assets into the bin folder. As the bin folder is designed to be transient and you should not manually be putting anything in there at all. Anyways, to help solve Dracos issue, i've fixed a bug in MC that make the log message useless. You now get useful information: 2013-10-27 10:57:21 [WARNING] [Minecraft-Client] ResourcePack: ignored non-lowercase namespace: Forge/ in Z:\Forge\eclipse\Forge\bin

Get rid of Minecraft Comes Alive mod that you have, it's not packed correctly and is causing issues. Nothing to do with Forge.

That would be up to whatever mod is implementing the interface for crafting, and would require us to implement a fairly fundamental change into how crafting works. Yes crafting conflicts are a pain, but there is no simple way to fix without making it look like crap. We could add in conflict warnings, potentially... that may be something to look into... However, there is a reason mods add different machines/tools for creating things, to help prevent these conflicts.

Out of memory, what, permgen or heap? And depending on your mod set, 4GB may not be enough. Some mods are hogs on memory. Also, pagefiles may be an issue, as what a PageFile is is it's a file on disk that your computer thinks is actually extra ram. There are a lot of fancy optimizations done to it, but MC is horrible with ram. So relying on the pagefile for normal running would be bad. As those slowdown may be disk IO time. I'd start by trying to find out which OOM error you're getting. It *should* print to atleas the console, so try running from the console. After that i'd go back to disecting the mods themselves, see if you can track it down to the specific mod.