Vanilla in my modpack?

[flamebolt_r15]

Hello. I'm new to this whole modpack thing. Can u help me with this problem? It keeps going to vanilla for some reason. Thx.

https://dl.dropboxusercontent.com/s/t6b9wrfd09t3x4a/test.zip?dl=1&token_hash=AAG58Z155ac2SWWjAtHHzrVUKoZ7r43ToKY3uVGmEjfEmQ

[plowmanplow]

A few notes before I go through the pack itself:

• When trying to build a pack, especially for the first time, don't throw dozens of mods into your mods folder and hope they'll all work together. Start small with just a few core mods in your pack and once that is working well add mods in singly or in logical groups. Trying to debug a new pack without any existing configs and 60 mods can make the inexperienced throw their hands up in frustration.
• Only get your mods from the mod author's preferred distribution channels. This ensures that you have the most recent and/or correct versions and that you have the proper installation procedures. In the case of your pack I see a lot of mod files with all capital letters in their name and it just makes me suspicious that something might be up with them. Don't copy mods from other packs because you might miss dependencies on which a mod requires. In this case you seem to have copied Tropicraft from another mod because the download from the author has five other mods/dependencies inside.

Pack notes:

• You have an old version of Forge. Get the latest version (Build 965)
• Tropicraft is not installed correctly. Missing all dependencies.
• Galacticraft is not installed correctly. Missing MicdoodleCore dependency. Also, old version with known problems.
• Missing Universal Electricity mod, a dependency for CalclaviaCore+ICBM.
• Missing powercrystalsCore mod, a dependency for MineFactoryReloaded.
• You have duplicate mods of: OpenBlocks, OpenModsLib
• Your Calclavia mods (CalclaviaCore and ICBM) may not work together and/or with some other mods. Saw some odd crashes. Getting versions that all work correctly together for Calclavia's mods can be challenging.
• You have no config files in your pack. This is always bad and often fatal to the operation of a pack. Always include config files.

