plowmanplow

No, those folders get created by the mods when you start your client. If you were adding EXTRA hats, you might need that, but even then I'm not sure. If you look at the installation instructions for the mods they both say to basically just drop the mods into your "mods" folder.

Your archive is in RAR format. It must be in ZIP format for the launcher/platform/java to be able to use it. Your modpack.jar is named "Modpack.jar". This is bad. Make it all lower case for the filename. You aren't including any config files in your pack. This is "bad". Always include the config files. Your "ThermalExpansion.recipes" and "vanilla.recipes" files are in the wrong place. It goes in your config directory under "machinemuserecipes". See why you need to include config files? You have many mods which are slightly to very old with known lag/crash bugs in them. Your ChickenBones mods are out of date/mismatched and cannot load. You have duplicate Tubestuff mods. I would highly recommend Waila mod. In a pack with this many mods it is very helpful when searching NEI and trying to identify things in the world at large. Making these changes allowed me to start the pack with no conflicts being reported in the ForgeModLoader log.

Nine minutes between asking for a custom pack and bumping your own post? Patience much? <takes off grumpy hat> That's a pretty basic pack. Try adding my BareBonesPack (it's in the platform), selecting Forge 1.6.4 in the settings and dropping in the mods. There are few enough that you might get by without conflicts (or not many).

You should have exactly one file in your "bin" directory: modpack.jar You have a ton of other stuff in the top level of your archive that doesn't need to be there: cache, customnpcs, hats, jarmods, log files, IDConflicts.txt You are using an amazingly old version of Galacticraft with known bugs and crashing problems. Your problem with Resonant Induction is actually that you are using a number of Calclavia mods of widly varying versions. This won't work. They all rely on CalclaviaCore so you need to make sure you are using the correct version of the mods for the correct version of the core. Getting the latest versions of the mods worked, but you may need to resolve an ID conflict inside ICBM after upgrading that mod. Atomic Science is also very old. Mekanism is old. The newer version fixes many lag/crash bugs from the version you currently have. If you are including NEI and plugins while also including Mystcraft it would probably make sense to also include the Mystcraft NEI plugin. Fixing the things I mentioned above allowed the pack to start properly.

The pack download URL you have set in your pack settings seems to point at a file that requires you to log in to retreive. You need a direct, public download in order for the launcher to accept it when starting.

You might not have enough RAM allocated in the launcher, or your system is running out of memory altogether. Check your task manager while it seems to be hung up. If you have more than a gig of memory still free you can try bumping up the settings in the launcher. If you are hitting your max/physical you are maybe out of luck. Texture packs consume a LOT of memory.

