funny you mentioned this. it's the last item on my to-do list. i was running through my forge log looking for any nagging warnings (kinda like what iskandar is talking about with the multimc console) and i found some issues with forestry backpacks. looks to be a tedious job cleaning it up. :/
1.5.1 Beta Pack-DIY Edition (now with 1.5.2)
- Thread starter Bagman817
- Start date
found an invaluable tool for those creating DIY packs. wish i had found this sooner!
so this is a nifty little perl script that finds id conflicts for you. it is NOT a minecraft mod. it runs outside of minecraft. while you do need to install perl for it to work, that's a small price to pay. you can grab perl by googling either "active perl" or "strawberry perl" and if you're on windows i (personally) would go with strawberry perl.
anyway, here's the original dev's thread. kudos to oldfarmerjoe for such a useful script! http://www.mmo-champion.com/threads/1243693-Minecraft-Item-Id-Reporter-Program
one last thing to note, the script does generate a few false positives now and again. this is because of the lack of consistency/standardization in formatting from config to config. it still does one helluva good job though!
so this is a nifty little perl script that finds id conflicts for you. it is NOT a minecraft mod. it runs outside of minecraft. while you do need to install perl for it to work, that's a small price to pay. you can grab perl by googling either "active perl" or "strawberry perl" and if you're on windows i (personally) would go with strawberry perl.
anyway, here's the original dev's thread. kudos to oldfarmerjoe for such a useful script! http://www.mmo-champion.com/threads/1243693-Minecraft-Item-Id-Reporter-Program
one last thing to note, the script does generate a few false positives now and again. this is because of the lack of consistency/standardization in formatting from config to config. it still does one helluva good job though!
This is an amazing find. Your timing couldn't have been better either! I was just finishing up downloading and installing all the mods for my 1.5.2 custom pack and the script you linked to just found about 14 Item ID conflicts I hadn't noticed. Fantastic!
Mandatory? Probably not. It's just my habit, and it's only 1 button press, so why not?
It just redownloads some Forge folders, which on my campus's internet, take a heck of a long time
NOTE: The latest version of CodeChickenCore is incompatible with Forge versions 690 and up.
689 is the latest you can use.
Dammit. Just given up my 1.5 pack.
To many compromises to make just to get it up and running. How do you guys do it!
NOTE: The latest version of CodeChickenCore is incompatible with Forge versions 690 and up.
689 is the latest you can use.
Dammit. Just given up my 1.5 pack.
To many compromises to make just to get it up and running. How do you guys do it!
By the way:
Resonant Rise 0.7.2 modlist: https://s3.amazonaws.com/resonant-rise/0.7.2/modlist.txt
Config Snapshot: https://s3.amazonaws.com/resonant-rise/0.7.2/configs.zip
Be careful if you upgrade past where we are. We've had more than a few bad builds. 0.7.2 is probably the most stable we've ever been, with only a few client crashes.
Resonant Rise 0.7.2 modlist: https://s3.amazonaws.com/resonant-rise/0.7.2/modlist.txt
Config Snapshot: https://s3.amazonaws.com/resonant-rise/0.7.2/configs.zip
Be careful if you upgrade past where we are. We've had more than a few bad builds. 0.7.2 is probably the most stable we've ever been, with only a few client crashes.
Well I've managed to put together a 1.5.1 mod pack with about 69 mods, haven't run into any problems post config prep although I didn't give the config too much of my time considering I was just too eager to finally getting to play. Few mods left out, such as Mystcraft, never really find myself exploring dimensions nor can my laptop handle it. I should mention however that I've noted some decline in fps overall. Could be the giant Natura tree I've decided to call home.
http://pastebin.com/v2xCxnFV
http://pastebin.com/v2xCxnFV
Sometimes MystCraft can be a positive for FPS and CPU Usage, for instance a Void Age for your power generation and item processing.
Don't expect that all the problems it finds are really ID conflicts. Problem especially with ItemIDs is that some mods take the from the config and shift it by 255(id+255) and some do not and take the ID which was given. The script might not know that and will then report an error where there is none actually.
Almost all of the trouble I keep running across are ItemID conflicts that are NOT showing up as 'stop errors'. (Often when you get an ItemID conflict between two mods, the game halts during startup and TELLS YOU.) I've been having tons of random crashes when I use certain items and tracking down the crashes so far have lead to item after item and block after block that share ID #'s! ARGH! If I try to use ID Resolver than dozens and dozens of items lose their textures and look like blank slots in inventory. Trying to USE the items like this usually results in a total crash.
It is getting absolutely maddening, I really do wish there was a stand alone application that you could point at your CONFIG folder and it would visually SHOW YOU which ID #'s have overlaps and which ID #'s are available to use. AUGH!
It is getting absolutely maddening, I really do wish there was a stand alone application that you could point at your CONFIG folder and it would visually SHOW YOU which ID #'s have overlaps and which ID #'s are available to use. AUGH!
Read your log. Learn to use Grep or Find-in-document. Every single time there is a conflict in item ids it is reported here with the word CONFLICT.
Also, don't rely on the "console" window in multimc. Make sure you are actually using the forge log file. It contains much more information than the console.
For those having Forge x CodeChickenCore issues, there is an unauthorized fix on the minecraftforums.net site. Seems to work for me. I'm sure CB will make a quick fix for this, but in the meantime, this should allow you to continue config'g your 1.5.2 modpack.
Regarding Item and Block ID conflicts, I prefer to assign ranges to each mod. It doesn't take nearly as long as you might think, especially when you compare it to the trial & error method.
Regarding Item and Block ID conflicts, I prefer to assign ranges to each mod. It doesn't take nearly as long as you might think, especially when you compare it to the trial & error method.
Another option is to roll back your forge version to 689 (unless a mod you use requires something newer) 690 is where they added the stencil buffer change that causes the CodeChickenCore crash.For those having Forge x CodeChickenCore issues, there is an unauthorized fix on the minecraftforums.net site. Seems to work for me. I'm sure CB will make a quick fix for this, but in the meantime, this should allow you to continue config'g your 1.5.2 modpack.
Regarding Item and Block ID conflicts, I prefer to assign ranges to each mod. It doesn't take nearly as long as you might think, especially when you compare it to the trial & error method.
The problem isn't finding the conflict, it is the fact that I don't know about it until it causes a crash. I can find a conflict, sure that is pretty easy once you know about it. The current issue I keep running across however is that it doesn't even get listed in the log files until I attempt to use an item with a conflicted ID and it crashes the game session out. I'll dig out the log, do a search and fix the ID issues that it produces, then restart and the game will run fine for a few hours. Then BANG another crash, and I have to repeat.
Really hunting down the conflicts isn't even half the aggrivation.. it is going through and having to read all the 'already reserved' ID #'s, trying to figure out a free number somewhere that isn't too high (as I then start getting "ItemID Out of Bounds" errors).
In general, item ID conflicts should appear in your log once your map is loaded before you build stuff.
Suppose I should throw this tool I've been working on a for while out there:
https://github.com/agaricusb/ModAnalyzer
It may be somewhat more difficult to setup (requires Python, but if you've setup Forge for development you already have Python) and to use, but its design has some interesting advantages.
Basically, it works by first analyzing each mod in isolation. You place all the mods you want to use in the "allmods" directory, run the modanalyzer script, then it quickly iterates over each, runs a temporary Minecraft instance, and injects an analyzer mod to dump the "contents" of the mod under analysis.
Then you can run modlist, and it will show you a list of all the contents of all the mods, per identifier. This includes not only the usual blocks and item IDs, but also biomes, enchantments, and even crafting recipes (first tool I'm aware of to identify these other types of conflicts, though hopefully not the last). You can import this list into a spreadsheet to see all of the assigned IDs and then move them around by hand if you'd like.
Haven't seen the item reporter Perl script before, though it does look quite nifty, this is a possible real problem:
However I've also included an experimental automatic resolution script. Run modresolve, then it'll edit the configs picking the next free IDs, trying to resolve the conflicts. Not all conflicts can be resolved automatically, since some mods have unrecognizable config file formats. But I do handle the aforementioned case of "unshifted" (or "shifted", I always forget which is which) IDs in the config file, by special-casing mods with this behavior:
So in summary, MA can be a great help in getting tons of mods to play nice together. I've been personally using it for a while now (about a month), though mainly for the analysis and config generation rather than automatic resolution, so I can assign IDs in contiguous ranges (MA does support matching IDs from existing configs using NEI item dumps, but it is not 100% since some modders change their item names between versions so they can't be reliably matched up). Got tired of the whole "load up all your mods, wait forever, watch it crash and burn, fix and repeat" brute-force trial-and-error approach, wanted to make something easier; not perfect but this is what I've came up with. Also unlike IDResolver it doesn't load while you're playing the game so it should avoid some of the compatibility problems mentioned above.
With the help of ModAnalyzer I was able to get 100+ mods to work together without much effort. Hopefully someone else will find it useful as I have.
https://github.com/agaricusb/ModAnalyzer
It may be somewhat more difficult to setup (requires Python, but if you've setup Forge for development you already have Python) and to use, but its design has some interesting advantages.
Basically, it works by first analyzing each mod in isolation. You place all the mods you want to use in the "allmods" directory, run the modanalyzer script, then it quickly iterates over each, runs a temporary Minecraft instance, and injects an analyzer mod to dump the "contents" of the mod under analysis.
Then you can run modlist, and it will show you a list of all the contents of all the mods, per identifier. This includes not only the usual blocks and item IDs, but also biomes, enchantments, and even crafting recipes (first tool I'm aware of to identify these other types of conflicts, though hopefully not the last). You can import this list into a spreadsheet to see all of the assigned IDs and then move them around by hand if you'd like.
Haven't seen the item reporter Perl script before, though it does look quite nifty, this is a possible real problem:
In contrast since ModAnalyzer dynamically analyzes the mods, starting them up and then dumping their IDs after they've loaded, it guarantees you'll get the real IDs. It will even dump IDs not in the configuration files (some mods do not offer configurable item IDs, for example, so conflicts can be cumbersome to identify and resolve otherwise). Not Enough Items' ID dumps can also be used for a similar purpose, but ModAnalyzer is fully automated.
MA can automate this tedious task for you. In addition to saving a 'mod analysis dump', it'll also stashes the defaults configs for each mod. Usually I take the default config, check it into version control, then make my conflict resolution changes.
However I've also included an experimental automatic resolution script. Run modresolve, then it'll edit the configs picking the next free IDs, trying to resolve the conflicts. Not all conflicts can be resolved automatically, since some mods have unrecognizable config file formats. But I do handle the aforementioned case of "unshifted" (or "shifted", I always forget which is which) IDs in the config file, by special-casing mods with this behavior:
If anyone knows of any other mods to list here, let me know or better yet feel free to submit a pull request to ModAnalyzer on GitHub. I've had to add a fair amount of mod-specific compatibility since some mods have errors in their mcmod.info which prevent proper analysis or otherwise require special handling. But all in all, it works fairly well in my experience.
So in summary, MA can be a great help in getting tons of mods to play nice together. I've been personally using it for a while now (about a month), though mainly for the analysis and config generation rather than automatic resolution, so I can assign IDs in contiguous ranges (MA does support matching IDs from existing configs using NEI item dumps, but it is not 100% since some modders change their item names between versions so they can't be reliably matched up). Got tired of the whole "load up all your mods, wait forever, watch it crash and burn, fix and repeat" brute-force trial-and-error approach, wanted to make something easier; not perfect but this is what I've came up with. Also unlike IDResolver it doesn't load while you're playing the game so it should avoid some of the compatibility problems mentioned above.
With the help of ModAnalyzer I was able to get 100+ mods to work together without much effort. Hopefully someone else will find it useful as I have.