plowmanplow

Your modpack archive is in RAR format. All archive files intended for use in the platform must be in ZIP format only. Many of your mods are out of date with known crash bugs and stability issues.

Ahh, yes. If you include the world save in your modpack archive it will most definitely "clobber" the local user's save and anything they have changed. There are a few ways you could distribute the world save in a non-destructive way:
Zip up the "starting" world into an archive in the /saves/ folder. Clients can extract that ZIP to the /saves/ folder the first time they want to start the world and then if you change the ZIP file later it won't overwrite their active save. This would be a close second to the last option if you don't want users to have to download extra files. Instruct users to change the folder name of the world save before they launch the pack for the first time. This is likely to cause issues/frustration for the "less informed" among your user-base. Distribute the world save as an additional download. This would be my first choice.

I applaud your efforts to provide a consistent, uninterrupted game play experience to your users. That desire will serve you well over time.
 
As for the updates, as long as you stay within the same version of MC (1.7.10) you'll almost never have an issue. All of the mods I mentioned will update without any impact on world saves which players have created. For things like Thaumcraft and ThaumicTinkerer not matching, this WILL cause your world to crash eventually. The version of TT you have has implemented features that don't work with the version of Thaum you have. If someone attempts to make certain TT items and gets them into their inventory, the client will crash. Same issue with any mods with provide Waila integration. There was a significant API change in Waila after the version you are using which most other mods have included. This will cause issues if you don't update.

Yes, the user in question should update to the latest Java 8. This may require installing the Java 8 JDK instead of the JRE.

You have to have versions that match. CoFHCore is a dependency library. All the mods which link against it must match versions. Those are all listed on the page I provided.

Your CoFHCore is out of date. Update to the most recent CoFH mods (that you are using): http://teamcofh.com/downloads/ Your IC2 mod is out of date and not from the author: http://ic2api.player.to:8080/job/IC2_experimental/ After fixing these issues I was able to launch your pack and start a SSP world (Java 8).

I do a fair amount of modpack testing and debugging, typically in threads posted to this forum. I thought I could demystify the process by sharing some of the steps and tools I use during an evaulation.
 
