Entoarox

as the issue is not in any way related to forge, it would be best if you got help at the NEI or individual plugin topics on the MCforums, as the modders there will have more experience with the issue you are having i am sorry i can not be of any further aid, but unless you have individual error logs for each there is simply no way to even start finding out what your issue is, the peope who have experience with these issues might be able to aid you though

seeing as forge could have been part of the problem, this could very well have been the correct place @OP: the error is caused because you have the wrong version of forestry, the NEI plugin expects a newer or older (but most likely newer) version of forestry try updating it, that should fix the problem

all updated forge builds include a fix for the 4096 block id's so that is not the issue try cleaning up your jar completely, then boot with just forge, then install only jar mods one by one (boot mc after each) once that is done, you can start adding mods to your mods folder also one by one (the one by one princible is to see when the bug happens) ps: the nei plugins do not need to be in the jar, you can put the zipfiles in your mods also - or you can put the needed files directly into the NEI zip

my jar is almost the same as yours except i dont have mystcraft, so that might be causing the issue anyhow, here are some ideas as to solve it: 1) Make sure you have the correct forge version for mystcraft's patch to work 2) Remove mystcraft 3) Update forge i'd try them in order so you can find where the issue is caused

not gonna happen, the best we will get is a pre-release so lexmanos can start bugfixing all the new bugs that are bound to pop up due to 1.3

1.3.1 is not out yet, forge itself is being changed so its easier for modders to use, put that on top of the fact that MC 1.3 is a massive change in how minecraft works and yeah.... follow the forge github to see how the update is comming along!

Just sayin.. you're a moron then, just sayin.. Anyways enough of this just sayin crap. Anyone who thinks that Forge instantly get updated is stupid, I am working my but on getting it updated though. View the git for progress commits. and we all love that you are working so hard to make us lowly minecraft-addicts happy!

You did not supply enough info for people to be able to help you please post the error found in modloader.log or forgeModloader.log if you are using FML

9/10 people will already have it but the main reason for you to use forge is so you can safely create a mod without editing minecraft itself - meaning that all other mods that dont edit minecraft will work with yours without patches!

they really should have put more time between the pre-release and official release of 1.3, they simply changed the basecode to much for such a short time between them, especially for a major API like forge!

atually, i had MLMP for 1.2.5 installed because a mod i was using was not yet updated to FML due to how this mod interacted with MLMP, it caused no issues with FML this is not the case with all MLMP dependant mods of course, so its a bit of trail&error to see the ones that dont rely on MLMP to heavily

forge no longer needs MLMP, if the mods you are using still rely on them, install MLMP before forge and hope it wont mess things up

maybe forge eventually will, but if it does, it will have to do so properly (aka, making sure all existing mods that rely on dimensionAPI can be ported without loss of features) forge already removed 2 dependencies for modders, but seeing as the mod API is quite close, i dont think we can expect forge to include any other 'big' API replacements simply because it would not be worth all the trouble it takes to make it happen

i do agree that having something like the ore dictionary that has forge give a cirtain 'rarity value' to all vanilla items and allows mods to add their own items to it for cross-mod compatibility would be nice perhaps even create a 'category' system next to the rarity for mods like forestry so external mod items can be properly added to backpacks without having to manually add their item/block id's

that is actually false, mods can still be SSP - but they will work the same as an SMP mod, just designed to only interact with the local client also its not wise to forget that although the client creates a server behind the scenes, this is still part of the client itself, and thus its not actually needed to implement cirtain safety procedures etc for SSP mods Still, you have to code for the internal server and internal client, and the code can be used for multiplayer. So in a sense making it work single player will make it work multiplayer. true that an SSP mod for 1.3 could theoretically work for SMP, but i'd not trust such a mod due to lacking safety procedures etc of course, adding such procedures would be a lot easier for mod creators, so i am rather interested to see if most mods will actually be SMP from now on

that is actually false, mods can still be SSP - but they will work the same as an SMP mod, just designed to only interact with the local client also its not wise to forget that although the client creates a server behind the scenes, this is still part of the client itself, and thus its not actually needed to implement cirtain safety procedures etc for SSP mods

if mathhelper is better after JIT kickes in, is there not a way to force JIT to kick in immediately? (either by running some stuff behind the scenes during game-load or by somehow manually enabling it?)

not against it personally, but in order for this to work, would they not have to re-write half the vanilla sound handling code? (i am not a java expert, and honestly have not spend a lot of time looking over the MC base-code)

the issue though is, that most people who use optifine with forge, actually do so for GFX and FPS improvements, not for texture packs such improvements i'd see as being a "good" idea to have in forge, but as we have a perfectly working forge-compatible optifine available, why bother? note: anyone asking about ML or MLMP should be reminded forge NEEDED those to work, neither forge nor optifine NEED the other to work

this should actually be deemed a bug in the mod, no client-side mod has need for the username to store data properly, doing so is therefore useless storing info on a SMP server by username i can get, not on a client where a mod SHOULD assume a single user per world anyhow

texture pack == no mods in 99/100 cases why? cause mods themselves have 16x16 textures, and almost no texture packs have support for those mods so building something like optifine into forge is like adding a jet-engine to a car, not needed, costs more fuel then is required, and usually ends up with stuff going boom

i do understand that you cannot force people to make use of such a function, but my personal experience with mods for other applications i have found that similar features are often well-received because they make the resulting mod a lot more user-friendly right now, each mod gets atleast one config file, with some even getting more when it comes to having a server-compatible client, this effectively means tons of files that need to be copied and placed in the correct locations (as not all mods use the config directory either, including 2 of the biggest ones [buildcraft&redpower]) i just felt that having a central location to change/register all blocks, items etc would be both easier for the end user, and for the modders as they only need to get the ID's from forge, and modders wont have to follow eloraams example (not that its a bad thing!) in making redpower re-assign its own ID's like i said, i know you cant force people to use it, but having it available would seem to me a great tool for modders and users alike this will be the last i reply to this topic, i simply wished to give my idea in such a way that it was correctly understood and that my reasons behind the idea where clear

i must say i swear by optifine, simply because of one reason: it plays nice yep, thats all, optifine does not cause any trouble with any of the many MANY mods i tried, where that thrice-damned patcher causes tons of issues MCPatcher might (MIGHT!) work better for vanilla content, but it crashes quickly as soon as mods come into play while the worst i have ever had with optifine is texture errors i'd rather my game has some texture problems if running to long, then that it suddenly goes dead without any visible reason

i honestly dont get why it would be so hard to have forge implement a system that allows it to manage the block/id's i am not saying it should overwrite the existing system, but more like: > mod asks the forge API to give an ID for object X > the forge API checks its settings list if the object already has an ID, if so returns that, if not, assigns a new one > the mod is given the ID by forge, and registers it in minecraft the normal way

@lexmanos: he also had a point about a "default ores" that i personally think is a good one right now, its possible to get diferent versions of the same ore in your inventory, but if mods are told "use this version" instead of "these versions also exist" then it would lower inventory space usage and make the the seams between mods less