I highly recommend using something like my BareBonesPack ( http://www.technicpack.net/modpack/details/barebonespack.271497 ) to build up your pack the first time (and handy for maintenance/upgrades later). This will allow you to methodically build your pack as you go instead of having to constantly update your online download.

 

Okay, I'm heading out to dinner. You've got a fair amount of homework to do Good luck and come back here after you work through this if you are still having problems.

[flamebolt_r15]

I need help with the config. Should I just leave the configs blank or do I have to copy and paste from vanilla?

[Ti Ex Ex]

Depends whether or not you actually want to change something you'd find in the configs. If you want the mods to be as-is, you don't have to include any configs. If you do want to change a config option, I suggest you copy the config file from your regular Minecraft with that mod installed and modify it as you wish.

[plowmanplow]

@Ti Ex Ex: That is not correct. Modpacks without complete config folders should be considered faulty in all cases. When making a <=1.6.4 pack with more than just a few mods (and sometimes with only two) you run the risk of block/item/potion/enchantment/entity/biome/etc. ID conflicts which can only be resolved with proper config files. However, there are many other settings which almost always will need some tweaking to get the pack working "correctly". Configuring oregen/worldgen to balance your mods, configuring mod interactions with things like TreeCapitator, configuring power production interaction, resolving/enhancing recipe interaction and many more tweaks can and should be addressed using config files.

 

@flamebolt_r15: If you use my BareBonesPack and methodically build your pack that way you will see the config folder being filled with more config files as you add mods. The config folder and all of its contents are what you want to be including in your pack. The reason I suggest this way instead of just using your pack in the launcher to do this is because if your pack is crashing you might not get all the configs created if the startup process crashes before all the mods get loaded.

[Ti Ex Ex]

@PlowManPlow: When I wrote that, I didn't take in account that most modpacks were still made for 1.6, or that I forgot to say you should test them nonetheless.

 

Nevertheless, I would suggest you take the mods you wish to include in your modpack, put them into your regular Minecraft game and test it out. From there on, edit the configs in there, test it out again, and used the new config folder for your finished modpack.

Edited April 27, 2014 by Ti Ex Ex

[Ti Ex Ex]

Also, what would be the point of including the config files if everything already works as intended as-is? They are automatically generated anyways.

[plowmanplow]

@Ti Ex Ex: A few points:

• Using something like my BareBonesPack (or something similar you do yourself) is far superior to using a vanilla minecraft install on top of which you have installed forge. If you are intending to use the Platform to distribute your pack then use the Platform to create your pack. This is as true for making a modpack as it is for all other types of development efforts. Always, always develop in an environment as close to your intended production environment as possible. This will reduce the chance of unexpected problems creeping into your product. This is an industry standard practice and should be heeded in all things.
• In the past, when folks seem extremely disinclined to include configs, I have used 48pt. bold fonts and bright colors to say "A modpack without configs is a poor excuse for a modpack!" There is no negotiation or excuse for not including config files in your pack. Ever. For any reason. Period. In my previous response I stated very clearly why you would always want to include them. Here I'll expound on that by saying that there is practically no interaction between mods generating their default configs when they get created. So, for instance, if you have a mod that has features for IC2, BuildCraft, AppliedEnergistics and ThermalExpansion but has those disabled by default because the mod can't know if they are also installed during the initial creation of the config you will not be able to use those features. This is just one example from a legion of examples.
• On the side of a more personal request, please don't suggest that folks deviate from widely accepted best practices for building modpacks without a compelling reason. These best practices have been honed over thousands of posts and hundreds of custom modpacks. I relish the opportunity to refine these procedures when presented with a better way of doing things or when adapting to a change in the common underlying structure of the mods and platforms with which we work. Suggesting contradictory procedures to these best practices is welcome if accompanied by evidence and/or examples. This helps us all. Suggesting deviations for things which have a compelling body of evidence for staying the course is less helpful.
• Thank you for participating in the support dialog/narrative. The more folks who comment and offer assistance the more rich and diverse the community will become.

Edited April 27, 2014 by plowmanplow

[Ti Ex Ex]

Alright then. thanks for letting me know about these practises. Now I can understand.

[flamebolt_r15]

@plowmanplow-Am i missing something else? It's still loading on vanilla.

https://dl.dropboxusercontent.com/s/zwooppn7iocjtfc/test4.zip?dl=1&token_hash=AAFTweFv_Yjhc8fV8zo_J5AcOtxbh6yLLqwTvSfabxX-lA

[plowmanplow]

Unless I'm missing something obvious, that is a well formatted pack archive ZIP file and should load up correctly identified as Forge by the platform. Provide a link to your Technic pack page for additional help.

 

As for the pack:

• You are missing the AutoUtils library required by Chisel. Please note the second bullet point in my first response to you. The author clearly states that this is required.
• You are missing the LomLibCore library required by Equivalency. In addition, your version of Equivalency is very, very old.
• You are missing the iChunUtil library required by all of iChun's mods (specifically MobAmputation).
• You have mismatched versions of your OpenMods mods, specifically an extremely old version of OpenModsLib compared to the other mods.
• You are missing the bulk of the ChocolateQuest/BetterDungeons mod installation package, specifically the pack-root folder "Chocolate" and its contents.

Go back and read over the first two bullets from my first response to you in this thread. Every single one of these problems would never have occurred if you had followed that advice.

• You have block ID conflicts between QarryPlus, Pam's Harvest Craft and other mods which need to be resolved.
• You have many item ID conflicts between Railcraft and Witchery.

Edited April 27, 2014 by plowmanplow

[flamebolt_r15]

I'm having troubles with the config. There are id conflicts but I don't where the conflicts are happening. 

https://dl-web.dropbox.com/get/need%20help.zip?_subject_uid=292193548&w=AADypHMhU8h4eI6bGm1k9BrnNfRTAGNwib-Vq_ZIdRAHIA&dl=1

[plowmanplow]

The most recent link you provided (in Post #12 in this thread) is not valid.