Testing Environment for Monolithic packs:
I keep a "custompacks" folder on one of my drives and made a link to it in Windows Explorer's Favorites to make it easy to navigate into. When someone requests assistance with a pack I copy their API URL (this is why I always ask for it) and paste it into a custom page I maintain for displaying pack metadata (feel free to use it or see what yours looks like: http://www.circlecraft.info/platform ). If the pack download link is valid I save it to custompacks in a subfolder titled as the username of the person requesting assistance. I name the ZIP file the same as the platform (i.e. slug-version.zip). Keeping the version in the filename is important because it permits me to notice when someone is changing their pack contents but not the version number. I then look through the pack to make sure everything looks "normal". Does the pack have the correct modpack.jar file (version, name, contents, etc.)? Does the pack have config files? Are the mods named "correctly" (not renamed, don't look like they came from content scraping sites, etc.)? Do the well known standards (ChickenBones, CoFH, Immibis', etc.) have all their dependencies? Are the mod versions current? I use my BareBonesPack (BBP) ( http://www.technicpack.net/modpack/barebonespack.271497 ) for testing monolithic modpacks (packs which are one big ZIP file download). This allows me to easily deploy a base platform for testing which I know has a working Forge environment. For a new test I will reset the BBP (using this script: http://www.circlecraft.info/bbp/ ) and select the correct version of Forge. I will then copy in the pack's required folders (config, mods, etc.). I then try to launch the BBP. If the pack crashes I will look at the crash report and ForgeModLoader logs (FML logs are in the root folder of the pack for MC <= 1.6.4 and in the /logs/ subfolder for MC >= 1.7.2) to get an idea about what may be causing the crash. This is sometimes quite clear (missing dependency mods, ID conflicts) but sometimes requires reading through Java errors/exceptions. Unless there are dozens of block ID conflicts, or the mods folder is a hot steaming mess I will usually do what is required to get the pack started (update mods, fix dependencies, fix conflicts, etc.) so I can report on that. If the pack launches successfully the first step is to go through the entire FML log and look for glaring issues. Things like mods which completely fail to load (errors reported), item ID conflicts (if MC <= 1.6.4), errors other than missing textures and failures to contact update checkers. I will then try to create an SSP world with the correct world type (like Biomes O' Plenty, etc.) and do some quick checks. Does NEI/Waila/etc. show up? Are there any obviously missing item textures (look through NEI pages)? Do the cornerstone mods allow block placement? Can I successfully change dimensions? Does the pack use an expected amount of RAM/CPU? At this point I will usually write up my findings. Many of you have probably seen them, but here's an example: Testing Environment for Solder packs:
It is usually easiest to just add packs to my Launcher when they are managed by Solder. However, I do look around a bit first. My Platform metadata page will provide a link to the direct API URL for the Solder modpack. I will follow this to make sure that things look "normal". I will append the latest version number (i.e. if the latest version is 3.2 I would append "/3.2" without quotes) and make sure that a full mod list shows up. I will usually hit one of the direct mod URLs to make sure the web server is feeding things correctly. Once the pack finishes installing to the Launcher I will examine the pack folder to ensure all the folders look correct (that the modpack.jar in /bin/ is correct, that the config files exist, that the contents of the /cache/modname-version.zip look correct) and perform most of the steps from the Monolithic section above. If everything looks good I will attemp to launch the pack. The analysis steps from here on mirror those from the Monolithic section above except that I would be working in the current pack's folder instead of inside the BBP. Testing Environment for Servers:
The first step for server assistance requests is always to do an analysis of the client modpack. If the above steps yield a fully working pack I will continue with the server. I keep a Servers folder in my custompacks folder with pre-built servers (both Forge and MCPC+/Cauldron) for all versions of MC. I will make a new folder for the test server, copy in the required top level folders from the pack (/config, /mods, etc.) then copy in one of these pre-built servers. I then make a new folder in the server folder called client_only and move all the client only mods (minimap, visual animations, etc.) from the server's /mods/ folder. Which mods these are is mostly learned by research and trial/error. However, most (decent) mod authors will state that their mods are client only when relevant (like Damage Indicators). I then launch the server using the Forge JAR as the base. If it starts correctly I will then connect from the client and verify that things are working as expected. If the person requesting assistance has provided crash reports or a test which makes the server crash I will attempt to duplicate that and analyze the results if it does indeed crash. Once everything is working as expected I will report my findings about the client pack, which client only mods must be removed from the server (sometimes mods should work in SMP but don't because they are poorly coded), and any other "gotchas" required to get the server up and running.

Your Tinker's Construct and Mantle mods are extremely out of date. Rei Minimap, to my knowledge, has no published versions for 1.7.10. It is conflicting with one or more mods in the pack. Switching to Litemod and VoxelMap_litemod seems to work, even after adding Extra Utilities.

Why is eyemod named "eyemod-EyeOS4.2-1.7.10.jar.zip". You should remove the .zip at the end. Your ChickenBones' mods (NEI) are not from the author and you are missing the dependency library CodeChickenCore mod: http://chickenbones.net/Pages/links.html Your IC2 version is woefully out of date: http://ic2api.player.to:8080/job/IC2_experimental/ You have Extra Cells but not the dependency mod Applied Energistics 2 rv2-beta: http://ae2.ae-mod.info/Downloads/ You have Morph mod but not the dependency mod iChunUtil: http://ichun.us/mods/ichunutil/ You have OpenPeripheral but not the dependency mod ComputerCraft (Open Peripheral is useless without it anyway): http://www.computercraft.info/ You have Tinker's Construct but not the dependency mod Mantle: http://www.curse.com/mc-mods/minecraft/mantle/2215235 Your version of VoltzEngine does not match your version of ICBM. Get the latest versions here: http://builtbroken.com/project.php You should not be using Too Many Items and Not Enough Items at the same time. Pick one, remove the other. One of your mods is generating an error indicating that it's not for the version of Forge you have installed (older/newer MC version). I'm not going to go through every one of your mods. I'll leave you to do that. Way too many of your mods are simply named "ModName-1.7.10.jar". This strongly implies that you aren't getting all your mods directly from the mod authors (since almost no one names their mods that way) and is likely the reason you have an outdated/mismatched mod installed. You need to be more careful about where you get your mods from, and in following the mod author's installation instructions. You have so many mods without their required dependencies or libraries, every one of which is specifically mentioned as required by the authors.

@heyhow123: Start a new thread with relevant details about your issue. Don't hijack someone else's thread.

No links, no crash reports, no server or FML logs, no modpack links, no API URLs. How are we supposed to help? My magic 8-ball is all messed up

Why is eyemod named "eyemod-EyeOS4.2-1.7.10.jar.zip". You should remove the .zip at the end. Your ChickenBones' mods (NEI) are not from the author and you are missing the dependency library CodeChickenCore mod: http://chickenbones.net/Pages/links.html Your IC2 version is woefully out of date: http://ic2api.player.to:8080/job/IC2_experimental/ You have Extra Cells but not the dependency mod Applied Energistics 2 rv2-beta: http://ae2.ae-mod.info/Downloads/ You have Morph mod but not the dependency mod iChunUtil: http://ichun.us/mods/ichunutil/ You have OpenPeripheral but not the dependency mod ComputerCraft (Open Peripheral is useless without it anyway): http://www.computercraft.info/ You have Tinker's Construct but not the dependency mod Mantle: http://www.curse.com/mc-mods/minecraft/mantle/2215235 Your version of VoltzEngine does not match your version of ICBM. Get the latest versions here: http://builtbroken.com/project.php You should not be using Too Many Items and Not Enough Items at the same time. Pick one, remove the other. One of your mods is generating an error indicating that it's not for the version of Forge you have installed (older/newer MC version). I'm not going to go through every one of your mods. I'll leave you to do that. Way too many of your mods are simply named "ModName-1.7.10.jar". This strongly implies that you aren't getting all your mods directly from the mod authors (since almost no one names their mods that way) and is likely the reason you have an outdated/mismatched mod installed. You need to be more careful about where you get your mods from, and in following the mod author's installation instructions. You have so many mods without their required dependencies or libraries, every one of which is specifically mentioned as required by the authors.

@heyhow123: Start a new thread with relevant details about your issue. Don't hijack someone else's thread.

I do a fair amount of modpack testing and debugging, typically in threads posted to this forum. I thought I could demystify the process by sharing some of the steps and tools I use during an evaulation.
 
Testing Environment for Monolithic packs:
I keep a "custompacks" folder on one of my drives and made a link to it in Windows Explorer's Favorites to make it easy to navigate into. When someone requests assistance with a pack I copy their API URL (this is why I always ask for it) and paste it into a custom page I maintain for displaying pack metadata (feel free to use it or see what yours looks like: http://www.circlecraft.info/platform ). If the pack download link is valid I save it to custompacks in a subfolder titled as the username of the person requesting assistance. I name the ZIP file the same as the platform (i.e. slug-version.zip). Keeping the version in the filename is important because it permits me to notice when someone is changing their pack contents but not the version number. I then look through the pack to make sure everything looks "normal". Does the pack have the correct modpack.jar file (version, name, contents, etc.)? Does the pack have config files? Are the mods named "correctly" (not renamed, don't look like they came from content scraping sites, etc.)? Do the well known standards (ChickenBones, CoFH, Immibis', etc.) have all their dependencies? Are the mod versions current? I use my BareBonesPack (BBP) ( http://www.technicpack.net/modpack/barebonespack.271497 ) for testing monolithic modpacks (packs which are one big ZIP file download). This allows me to easily deploy a base platform for testing which I know has a working Forge environment. For a new test I will reset the BBP (using this script: http://www.circlecraft.info/bbp/ ) and select the correct version of Forge. I will then copy in the pack's required folders (config, mods, etc.). I then try to launch the BBP. If the pack crashes I will look at the crash report and ForgeModLoader logs (FML logs are in the root folder of the pack for MC <= 1.6.4 and in the /logs/ subfolder for MC >= 1.7.2) to get an idea about what may be causing the crash. This is sometimes quite clear (missing dependency mods, ID conflicts) but sometimes requires reading through Java errors/exceptions. Unless there are dozens of block ID conflicts, or the mods folder is a hot steaming mess I will usually do what is required to get the pack started (update mods, fix dependencies, fix conflicts, etc.) so I can report on that. If the pack launches successfully the first step is to go through the entire FML log and look for glaring issues. Things like mods which completely fail to load (errors reported), item ID conflicts (if MC <= 1.6.4), errors other than missing textures and failures to contact update checkers. I will then try to create an SSP world with the correct world type (like Biomes O' Plenty, etc.) and do some quick checks. Does NEI/Waila/etc. show up? Are there any obviously missing item textures (look through NEI pages)? Do the cornerstone mods allow block placement? Can I successfully change dimensions? Does the pack use an expected amount of RAM/CPU? At this point I will usually write up my findings. Many of you have probably seen them, but here's an example: Testing Environment for Solder packs:
It is usually easiest to just add packs to my Launcher when they are managed by Solder. However, I do look around a bit first. My Platform metadata page will provide a link to the direct API URL for the Solder modpack. I will follow this to make sure that things look "normal". I will append the latest version number (i.e. if the latest version is 3.2 I would append "/3.2" without quotes) and make sure that a full mod list shows up. I will usually hit one of the direct mod URLs to make sure the web server is feeding things correctly. Once the pack finishes installing to the Launcher I will examine the pack folder to ensure all the folders look correct (that the modpack.jar in /bin/ is correct, that the config files exist, that the contents of the /cache/modname-version.zip look correct) and perform most of the steps from the Monolithic section above. If everything looks good I will attemp to launch the pack. The analysis steps from here on mirror those from the Monolithic section above except that I would be working in the current pack's folder instead of inside the BBP. Testing Environment for Servers:
The first step for server assistance requests is always to do an analysis of the client modpack. If the above steps yield a fully working pack I will continue with the server. I keep a Servers folder in my custompacks folder with pre-built servers (both Forge and MCPC+/Cauldron) for all versions of MC. I will make a new folder for the test server, copy in the required top level folders from the pack (/config, /mods, etc.) then copy in one of these pre-built servers. I then make a new folder in the server folder called client_only and move all the client only mods (minimap, visual animations, etc.) from the server's /mods/ folder. Which mods these are is mostly learned by research and trial/error. However, most (decent) mod authors will state that their mods are client only when relevant (like Damage Indicators). I then launch the server using the Forge JAR as the base. If it starts correctly I will then connect from the client and verify that things are working as expected. If the person requesting assistance has provided crash reports or a test which makes the server crash I will attempt to duplicate that and analyze the results if it does indeed crash. Once everything is working as expected I will report my findings about the client pack, which client only mods must be removed from the server (sometimes mods should work in SMP but don't because they are poorly coded), and any other "gotchas" required to get the server up and running.

Does this post strike you as helpful for troubleshooting?

For Forge/MC <= 1.6.4: Modify the version.json file inside the modpack.jar to include the correct references to download LiteLoader at run time. My BareBonesPack includes a 1.6.4 version with this already completed ( 1.6.4 LL): http://www.technicpack.net/modpack/barebonespack.271497
For Forge/MC >= 1.7.2: The LiteLoader JAR file (the mod, not the installer) is simply placed into the /mods/1.7.2 or /mods/1.7.10 folder. That's it.

You have included too many things in your modpack archive. Your modpack archive should only contain the folders: /bin/, /config/, /Flan/, /mods/. The extra, unneeded folders and files are bloating your pack by over 200M. Forge for 1.7.2 requires the use of Lexmanos' legacy java fixer. See this post: http://technicpack.net/article/attention-modpack-authors.105 Your Custom Music Discs mod is out of date. The current version for 1.7.2/1.7.10 is v1.6. http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1294939-custom-music-discs-v1-6 After correcting these issues I was able to start the pack.

Copy.com direct links need to have "?download=1" (without quotes) appended to them to work properly in the platform. The legacyfixer-1.0.jar is only needed for Forge 1.7.10 < #1230. You can and should remove it. iChunUtil is the incorrect JAR file. You shouldn't be using the "deobf" (deobfuscated) version of the mod. As of this post, the site isn't working so I can't get the latest, correct version. Disabling it and Hats allows the pack to start after fixing Calclavia's mods. Have caution when including mods with "(1)" (caused by downloading a duplicate file to the same folder) in the name. Believe it or not, this sometimes causes issues. Why are you including Resonant Engine and Universal electricity? None of the mods you have installed require them. Also, Your Resonant Engine is amazingly old. The current version doesn't require Universal Electricity as a dependency.

Please provide the API URL or modpack page link.

Please always use a pastebin (like http://pastebin.com ) service for logs instead of pasting them into the thread.
[07:13:25] [Client thread/ERROR]: The mod statues (Statues) requires mods [asielib] to be available Asie's 1.7.10 port of Statues mod requires asielib dependency mod: http://mc.shinonome.ch/doku.php?id=wiki:statues

Here's some info on where and how to get your mods:
 
Here's some info on using my BareBonesPack to build a custom modpack for the platform:
 
Here's some general info on the overall process:

Here's some info on where and how to get your mods:
 
Here's some info on using my BareBonesPack to build a custom modpack for the platform:
 
Here's some general info on the overall process:

What now? As previously mentioned, you go through every mod in your pack and make sure that:
each mod is the latest compatible version each mod is downloaded directly from the mod author's preferred distribution channels For mods that aren't cornerstone, "big name" mods make sure that you take a look at what folks are saying or complaining about. If a mod has a ton of folks complaining about instability or incompatibility with other mods you might want to steer clear. At this point I would normally bring the pack up in my test environment, but there are so many outdated mods with known critical issues in your pack that it's not reasonable to do that at this time.

Ahh. No, I do not think any of the default Technic packs are officially up to 1.7.10. That should be coming long soon (Hexxit is first I think).

You are missing the javalegacyfixer-1.0.jar in your server's /mods/ folder.