plowmanplow

If there are multiple mods overloading the same vanilla classes it is possible that load order could make a difference.

It could definitely be a case of "hasn't happened yet", but if you are using Cauldron as your server it may be that Cauldron does some "fancy optimization magic" on the back-end which is catching this before it becomes a crash and silently ignoring it. If you are using the default Forge universal as your server I wouldn't think it would be doing anything different from the client so more likely a "not yet" issue. As an example, the OreSpawn mods does some "weird things" related to mob spawning and frequently conflicts with other mods resulting in fairly non-informative crash reports. However, I've come to notice that if I see a "Spawn24" packet reference in the crash report and OreSpawn is present, that is where the issue is. Removing OreSpawn always fixes the problem. That's not to say it is specifically OreSpawn's issue (is likely due to a conflict with another mod), but since I've seen that exact error on WIDELY varying packs I've started pointing the finger at OreSpawn.

Nope, that is the download URL for your modpack archive. I'm referring to the URL which you paste into the Launcher to add the pack.

The Tracker for the Launcher is the best place for issues with the Launcher: http://forums.technicpack.net/tracker/project-1-technic-launcher/

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.

We can't provide assistance without the API URL for your custom modpack.

Copy.com public share URLs must be appended with "?download=1" (without quotes). The top level folders in your modpack archive are named incorrectly. The folder names must all be lower case. You have the Mo' Creatures mod, but not the dependency mod CustomMobSpawner. You have the "dev" version of CodeChickenCore. Use the latest "universal" version. You are using an ancient version of AE2. You have other mods which are linked against AE2rv2 and should update to that.

Always provide the API URL of your custom modpack when requesting assistance. java.lang.NoSuchFieldError: itemRegistry at codechicken.core.featurehack.GameDataManipulator.replaceItem(GameDataManipulator.java:33) at codechicken.nei.api.ItemInfo.addMobSpawnerItem(ItemInfo.java:293) NEI is having troubles with the spawners of one or more of your mods. Once we have the API URL we should be able to provide more information.

java.lang.NullPointerException: Unexpected error at net.minecraft.client.network.NetHandlerPlayClient.func_147281_a(NetHandlerPlayClient.java:744) at net.minecraft.network.play.server.S0FPacketSpawnMob.func_148833_a(SourceFile:97) at net.minecraft.network.play.server.S0FPacketSpawnMob.func_148833_a(SourceFile:15) at net.minecraft.network.NetworkManager.func_74428_b(NetworkManager.java:212) at net.minecraft.client.multiplayer.PlayerControllerMP.func_78765_e(PlayerControllerMP.java:273) This error isn't very specific, and provides few clues as to which mod may be causing the problem. The first three lines indicate that there was a problem in the code which is sending mob spawn information (S0FPacket) from the server (which is built into SSP) and the client. Since there aren't any specific mods present in the exception, and the code locations are listing vanilla classes, the issue is likely to be that one of the mods adding mobs is doing so improperly and that the vanilla code is getting data which it does not expect, and therefor causing a crash. Which mod is it? With just that crash report it is impossible to say. You have SO many mods adding mobs that it will take some trial and error to isolate the source of the crash.

IDFixMinus is a tool. It is intended to help you resolve ID conflicts. If you remove it (after it does its magic) and still have conflicts, you'll need to fix them the old fashioned way:

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

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.

I'm not claiming to know all the right ways (far from it), but in this case it is improper to include anything in the /coremods/ folder as it does absolutely nothing and just bloats the pack size needlessly. If you place mods in there which are required for other mods to function, the pack won't work. As for IDFixMinus, it is intended to help you resolve conflicts, then to be removed. It should not be in a published pack, and should never ever be used in a pack which is destined to be used on an SMP server.

Please provide the modpack API URL.

You haven't installed the mod correctly. There is almost 48M of assets which need to be available for the mod to work. The mod author is packaging Last Days in a "non-standard" way. I can get the pack to launch by including part of what the author advises placing into the minecraft.jar file, but it won't start in single player. I believe the mod author is doing some "bad things" to actively prevent this. Short answer, take it up with the mod author.

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.

Just download the JAR and run that.

Server Pack: You have two copies of CoFHCore (one with (1) in the title). Duplicates are always bad, and I've already mentioned the (1) issue in a previous post to you. You still have CoFHLib in the /mods/ folder. As I previously mentioned, this does not belong. (It's still in your client pack as well... are you not heeding my advice?) Your Thaumcraft and ThaumicTinkerer still don't match. You really want to be using AE2rv2 and Chisel 2. Your BigReactors is out of date. Your Waila version is still woefully of date and doesn't match your other mods. None of the recommendations I made for your client pack have been fixed. Why are you asking for help again when you haven't addressed the previously noted issues?

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).

Forge for MC >= 1.6 does not use a /coremods/ folder in any way. All mods belong in or below the /mods/ folder. Your pack archive has a /test/ folder with 200M of unneeded files. Remove this folder. IDFixMinus should not be included in your modpack. It is intended to be used to assist in resolving ID conflicts, then removed. You need to be including Lexmanos' Legacy Java Fixer: http://www.technicpack.net/article/attention-modpack-authors.105 I am able to launch your pack with 2G allocated and using Java 8.

The modpack creator is altering a ton of default recipes using MineTweaker. The recipes for all the ComputerCraft blocks/items have been altered and it seems that is preventing the specialty Turtles from crafting properly. You will need to follow up with the modpack creator in order to resolve this. (or just remove the MineTweaker mod)

http://technicpack.net/article/attention-modpack-authors.105

It is impossible to do anything but guess unless/until you provide the modpack API URL.

Heh, I don't know if I'd say encyclopedic, but the changelog in the Jenkins server for TT does indicate when significant version changes happen ( http://jenkins.nekokittygames.com:8080/job/Thaumic%20Tinkerer/ ). I don't really have a program I use, but I do have a process which I recently published in the hopes that others might gain something from it: '?do=embed' frameborder='0' data-embedContent>>

[12:08:09] [main/INFO]: [codechicken.core.launch.DepLoader$DepLoadInst:scanDepInfo:510]: Failed to load dependencies.info from CoFHCore-[1.7.10]3.0.0B9-40 (1).jar as JSON [12:08:09] [main/INFO]: [java.lang.Throwable:printStackTrace:461]: java.util.zip.ZipException: error in opening zip file The mod should not have " (1)" in the file name. I've seen this cause issues before. Remove that. As far as the ZIP libraries differeing, hard to say. Might have to ask one of the admins in the IRC channel. The CoFHLib file is only for use by mod developers and should never be used in a modpack. Your ThaumCraft is out of date (specifically does not match your version of Thaumic Tinkerer). Your Waila version is out of date with known crashes/bugs.