I decided to go check my logs and such for my BTeam server. I have 3G allocated to the server process, but the reported usage seldom goes over 1.5G even with 7 or 8 people on. The CPU usage on the box rarely goes over 30% (60% of one core) and usually VERY low (I'm currently on by myself, bouncing around with teleport between everyone's bases and the CPU load isn't going over 5%). I have no mods disabled and am using MCPC+ build #243 with CoreProtect, GriefPrevention, BanItem, Pex and Essentials as the only plugins which might impact performance. For good or ill, here's my startup: /usr/local/java/bin/java -Xmx3072M -Xms3072M -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseNUMA -XX:+CMSParallelRemarkEnabled -XX:MaxGCPauseMillis=50 -XX:+UseAdaptiveGCBoundary -XX:-UseGCOverheadLimit -XX:+UseBiasedLocking -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 -XX:UseSSE=3 -XX:+UseLargePages -XX:+UseFastAccessorMethods -XX:+UseStringCache -XX:+UseCompressedOops -XX:+OptimizeStringConcat -XX:+AggressiveOpts -jar mcpcplus.jar nogui I haven't vetted those arguments in a LONG time so if they are suboptimal please don't hang me.

Sure, PM me if you want, but all the feedback will be here so that others can benefit from problems we might solve. I have no time or inclination to get worked up over "permissions".

It is important when requesting assistance here that you include a link to your pack so we can check out the details.

Without having a link to your pack to download to see what else is there to be requiring this dependency i think I might be stuck.

Be aware that there is an authentication exploit that exists in versions of MCPC+ below "SNAPSHOT-f534-L67" which permits anyone using a particular hacked client to connec to to your server as anyone they wish. It might still exist even in that version, but I don't think so and we haven't had problems since upgrading (although you might still want to require a secondary authentication plugin for mods/admins/etc. just to be sure).

@RadioactiveSheep: Any errors like that when starting a server which reference "render" are usually caused by having a mod in your server which is a client-only mod. Things like REIMinimap, DamageIndicators (although I don't think this one crashes because the author knows what he is doing), VoxelMap, CustomLANPorts, etc. are all client-only mods.

Renaming a mod to have a ".disabled" on the end effectively removes it from your build. Starting a server after this will remove ALL blocks/items which are provided by that mod from any chunks that get loaded in your world. This is permanent and irreversible short of doing a restore from backups. Proceed with caution.

Awww, shucks. Quoted a post from me but didn't include the reference to the poster. Heh, seriously, no worries. Glad you were able to get things resolved!

java.lang.NoClassDefFoundError: calclavia/lib/prefab/item/ItemBlockHolder You are either missing, or have the wrong version of, CalclaviaCore.

Your first crash log has a line right near the top: This implies that you have Galacticraft included but are maybe missing MicdoodleCore. Galacticraft consists of 3 mods. Galacticraft, GalacticraftPlanets and MicdoodleCore. Having NEI serverside is totally fine. You probably want that so you can more tightly control who has access to which features from the server.

I would be careful making recommendations like these. 4G can hold one person on a "large" map? Not at all. That doesn't even make any sense. The map could have a 100000 block world border, and if there is only one person on there will only be a few hundred chunks loaded total regardless of where they are (unless you are including chunk loaders and that is a totally different issue). I have servers that only allocate 3G of ram and with 15-20 people doing very active builds it usually uses only about 2G and sits at a solid 20 TPS. To be honest, the only thing I have every had that caued the TPS to drop (even on packs with 130+ mods and 10 active players) was (1) Complex or rapid worldgen and (2) someone spewing 10s of thousands of items onto the ground from misconfigured builds. As for the donation spiral, I may be in the minority here (I honestly have no idea) but the moment I log into a server and see anything about donations I just politely leave to go my merry way. I have 5 servers using different modpacks with 10s of concurrent players out of 100s who play and I couldn't imagine charging anyone for that. It is a hobby for me and I get a lot of enjoyment out of keeping it all up. I totally understand that not everyone has my expertise, resources or free time. I'm sure it costs me a little bit in electricity, but I already had the infrastructure in place to host it myself so that's what I do. I guess what I'm trying to say is "hobbies cost money" and "businesses make money". Both are excellent pursuits. Just make sure you know which one you want to be in before you start so that you stil have fun with it. Life's too short to do something for long that frustrates you.

Most mods will make their config files after they are started for the first time. If you look in your config folder and you don't see config files for most of your mods then you have never started the pack locally. Trying to distribute a modpack before you know it works well on your PC is a recipe for disaster and frustration. The config files provide a way for you to resolve ID conflicts and to better integrate mods with each other. If it isn't working locally we'll need more information. Use pastebin to provide the most recent ForgeModLoader log and crash log. Edit: I decided to take a look at it again since I had done so previously... I do not know where you got the Fossil & Archeology mod you have, but it looks like you have the extracted mod in your mods folder. This is (almost always) incorrect. Additionally, it crashes the client immediately so it "may" be for the wrong version of Forge/MC. Since there is no information in the mod folder I have no easy way of verifying that. However, The only working version of F&A I am aware of for 1.6.4 is the patched version that the Technic team worked up for AoTB. As I stated in the previous thread you started you still have a 1.5.1 version of ChocolateQuest instead of the current one for 1.6.4. In a clear testament to including config files in your pack, once I disabled that F&A mod/folder and upgraded ChocolateQuest I was able to get the pack up far enough that it notified me of ID conflicts. There are conflicts between ChocolateQuest, Natura and Biomes-O-Plenty with their default config files. Making two changes in each of the Natura and BOP configs allowed the pack to start up successfully. Just for giggles, I tried adding in the AoTB version of Fossils. After resolving a few item ID conflicts everything seemed fine, but I couldn't fly around to see if there were any dinos anywhere because of the next problem. You have some conflict/contention between two or more mods that do worldgen. You have biomes that are generating MASSIVE amounts of "floating" grass (grass/grass seed that isn't attached to dirt and is hovering above the ground). This is causing an amazing amount of client lag to the point where the game is unplayable. In order to assemble a pack where everything works one must do so in a methodical fashion. Don't just thrown a couple/few dozen mods together and expect them to work. Especially when dealing with mods that change world generation, putting them in one at a time and testing things to make sure it still is doing what you want/expect is vitally important. I suggest starting with my BareBonesPack (simple pack that only has Forge installed and lets you change settings to select which version of that you want to start with) and adding in mods, testing as you go.

It looks like you extracted the modpack.jar file in the bin folder. Don't do that. Just leave it as a jar file. You have mods in the coremods folder. Forge/MC 1.6.4 does not use a coremods folder. Everything goes in mods. And still, you have no config files in your pack. Always, always include configs for every single mod (that has one). No exceptions.

I am away from a PC at the moment, but optifine now installs just like any other forge mod. Just put the latest (Ultra 9?) version into your mods folder. Yes, it is that simple.

Your modpack link in your pack is not a "direct" download. It must be so in order for the launcher to recognize it. You have mods in the "coremods" folder. Forge/MC 1.6.4 does not use a coremods folder. Everything goes in "mods". Many (very many) of your mods seem like they are out of date. Might load into 1.6.4, but definitely newer versions exist. You aren't including any config files in your pack. In a pack with this many mods, that is most likely fatal.

Switch to using MCPC+ for 1.4.7 and get some Bukkit plugins. (like Essentials or CommandBook or AdminCMD)

It seems most people wish to be provided fish. They do not want to learn how to fish.

You have everything in your pack archive inside a subfolder called "Modpack". All the contents (bin, config, mods, etc.) need to be at the top level of the archive, not in a subfolder. It looks like you are trying to assemble a 1.6.4 pack, but are using the 1.4.7 version of Forge (6.6.2.534 to be specific). You will need the most recent 1.6.4 version of forge as your modpack.jar file (1.6.4_9.11.1.965). Also, I'm not sure where you got that modpack.jar, but it is not the base Forge universal. This may be intentional, but if it was not you might want to start from scratch when moving over to the latest 1.6.4 Forge. You have some mods in the "coremods" folder. Forge for 1.6.4 does not use a coremods folder. Everything goes into "mods". I do not think you have Millenaire installed correctly. You have ProjectZuluComplete and ProjectZuluCore. If you have Complete I don't think you need Core, although I could be wrong. You have mismatched versions of mods. As I mentioned previously, you seem to be assembling a 1.6.4 pack but you have included the Forge/MC 1.5.1 version of BetterDungeons/Chocolate Quest. It is vitally important that you use the correct version of the mod with the matching version of Forge/MC. In this case, the latest 1.6.4 version of the mod is 2.08. And last, but not least, you aren't including any config files with your pack. With a very small number of mods you can sometimes get away with this but it is still easy to run into conflicts. If you ever want to use this on a server then you MUST include configs because some mods will try to auto-assign IDs and you can't know that you have the same config as the server unless you include them in your pack archive. Making these changes allowed me to start your pack successfully with all of the mods you were trying to use except for Millenaire since I'm not messing with that.

From a system management perspective, unless you have some very specific/unique processing requirements (of which Forge/MC does not qualify) you should NEVER see active use of your swap space. For a desktop system, maybe. If you have dozens and dozens of things open you can only really "look" at a few things at once. The stuff that gets paged out may be a lot less important. On a server? Not so much. If you are paging things to swap (again with an exception being made for some very uncommon edge cases) you are going to have a bad time. In this case, say you do have 8G physical and 13G allocated by utilizing swap. Assuming you are running Windows, as soon as you go over 6.5G of ACTUAL memory usage by the JVM you are going to start swapping and having a very bad time. However, 13G would be enough to host dozens of people concurrently. If you only have a few people on at once then what is getting swapped is stuff that isn't being actively used. You would see MUCH better results by drastically reducing your alocation for the Forge/MC server process. I have had 15 people actively using a very complex, current modpack (~135 mods reported, mostly tech and worldgen) with the server only having a -Xmx3G with no problems. The only thing that ever drops the TPS is worldgen, and that's a common issue largely unrelated to memory usage.