Velotican said:



Seriously though, this looks like a major achievement getting all those mods to play nice with one another. Stuff that isn't FTB-compatible isn't really appropriate for me but as someone who's prepared a smaller-scale config pack myself I can appreciate how time consuming this stuff is to do. I guess my FTB-compatible config racket isn't threatened here.Seriously though, this looks like a major achievement getting all those mods to play nice with one another. Stuff that isn't FTB-compatible isn't really appropriate for me but as someone who's prepared a smaller-scale config pack myself I can appreciate how time consuming this stuff is to do. Click to expand...

This is kind of out dated at this point, honestly. On my current server, I've trimmed it down to about 114 mods, minus plugins for forestry. Soon, though, if I can get time, I'm going to add that, and quite a few other mods that have come out/been updated since.The reason why I don't like it to be "FTB-Compatible", is because, although the FTB team gets the mods to work together fine, the problem I find is that the IDs for all of the mods are thrown around like friggin candy, and they aren't in a set order. In this modpack, and in my new one(as far as I can help it at least) the IDs are in a nice little chunk together, so adding new mods is streamlined, and I don't have to check my master ID list to see if this ID and that ID are taken yet. The problem comes when not all mods allow you to change their item's/block's ID. At those points you can't help it. It makes it especially useful on a server because, since they're all in one big chunk, the mods have a less likely chance to automatically change their IDs if their originally set ID is already taken. Having that happen can generate different IDs for different people, so if someone updates a mod that I had updated on the server, the ID that it generates may not be the same on the server. Doing it this way ensures a set consistency that's worth my time in maintaining as a server admin.