plowmanplow

I'm not really sure what you are doing. If I load your pack, remove the ResonantInduction.cfg and run the pack it makes one that works just fine.

Your modpack.jar is now named "modpack.jar.jar". This won't work. It must be named "modpack.jar".

Calclavia Core: http://calclavia.com/calclavia-core/

I won't get into anything specific to Ultra Modded Survival pack (that's up to the pack authors), but if you provide a crash report and a Forge Mod Loader client log I'll see if anything obvious is going on.

This probably belongs in Platform Pagoda. In order for clients to recognize that an update has happened: The version number must be changed (incremented is usually best, but not required) The Launcher must be restarted.

Not any more. I test so many modpacks that my BareBonesPack gets cleaned out as soon as I move on to another pack to test. Just go through the same procedures you have been doing so far. If you get stuck make sure your hosted pack is up to date and I'll take another look.

You have included the cache folder in your modpack which has an entire copy of your pack inside of it. This makes your modpack well over 400M. This desperately needs to be removed and may be causing problems. Your modpack archive should have only the following folders in it. Removing all other folders: bin, config, mods Do these things, update your pack settings with the new download (if necessary) and let me know. I'll take another look then. Edit: After manually downloading your (giant) pack and setting up a test environment you have 14 block ID conflicts. Might want to address those at the same time you are working on the two points listed above.

The "server-ip" field should probably be empty.

Have you tried restarting your launcher? (If that doesn't fix it you probably need to take this to the tracker)

Yes, the file named "magical_crops_1.6.4_3.2.0_BETA_15a.zip" worked for me.

I'm game. Gotta spread the love.

Pretty much anything inside a tag like this is considered a block: blocks { . . . }

You have at least two mods for Forge/MC 1.7.2 in your pack: Metallurgy Jabba Get the versions for 1.6.4 and try again. Also, as Stop mocking me0 mentions, please provide links to your Technic Pack page and/or your API URL.

Holy buckets, Batman. You would never need to allocate that much RAM to the launcher under any circumstances. Assuming your PC has 8G of RAM, set your launcher to 3G at a maximum. If your PC has only 4G then set your launcher to 2G maximum and don't run many other programs while running the client.

You have a block ID in ResonantInduction.cfg for molten_copper set to 16000. The highest value for blocks capable of worldgen is 4095 (as previously mentioned). However, somehow you ended up with a number of conflicts between blocks in the same ResonantInduction.cfg file. No idea how that would happen. You are better off at this point just removing the ResonantInduction.cfg file and letting the mod make a new one. You need to update to the beta (as of this post) of Magical Crops to be compatible with the version of Thaumcraft you have installed. You will have a few block ID conflicts to fix after you do this. Don't feel to bad about missing that last one. The MCF post for Magical Crops doesn't mention anything about being compatible with certain versions of Thaumcraft. A tricky crash.

What do you have set for "server-ip=" in your server.properties file?

You will need to provide launcher logs, links to your Technic Pack page, the API URL... something we can use to help you.

This is in the sticky Common Problems and Solutions thread. Look for the entry in the first post for "Mapwriter file corrupt".

Add an exception to your antivirus software for the server's folder on your file system.

Let us be quite clear. I never attacked you personally (and I won't), I was simply talking about the information you posted. Regardless of how much I could spend on server hosting (and it's currently a lot more than a few hundred/month), the information is either anecdotal or misleading. I have neither the time nor inclination to iterate over your entire post so I'll hit a few highlights: This is completely wrong and misleading. There are as many ways to protect against brute force SSH attacks as there are ways to do brute force SSH attacks. Just a few off the top of my head: Using IPTables to limit the connection speed based on flow/frequency, SSHGuard, DenyHosts. Those are three I have used myself on multiple occasions (some of those occasions going back farther than a lot of the users were even born). This is what I meant by misinformation. If you are using the two OSs on the exact same hardware your application performance should be exactly the same. If it is not then you have something misconfigured. Saying that one is not as fast as the other will mislead folks as it is completely untrue. Heartbleed was/is a vulnerability in specific versions of OpenSSL and has little relevance to the platform on which it is hosted. Both Windows and Linux, if running vulnerable versions of OpenSSL, can be compromised with Heartbleed style attacks. It also is not effected by encryption key length (other than it just being longer and taking more time to heist). My biggest issues come from all of the information being presented in a very anecdotal, non-specific way. There are SO many things which contribute to server performance, especially when dealing with modded Forge/MC servers. How many concurrent players? How big is the modpack? How much worldgen/oregen/treegen happens? What kind of server (Forge/MCPC+ Cauldron/Spigot/Vanilla/Bukkit)? Using Dynmap? Are you on VPS/Dedi/CoLo? There are so many more things that can contribute to good or poor performance. I'm not saying the information you presented was all "wrong". I'm saying that due to the way it was presented it is mostly not "relevant". More helpful information would be something like: "If you have X number of heavy worldgen mods (like blah or blah or blah) and want to have Y number of concurrent players here are a few hardware examples which will provide Z level of performance. If you want to add Dynmap keep in mind that it can create quite a bit of disk I/O and additional storage requirements." Please don't make this personal. I think I have made it quite clear in all my posts that all I am after is a more fun and less frustrating experience for everyone. If you disagree with what I am saying then I encourage you to refute my claims or positions and I will be attentive to that. If I am in the wrong then I welcome elucidation.

Also, it is quite helpful to have a link to your Technic Pack page and/or your API URL (the URL you paste into the launcher for the modpack).

There isn't enough information there to truly isolate the problem, but here is some information that might help: One should never allocate the amount of physical system RAM to a Forge/MC server process. If your physical server (or virtual, whatever) has 3G of ram then you shouldn't allocate more than 2G to the java process (-Xmx2048m) and I would personally start at 1.5G. This provides overhead space for the operating system to do its thing for all of the processes it has to manage like its own memory management, network I/O, file system operations, etc. It is advisable to reduce the number of chunks loaded around each player. This is controlled through the "view-distance" setting in your server.properties file. I would recommend setting it to 6 and seeing how things change. Limit the use of force-loaded chunks using various chunk loaders. You can use the /chunkloaders command to see the number of forced chunks in each dimension. Those are just a few data points. Work with that a bit and see where it gets you.

What you are seeing is the different between internal and external references to RAM/Heap allocation for the JVM (Java Virtual Machine). Externally you have a single process that is managed by the operating system and the memory usage shown is the total space used for both the programs/threads running inside the JVM and the overhead required to manage them. Internally you get different numbers depending on how the thread are allocated inside the JVM and those will fluctuate depending on Garbage Collection (GC), how many users are currently on, how many chunks are loaded, how busy certain mods are, etc. There are about as many ways for lag to creep in as there are stars in the sky. You will need to do more work to isolate the source before blaming your memory allocations.

Pros: It is always good to have more folks contributing to the community. Learning more about how your hardware runs is always a good thing. The OP is obviously trying to help folks out. Cons: Pretty much the entire original post in this thread has ZERO relevance to anyone's experience but the OP's. Please, please do not base your server design decisions on data in this thread (so far). There is enough incorrect information to cause problems for folks if they tried to follow this.

Where did you get that build of MCPC+? The author's build server, which is their recommended place to download from, has a current version of Build #272. You have Build #3. Download the latest version and try again: http://ci.md-5.net/job/Cauldron-164/