I can't even get ID Resolver to work with one extra mod that add items.... Quite annoying since I have mulitple and won't be able to use them all because of conflicts.
Time: 5/27/13 10:09 AM
Description: Failed to start game
java.lang.RuntimeException: error loading theme
at sharose.mods.guiapi.GuiWidgetScreen.getInstance(GuiWidgetScreen.java:84)
at sharose.mods.idresolver.IDResolver.<init>(IDResolver.java:2499)
at sharose.mods.idresolver.IDResolver.getConflictedBlockID(IDResolver.java:938)
at sharose.mods.idresolver.IDResolverBasic.getConflictedBlockID(IDResolverBasic.java:110)
at net.minecraft.block.Block.<init>(Block.java:338)
at net.minecraft.block.BlockOre.<init>(SourceFile:12)
at com.elvenwater.malkierian.Plasmacraft.common.blocks.BlockPlasmaOre.<init>(BlockPlasmaOre.java:30)
at com.elvenwater.malkierian.Plasmacraft.common.PlasmaCraft.registerBlocks(PlasmaCraft.java:354)
at com.elvenwater.malkierian.Plasmacraft.common.PlasmaCraft.load(PlasmaCraft.java:327)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:515)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:314)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:314)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:98)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:689)
at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:206)
at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:444)
at net.minecraft.client.MinecraftAppletImpl.func_71384_a(SourceFile:56)
at net.minecraft.client.Minecraft.run(Minecraft.java:729)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: while parsing Theme XML: classloader:twlGuiTheme.xml
at de.matthiasmann.twl.theme.ThemeManager.parseThemeFile(ThemeManager.java:280)
at de.matthiasmann.twl.theme.ThemeManager.createThemeManager(ThemeManager.java:190)
at de.matthiasmann.twl.theme.ThemeManager.createThemeManager(ThemeManager.java:155)
at sharose.mods.guiapi.GuiWidgetScreen.getInstance(GuiWidgetScreen.java:66)
... 39 more
Caused by: org.lwjgl.opengl.OpenGLException: Invalid value (1281)
at org.lwjgl.opengl.Util.checkGLError(Util.java:56)
at de.matthiasmann.twl.renderer.lwjgl.LWJGLTexture.<init>(LWJGLTexture.java:152)
at de.matthiasmann.twl.renderer.lwjgl.LWJGLCacheContext.createTexture(LWJGLCacheContext.java:106)
at de.matthiasmann.twl.renderer.lwjgl.LWJGLCacheContext.loadTexture(LWJGLCacheContext.java:67)
at de.matthiasmann.twl.renderer.lwjgl.LWJGLRenderer.load(LWJGLRenderer.java:522)
at de.matthiasmann.twl.renderer.lwjgl.LWJGLRenderer.load(LWJGLRenderer.java:511)
at de.matthiasmann.twl.renderer.lwjgl.BitmapFont.<init>(BitmapFont.java:143)
at de.matthiasmann.twl.renderer.lwjgl.BitmapFont.loadFont(BitmapFont.java:290)
at de.matthiasmann.twl.renderer.lwjgl.LWJGLCacheContext.loadBitmapFont(LWJGLCacheContext.java:123)
at de.matthiasmann.twl.renderer.lwjgl.LWJGLRenderer.loadFont(LWJGLRenderer.java:361)
at de.matthiasmann.twl.theme.ThemeManager.parseFont(ThemeManager.java:436)
at de.matthiasmann.twl.theme.ThemeManager.parseThemeFile(ThemeManager.java:319)
at de.matthiasmann.twl.theme.ThemeManager.parseThemeFile(ThemeManager.java:271)
... 42 more
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- System Details --
Details:
Minecraft Version: 1.5.1
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_10, Oracle Corporation
Java VM Version: Java HotSpot™ 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 417785008 bytes (398 MB) / 672399360 bytes (641 MB) up to 954466304 bytes (910 MB)
JVM Flags: 2 total; -Xms512m -Xmx1024m
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: FML and Forge are installed
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
FML: MCP v7.44 FML v5.1.8.611 Minecraft Forge 7.7.1.611 Optifine OptiFine_1.5.1_HD_D1 7 mods loaded, 7 mods active
mcp [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized
FML [Forge Mod Loader] (coremods) Unloaded->Constructed->Pre-initialized->Initialized
Forge [Minecraft Forge] (coremods) Unloaded->Constructed->Pre-initialized->Initialized
mod_ReiMinimap [mod_ReiMinimap] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized
GuiAPI [GuiAPI] (GuiAPI-0.15.4-1.5.1.jar) Unloaded->Constructed->Pre-initialized->Initialized
PlasmaCraft [PlasmaCraft] (Plasmacraft-0.3.4.zip) Unloaded->Constructed->Pre-initialized->Errored
IDResolver [ID Resolver] (IDResolver-1.5.1.0.jar) Unloaded->Constructed->Pre-initialized->Initialized
LWJGL: 2.4.2
OpenGL: ATI Radeon HD 4200 GL version 3.3.10834 Compatibility Profile Context, ATI Technologies Inc.
Is Modded: Definitely; Client brand changed to 'forge,fml'
Type: Client (map_client.txt)
Texture Pack: Default
Profiler Position: N/A (disabled)
Vec3 Pool Size: ~~ERROR~~ NullPointerException: null
Could you post the Forge log, it will give us more information. Also, it appears to be a GUI error, whether that means GUIAPI or OpenGl, I'm unsure (someone with more OpenGL experience will have to tell you that).
What is the single mod that causes this error?
Is there any alternatives which list item ids or something so that i could fix conflicts manually?
See the previous post. However, I want to point out that if you have any significant number of mods the process will be extremely long and difficult. Expect hours of working to fix conflicts before you can play Minecraft again.
You know what? It's taking FOREVER to update, and I really want to get 1.5.2 up and running. Is there any alternative to ID Resolver?
You could stay on 1.5.1 and wait for an update since 1.5.2 doesn't really offer much more than 1.5.1, or you can manually change your ID configs to not conflict.
Those are about your only options at this point. There aren't any other mods that do the same thing as ID Resolver currently.
What I'm doing is moving my 1.5.1 install to 1.5.2 so i can just copy over configs for the most part. That could work as a last resort.
It 'could' work, but it won't if you used ID Resolver to resolve your ID issues... ID Resolver does not edit the config files of other mods, it creates a text file and stores IDs in that file then asserts them into the game upon load (which may be one reason it takes so long to load). You will HAVE to manually edit the configs if you want to use 1.5.2 which you can do more easily by finding the IDs in the ID Resolver config and finding the config file for the specified mod-then searching for the number on the left hand side and replacing it with the number on the right hand side... It's work, but, yeah... it's work.
Is there any alternatives which list item ids or something so that i could fix conflicts manually?
Actually there is away but it is a long and tedious process that still uses id resolver. Basiclly you want to use multimc to add the mods you want to use. You have to add the mods one at a time or else it will never let you do this process.
Id resolver may not auto fix ids for 1.5.2 but you can how ever generate a text file of all free block ids. So the first step is install forge, guiapi, and id resolver and run minecraft. Now get use to this next part becuase you will use it alot. Go to options, global mod options, id resolver, and click generate id status report expanded free ids. This will now save a text file of all the free ids in the game.
Now the tedious part. Add the mods you want to use one at a time and make sure after minecrft loads properly to keep creating the generate id status report expanded free ids so the text file will update. Once you have an id conflict open the status report text file and change the conflicting mod ids to the ones that are free in the list. Just repeat this process until all the mods are working.
After this use nei to check ids for items not blocks to make sure they arn't overiding any recepies for items if they are use the status report to change the items that are being used wrong to a new id. Sometimes items will not cause an id conflict but will mess with crafting items. Example of this issue is the crafting recepie for a steeleaf axe from twilight forest creating dark iron dust from mellurgy 3. Just change the dark iron dust item id to an open one and its fixed. Hope this helps and have fun with changing ids it will take some time.
Actually there is away but it is a long and tedious process that still uses id resolver. Basiclly you want to use multimc to add the mods you want to use. You have to add the mods one at a time or else it will never let you do this process.
Id resolver may not auto fix ids for 1.5.2 but you can how ever generate a text file of all free block ids. So the first step is install forge, guiapi, and id resolver and run minecraft. Now get use to this next part becuase you will use it alot. Go to options, global mod options, id resolver, and click generate id status report expanded free ids. This will now save a text file of all the free ids in the game.
Now the tedious part. Add the mods you want to use one at a time and make sure after minecrft loads properly to keep creating the generate id status report expanded free ids so the text file will update. Once you have an id conflict open the status report text file and change the conflicting mod ids to the ones that are free in the list. Just repeat this process until all the mods are working.
After this use nei to check ids for items not blocks to make sure they arn't overiding any recepies for items if they are use the status report to change the items that are being used wrong to a new id. Sometimes items will not cause an id conflict but will mess with crafting items. Example of this issue is the crafting recepie for a steeleaf axe from twilight forest creating dark iron dust from mellurgy 3. Just change the dark iron dust item id to an open one and its fixed. Hope this helps and have fun with changing ids it will take some time.
My suggestion, just previous to yours, is less tedious. It even allows forward porting from 1.5.1's already resolved IDs and a single (mod) adding process. The config file with the already resolved IDs is, and I want to emphasize this, IS confusing, but it isn't confusing to the point of being useless.
If you've already used ID Resolver and want to go beyond 1.5.1 (and, therefore, ID Resolver) use the config file. It is generally a 1:1 ratio of old ID to new ID (and has the classpath of the mod and item-but these are the confusing part-such as "com.devname.somejunk.somename").
While your method may generally make more sense to people who aren't educated in programming, languages, or <trying not to be insulting, and failing>... the one I'm suggesting is faster, more efficient, and takes less steps.
To anyone reading these: It's entirely your choice. You can try one and then the other... in any order... and choose the method best for yourself. (they BOTH work)
My suggestion, just previous to yours, is less tedious. It even allows forward porting from 1.5.1's already resolved IDs and a single (mod) adding process. The config file with the already resolved IDs is, and I want to emphasize this, IS confusing, but it isn't confusing to the point of being useless.
If you've already used ID Resolver and want to go beyond 1.5.1 (and, therefore, ID Resolver) use the config file. It is generally a 1:1 ratio of old ID to new ID (and has the classpath of the mod and item-but these are the confusing part-such as "com.devname.somejunk.somename").
While your method may generally make more sense to people who aren't educated in programming, languages, or <trying not to be insulting, and failing>... the one I'm suggesting is faster, more efficient, and takes less steps.
To anyone reading these: It's entirely your choice. You can try one and then the other... in any order... and choose the method best for yourself. (they BOTH work)
I agree with you that your method does work faster. The reason I posted my method was to help out the ones that are using mods that never had a version for 1.5.1, or the mod that was for 1.5.1 had added in some new blocks/items to its config list when it updated to 1.5.2. Using your method first and then mine after words to make sure nothing new that was added to the mods will conflict is the best way to get the job done for now until id resolvers gets updated to 1.5.2.
Every time i try to run it i get this crash: (P.S. I am NOT removing buildcraft)
<snip>
Please use spoilers.
If you don't want to lose buildcraft you can either revert to 1.5.1, find whatever mod BC is having conflicts with and drop it, or ideally google "fixing minecraft id conflict" or something of the nature and do it yourself. ID Resolver is a great mod and a great tool but it's main function is to save time and manual effort. It doesn't do anything super magical for the most part and it's not a bad idea for ALL minecraft players that want to use tons of mods to at least learn and understand minecraft ID conflicts.
If you don't want to lose buildcraft you can either revert to 1.5.1, find whatever mod BC is having conflicts with and drop it, or ideally google "fixing minecraft id conflict" or something of the nature and do it yourself. ID Resolver is a great mod and a great tool but it's main function is to save time and manual effort. It doesn't do anything super magical for the most part and it's not a bad idea for ALL minecraft players that want to use tons of mods to at least learn and understand minecraft ID conflicts.
You could *cough* *cough* also read the posts we've placed numerous times about this...
EDIT: Also, I agree, use spoiler tags, not code tags... you could use code tags WITHIN spoiler tags, but you NEED to use spoiler tags. (That should be made a rule for this thread/site, really. Some moderator, please get on that, perhaps?)
EntropySeattle, suggestion, when people ask questions that have been answered direct them to the answer (or to use the very, extremely, exceptionally wonderful "SEARCH" function this website has-nearly better than Google's "site:<website>" search). If the reference is enough pages back (say 3+) then just (right-click, copy URL, paste in textbox) the number in the upper left hand corner of the post and reply with that. It creates a direct link to the post so people can just click and be directed.
Why we should do this level of effort for people who clearly don't want to themselves? Simply because some of the things we are able to do on this site are not exactly evident unless told of or shown. (the 'search THIS thread' feature of the search engine, for example)
I fixed the current problem I was having with the 1.5.1 earlier, it was a conflict with another mod and was easily remedied when I figured it out by installing things one at a time.
However I was curious and hoping that there would be a version of this for 1.5.2 in the works?
I fixed the current problem I was having with the 1.5.1 earlier, it was a conflict with another mod and was easily remedied when I figured it out by installing things one at a time.
However I was curious and hoping that there would be a version of this for 1.5.2 in the works?
We don't know, we haven't heard from ShaRose in a while. I hope he's ok...
Just an FYI for everyone. I have 82 mods installed on my instance without ID resolver and they are all running smooth as butter. It is a great mod, and does make adding as many mods as I have a little easier. You just have to take a little time, ~15-20min when you load a new instance and all your mods, read the crashes, find which ID's from the crash, get NEI and just do a little busy work. Not that difficult.
It kills me when I see people shouting about, "I can't fix this, do it for me!" without taking the time to understand. The lack of investigative and curious intelligence, that humans are naturally born with, is overwhelming...
/rant. Sorry Now I feel bad, but I guess that was just boilin' up. In the end I do hope ShaRose is able to update this because, it is quite the resolver!
Just an FYI for everyone. I have 82 mods installed on my instance without ID resolver and they are all running smooth as butter. It is a great mod, and does make adding as many mods as I have a little easier. You just have to take a little time, ~15-20min when you load a new instance and all your mods, read the crashes, find which ID's from the crash, get NEI and just do a little busy work. Not that difficult.
It kills me when I see people shouting about, "I can't fix this, do it for me!" without taking the time to understand. The lack of investigative and curious intelligence, that humans are naturally born with, is overwhelming...
/rant. Sorry Now I feel bad, but I guess that was just boilin' up. In the end I do hope ShaRose is able to update this because, it is quite the resolver!
Ya...i did that before,be spent me much time,and easy to get error,this tool make everything work more easy,so I wish it can be update.
Just an FYI for everyone. I have 82 mods installed on my instance without ID resolver and they are all running smooth as butter. It is a great mod, and does make adding as many mods as I have a little easier. You just have to take a little time, ~15-20min when you load a new instance and all your mods, read the crashes, find which ID's from the crash, get NEI and just do a little busy work. Not that difficult.
But some people do find that difficult. For some people things that are time consuming are 'difficult' by definition. For some people things that require learning to use a new tool are 'difficult' by definition. For some people the excessive number of times opening and closing Minecraft, getting a crash each time alone makes any process other than using ID Resolver 'difficult'.
I understand these people's plight. Java, by nature, is a developer's language and has many things keyed to making developer's lives easier. Exception throwing (and handling) is one of these things, but when improperly used they simply become... annoying... I don't know if the exception informing users of an ID conflict is something that Mojang coded or something from Java, but if it is Mojang code then it was severely miscoded. End users should never see exceptions-except, of course, in exceptional conditions-as exceptions should be caught and handled by the code that the developer writes.
Basically, what I'm saying is that if Mojang was aware of this-having added it-then they should have wrapped it around something akin to ID Resolver.
It kills me when I see people shouting about, "I can't fix this, do it for me!" without taking the time to understand. The lack of investigative and curious intelligence, that humans are naturally born with, is overwhelming...
Yeah, the investigative and curious intelligence is what makes humans so great, but something you need to remember is that it isn't necessity that is the father of invention... it is laziness. While it is true that the causes all inventions could be said to be need... it is just as true, if not more so, that the causes of all inventions could be said to be laziness. Farming? Didn't want to travel to hunt or forage any more. Fire, same thing. Clothes, didn't want to migrate south when it got cold (or make fire). The wheel? Well, that's an easy one.
I do, however, agree that it is enraging when people whine and yell "Fix this for me, NOW!" rather than bother to do ANY of their own research. Something that is quite clearly evident in this thread or in EE3's.
/rant. Sorry Now I feel bad, but I guess that was just boilin' up. In the end I do hope ShaRose is able to update this because, it is quite the resolver!
No need to feel bad about ranting (you should see how often I do it-though I usually put mine is spoiler tags within talking about something else...) Speaking of that human intelligence... you could try making an ID Resolver... (Yes, so could I, but I'm perfectly content waiting back at 1.4.7 until the mod pack I use is updated... or at least until RedPower2 updates...)
But some people do find that difficult. For some people things that are time consuming are 'difficult' by definition. For some people things that require learning to use a new tool are 'difficult' by definition. For some people the excessive number of times opening and closing Minecraft, getting a crash each time alone makes any process other than using ID Resolver 'difficult'.
I understand these people's plight. Java, by nature, is a developer's language and has many things keyed to making developer's lives easier. Exception throwing (and handling) is one of these things, but when improperly used they simply become... annoying... I don't know if the exception informing users of an ID conflict is something that Mojang coded or something from Java, but if it is Mojang code then it was severely miscoded. End users should never see exceptions-except, of course, in exceptional conditions-as exceptions should be caught and handled by the code that the developer writes.
Basically, what I'm saying is that if Mojang was aware of this-having added it-then they should have wrapped it around something akin to ID Resolver.
Yeah, the investigative and curious intelligence is what makes humans so great, but something you need to remember is that it isn't necessity that is the father of invention... it is laziness. While it is true that the causes all inventions could be said to be need... it is just as true, if not more so, that the causes of all inventions could be said to be laziness. Farming? Didn't want to travel to hunt or forage any more. Fire, same thing. Clothes, didn't want to migrate south when it got cold (or make fire). The wheel? Well, that's an easy one.
I do, however, agree that it is enraging when people whine and yell "Fix this for me, NOW!" rather than bother to do ANY of their own research. Something that is quite clearly evident in this thread or in EE3's.
No need to feel bad about ranting (you should see how often I do it-though I usually put mine is spoiler tags within talking about something else...) Speaking of that human intelligence... you could try making an ID Resolver... (Yes, so could I, but I'm perfectly content waiting back at 1.4.7 until the mod pack I use is updated... or at least until RedPower2 updates...)
phew, was thinking for a second I had to individually quote all all the paragraphs.. hehe.. j/k..
I understand what you mean about the difficulty. The one thing though is we are talking about mods that are outside of Mojangs original code being placed inside of it to manipulate it differently. I know there are a ton of threads about Mojangs base code being terribly inefficient etc., but these modders are only working with what they got. I feel lucky that those exceptions being thrown out are readable, to at least me and I would think many many others. While you are right, we should never see those, we are also lucky in a sense to see them as well. Especially since we are using things that are modifying parameters outside of the original code.
I guess what I am trying to say is yes, I see your point and I agree. It is also my laziness not to learn java and commit time to making another ID resolver. I could .. buuuuut... ya, I think I'll save that one for ShaRose since personally, I'm not having issues as of yet.
You're still in 1.4.7? What modpack is that? Is it the one that is waiting for Redpower which is gloriously on stand-still? That is the one mod I've always wanted but was always on a higher version that it was made for. I would wait and wait and wait, then my coremods would move on, and I'd say screw it. Then days later redpower would update lol.. Well, that's a conversation for another thread.
phew, was thinking for a second I had to individually quote all all the paragraphs.. hehe.. j/k..
I understand what you mean about the difficulty. The one thing though is we are talking about mods that are outside of Mojangs original code being placed inside of it to manipulate it differently. I know there are a ton of threads about Mojangs base code being terribly inefficient etc., but these modders are only working with what they got. I feel lucky that those exceptions being thrown out are readable, to at least me and I would think many many others. While you are right, we should never see those, we are also lucky in a sense to see them as well. Especially since we are using things that are modifying parameters outside of the original code.
I guess what I am trying to say is yes, I see your point and I agree. It is also my laziness not to learn java and commit time to making another ID resolver. I could .. buuuuut... ya, I think I'll save that one for ShaRose since personally, I'm not having issues as of yet.
You're still in 1.4.7? What modpack is that? Is it the one that is waiting for Redpower which is gloriously on stand-still? That is the one mod I've always wanted but was always on a higher version that it was made for. I would wait and wait and wait, then my coremods would move on, and I'd say screw it. Then days later redpower would update lol.. Well, that's a conversation for another thread.
Take care
I'm using a modified version of Feed the Beast. THEY are still waiting for RedPower, and potentially waiting until 1.6. I think it is somewhat ironic that they have run into the same issue that Technic/Tekkit ran into with Equivilent Exchange (with the minor difference that EE2 will never be updated, RedPower will).
Could you post the Forge log, it will give us more information. Also, it appears to be a GUI error, whether that means GUIAPI or OpenGl, I'm unsure (someone with more OpenGL experience will have to tell you that).
What is the single mod that causes this error?
See the previous post. However, I want to point out that if you have any significant number of mods the process will be extremely long and difficult. Expect hours of working to fix conflicts before you can play Minecraft again.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumNope.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou could stay on 1.5.1 and wait for an update since 1.5.2 doesn't really offer much more than 1.5.1, or you can manually change your ID configs to not conflict.
Those are about your only options at this point. There aren't any other mods that do the same thing as ID Resolver currently.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumWhat I'm doing is moving my 1.5.1 install to 1.5.2 so i can just copy over configs for the most part. That could work as a last resort.
It 'could' work, but it won't if you used ID Resolver to resolve your ID issues... ID Resolver does not edit the config files of other mods, it creates a text file and stores IDs in that file then asserts them into the game upon load (which may be one reason it takes so long to load). You will HAVE to manually edit the configs if you want to use 1.5.2 which you can do more easily by finding the IDs in the ID Resolver config and finding the config file for the specified mod-then searching for the number on the left hand side and replacing it with the number on the right hand side... It's work, but, yeah... it's work.
Actually there is away but it is a long and tedious process that still uses id resolver. Basiclly you want to use multimc to add the mods you want to use. You have to add the mods one at a time or else it will never let you do this process.
Id resolver may not auto fix ids for 1.5.2 but you can how ever generate a text file of all free block ids. So the first step is install forge, guiapi, and id resolver and run minecraft. Now get use to this next part becuase you will use it alot. Go to options, global mod options, id resolver, and click generate id status report expanded free ids. This will now save a text file of all the free ids in the game.
Now the tedious part. Add the mods you want to use one at a time and make sure after minecrft loads properly to keep creating the generate id status report expanded free ids so the text file will update. Once you have an id conflict open the status report text file and change the conflicting mod ids to the ones that are free in the list. Just repeat this process until all the mods are working.
After this use nei to check ids for items not blocks to make sure they arn't overiding any recepies for items if they are use the status report to change the items that are being used wrong to a new id. Sometimes items will not cause an id conflict but will mess with crafting items. Example of this issue is the crafting recepie for a steeleaf axe from twilight forest creating dark iron dust from mellurgy 3. Just change the dark iron dust item id to an open one and its fixed. Hope this helps and have fun with changing ids it will take some time.
My suggestion, just previous to yours, is less tedious. It even allows forward porting from 1.5.1's already resolved IDs and a single (mod) adding process. The config file with the already resolved IDs is, and I want to emphasize this, IS confusing, but it isn't confusing to the point of being useless.
If you've already used ID Resolver and want to go beyond 1.5.1 (and, therefore, ID Resolver) use the config file. It is generally a 1:1 ratio of old ID to new ID (and has the classpath of the mod and item-but these are the confusing part-such as "com.devname.somejunk.somename").
While your method may generally make more sense to people who aren't educated in programming, languages, or <trying not to be insulting, and failing>... the one I'm suggesting is faster, more efficient, and takes less steps.
To anyone reading these: It's entirely your choice. You can try one and then the other... in any order... and choose the method best for yourself. (they BOTH work)
I agree with you that your method does work faster. The reason I posted my method was to help out the ones that are using mods that never had a version for 1.5.1, or the mod that was for 1.5.1 had added in some new blocks/items to its config list when it updated to 1.5.2. Using your method first and then mine after words to make sure nothing new that was added to the mods will conflict is the best way to get the job done for now until id resolvers gets updated to 1.5.2.
The ID resolver is now only for 1.5.1...please wait 1.5.2 come out and try again
I wish it can update to 1.5.2 as soon as possble too...
Please use spoilers.
If you don't want to lose buildcraft you can either revert to 1.5.1, find whatever mod BC is having conflicts with and drop it, or ideally google "fixing minecraft id conflict" or something of the nature and do it yourself. ID Resolver is a great mod and a great tool but it's main function is to save time and manual effort. It doesn't do anything super magical for the most part and it's not a bad idea for ALL minecraft players that want to use tons of mods to at least learn and understand minecraft ID conflicts.
You could *cough* *cough* also read the posts we've placed numerous times about this...
EDIT: Also, I agree, use spoiler tags, not code tags... you could use code tags WITHIN spoiler tags, but you NEED to use spoiler tags. (That should be made a rule for this thread/site, really. Some moderator, please get on that, perhaps?)
EntropySeattle, suggestion, when people ask questions that have been answered direct them to the answer (or to use the very, extremely, exceptionally wonderful "SEARCH" function this website has-nearly better than Google's "site:<website>" search). If the reference is enough pages back (say 3+) then just (right-click, copy URL, paste in textbox) the number in the upper left hand corner of the post and reply with that. It creates a direct link to the post so people can just click and be directed.
Why we should do this level of effort for people who clearly don't want to themselves? Simply because some of the things we are able to do on this site are not exactly evident unless told of or shown. (the 'search THIS thread' feature of the search engine, for example)
However I was curious and hoping that there would be a version of this for 1.5.2 in the works?
We don't know, we haven't heard from ShaRose in a while. I hope he's ok...
hmmm... agreed.
It kills me when I see people shouting about, "I can't fix this, do it for me!" without taking the time to understand. The lack of investigative and curious intelligence, that humans are naturally born with, is overwhelming...
/rant. Sorry
Ya...i did that before,be spent me much time,and easy to get error,this tool make everything work more easy,so I wish it can be update.
But some people do find that difficult. For some people things that are time consuming are 'difficult' by definition. For some people things that require learning to use a new tool are 'difficult' by definition. For some people the excessive number of times opening and closing Minecraft, getting a crash each time alone makes any process other than using ID Resolver 'difficult'.
I understand these people's plight. Java, by nature, is a developer's language and has many things keyed to making developer's lives easier. Exception throwing (and handling) is one of these things, but when improperly used they simply become... annoying... I don't know if the exception informing users of an ID conflict is something that Mojang coded or something from Java, but if it is Mojang code then it was severely miscoded. End users should never see exceptions-except, of course, in exceptional conditions-as exceptions should be caught and handled by the code that the developer writes.
Basically, what I'm saying is that if Mojang was aware of this-having added it-then they should have wrapped it around something akin to ID Resolver.
Yeah, the investigative and curious intelligence is what makes humans so great, but something you need to remember is that it isn't necessity that is the father of invention... it is laziness. While it is true that the causes all inventions could be said to be need... it is just as true, if not more so, that the causes of all inventions could be said to be laziness. Farming? Didn't want to travel to hunt or forage any more. Fire, same thing. Clothes, didn't want to migrate south when it got cold (or make fire). The wheel? Well, that's an easy one.
I do, however, agree that it is enraging when people whine and yell "Fix this for me, NOW!" rather than bother to do ANY of their own research. Something that is quite clearly evident in this thread or in EE3's.
No need to feel bad about ranting (you should see how often I do it-though I usually put mine is spoiler tags within talking about something else...) Speaking of that human intelligence... you could try making an ID Resolver... (Yes, so could I, but I'm perfectly content waiting back at 1.4.7 until the mod pack I use is updated... or at least until RedPower2 updates...)
phew, was thinking for a second I had to individually quote all all the paragraphs..
I understand what you mean about the difficulty. The one thing though is we are talking about mods that are outside of Mojangs original code being placed inside of it to manipulate it differently. I know there are a ton of threads about Mojangs base code being terribly inefficient etc., but these modders are only working with what they got. I feel lucky that those exceptions being thrown out are readable, to at least me and I would think many many others. While you are right, we should never see those, we are also lucky in a sense to see them as well. Especially since we are using things that are modifying parameters outside of the original code.
I guess what I am trying to say is yes, I see your point and I agree. It is also my laziness not to learn java and commit time to making another ID resolver. I could .. buuuuut... ya, I think I'll save that one for ShaRose since personally, I'm not having issues as of yet.
You're still in 1.4.7? What modpack is that? Is it the one that is waiting for Redpower which is gloriously on stand-still? That is the one mod I've always wanted but was always on a higher version that it was made for. I would wait and wait and wait, then my coremods would move on, and I'd say screw it. Then days later redpower would update lol.. Well, that's a conversation for another thread.
Take care
I'm using a modified version of Feed the Beast. THEY are still waiting for RedPower, and potentially waiting until 1.6. I think it is somewhat ironic that they have run into the same issue that Technic/Tekkit ran into with Equivilent Exchange (with the minor difference that EE2 will never be updated, RedPower will).