Help With Custom Modpack

[Munkey_Boy]

I'm trying to create a custom modpack for my friends (link for technic launcher is this http://www.technicpack.net/api/modpack/modpack-for-my-friends), the modpack loads fine (hosted on dropbox https://www.dropbox.com/s/b3h7g19bccvdety/modpack.zip), however it opens minecraft 1.6.4 usually ends up not responding so closes and goes back to the technic launcher screen.

Many thanks for any help, 

 

Crash report (https://www.dropbox.com/s/jmb688yjz9dgs2b/crash-2014-05-29_12.17.31-client.txt)

[plowmanplow]

• You have included a version of Enchiridion for Forge/MC 1.7.2. Get the 1.6.4 version.
• You have not included a full, working set of config files with your modpack. Some packs can get away with this but larger packs, like yours, seldom do. In your case this is a fatal oversight. You have multiple block ID conflicts in the default configs which need to be resolved.

[Munkey_Boy]

Many thanks for the response, how would I get the config files when they arent in the modpack's rar or jar file?

[plowmanplow]

The config files get created when the mod launches for the first time. Once you have a working pack THEN include the whole config folder in your modpack archive.

[Munkey_Boy]

Ok many thanks! It is greatly appreciated, I shall go through generating each config file for each mod and then change the block and item id's, will the configs be made even if the modpack doesnt load properly?

[plowmanplow]

The way that a mod works internally with Forge and Minecraft is that Forge gets its classes injected into Minecraft providing an API on which the mods rely. The integration of mods into Forge requires an initialization process during which the configs get created (if the mod does that and a pox on the mods that dont!). So, yes, the config files get generated even if a mod fails that initialization process. However, since the integration of mods halts when there is a fatal error not ALL configs for all mods will get created until the pack successfully starts. This is why you need to be testing your pack locally, adding mods individually or in logical groups until you have a working local setup and THEN you build your modpack archive from there.

[Munkey_Boy]

Many thanks for all of your help, you've been excellent, hopefully this should fix it, many thanks.

P.S any tips on the renumbering of block and item ids?

[plowmanplow]

Start a SSP world and and open your inventory. Go to the NEI options (bottom left) and then Tools. Make sure you are set to dump all (used and unused) IDs and dump them. A CSV file will be created with all the IDs and associated data. Find an empty range and use that.

[Munkey_Boy]

How could I do that to find the conflictibg item and block ids when the pack won't open because of that?

[plowmanplow]

You would need to temporarily disable one of the mods that is conflicting and make the ID dump then figure out an empty range to use for the conflicts.

[Munkey_Boy]

Does the crash report show the conflicting mods or will I have to find these myself? Sorry for so many questions, I appreciate the help!

[plowmanplow]

No, you need to be looking in your ForgeModLoader client log in the top level of your modpack folder. Search for the word "CONFLICT" (without quotes). You will see the ID (possibly up-shifted by 256 if for an item) and the two conflicting mods.

[Munkey_Boy]

Is the block id limit still 256? And item id 32,000 something?

[Munkey_Boy]

Also can I do block ids if I start to run out like this 248:1

[plowmanplow]

Noooo, don't do "248:1" in the configs. They must be whole numbers.

 

Blocks intended for use in WorldGen need to be <=4095.

[Munkey_Boy]

Okay, many thanks, here i go hopefully all goes well.

[Munkey_Boy]

I believe ive got all the cobfigs and block ids sortef yet nothing has changed?

[plowmanplow]

If you changed block and item IDs in your configs and your FML client log is EXACLTY the same I would be extraordinarily surprised. However, since your modpack settings currently point at a modpack archive that doesn't exist I cannot be more helpful.

[Munkey_Boy]

Ok I shall look into it further, from the forge log it looked like orespawn was causing quite a few issues so I've removed it, I shall tru again.

[Munkey_Boy]

Ok I shall look into it further, from the forge log it looked like orespawn was causing quite a few issues so I've removed it, I shall tru again.

[Munkey_Boy]

This is my forge modloader log, the only unusual conflict i find is thermal expansion replacing it's own block? https://www.dropbox.com/s/pmbp0x6jpsmwt6z/ForgeModLoader-client-0.log

[plowmanplow]

From your FML Client log:

java.lang.IllegalArgumentException: Slot 1225 is already occupied by resonantinduction.core.resource.fluid.BlockFluidMaterial@ae8086 when adding resonantinduction.core.resource.fluid.BlockFluidMaterial@c676113

Your ResonantInduction.cfg has the same value (1225) for two different blocks.

[Munkey_Boy]

Thanks that was what I was trying to say, many thanks, is that the only problem now then?

[plowmanplow]

Heh, I am not sure. I try to impart the knowledge to find and fix these problems. Give it a shot and see if it:

1. Works
2. Has a "clean" ForgeModLoader client log. (no resolvable conflicts, no glaring errors)

[Munkey_Boy]

Ok once again thanks for all your help , I shall give it a spin tomorrow.