plowmanplow

The latest version of Optifine for 1.6.4 is not compatible with the latest release of AM2. You'll need to remove one or the other. You have not included any config files in your modpack. This is always "bad". Once your pack is working correctly locally, and all conflicts have been resolved, the full config folder and its contents must be included in your modpack archive.

@its_a_builder: You do realize that this post is something like 17 months old, yes? Necro-posting serves little purpose.

Create a post in the Tracker for the Launcher ( http://forums.technicpack.net/tracker/ ). Make sure to follow the template and guidelines.

That is happening because you are launching the minecraft_server JAR file instead of the Forge JAR file.

If you don't use it, and don't place any microblocks, it causes basically zero additional load. You can't remove it without also taking out all the mods which rely on it. You probably don't want to do that.

Surprisingly enough, there's an entire forum for AoBT servers: http://forums.technicpack.net/forum/75-attack-of-the-b-team-servers/

Forge multipart is a dependency of other mods and the client will re-add it if you remove it. Since you can safely ignore that the mod is there by simply not using it why is it annoying? If it is just an issue of not liking the microblocks showing up in NEI that is simply to turn off.

A "headless" setup is one in which you have no KVM (keyboard, video, mouse). In this configuration you would be managing your system through SSH terminals and SFTP/SCP file transfers (or Samba/CIFS if you are fancy). Be careful messing with niceness settings. "nice" levels in Linux refer to how a process' system calls are prioritized ( http://en.wikipedia.org/wiki/Nice_%28Unix%29 ). IONice does the same thing for disk IO ( http://www.askapache.com/optimize/optimize-nice-ionice.html ). There are "gotchas", however, it can be VERY handy for things like backup operations so the server doesn't lag like a beast when running your periodic world backups. Running Forge/MC servers in a VM is extremely viable. Running servers in a shared hosting environment where resources are painfully oversubscribed is an enormous stack of suck. As long as you aren't oversubscribing (specifically memory) you can get great performance using VMs, especially when using a Type-1/bare-metal Hypervisor.

Mostly correct in practice and 100% correct in spirit. As long as you didn't use any API calls which were specific to Java 8 and only used Java 7 API structures and method you would probably be fine. However, it is easy to let something slip by unless you are extremely diligent. In practice, it makes sense to use the API which you plan on targeting for distribution.

Changing the config settings value in the launcher defines the -Xmx parameter. Why would you care about -Xms as it really doesn't matter? You really don't want to go hard-coding system Java parameters. Just use the Launcher settings.

Before creating a server for an existing client modpack it is vitally important that: If you are using Forge <=1.6.4 all ID conflicts for both items and blocks must be resolved. Most block ID conflicts will crash the client or produce an IDConflicts.txt file, but not always. Most item ID conflicts will not crash the client (at least not initially). Even if the client pack starts successfuly you need to search the ForgeModLoader-client-0.log when using a <=1.6.4 modpack for the word CONFLICT. Not all conflicts can be resolved (Mystcraft, many slabs, some Gravestone stuff) but most of them need to be addressed. Specifically focus on conflicts that list two completely different mods in the conflict. The client must NOT have an automated ID fixer installed. All conflicts need to be resolved in the configs. It is safe to use IDFixMinus as long as it is removed after all the conflicts have been resolved. The client modpack MUST have a full compliment of config files. These files get created the first time mods get injected into Forge. Even with modpacks for Forge >=1.7.2 the configs need to be included to ensure that they are synchronized between the client and server. I recommend the use of Cauldron over basic Forge for running a server. Cauldron has Spigot built in along with other optimizations which make things run better (usually). Cauldron also integrates the Bukkit API so you can use Bukkit plugins if you choose. Cauldron is no longer available through legitimate means. If you are creating a new server for Forge <= 1.7.10 you will need to use vanilla Forge. This guide assumes you are using Java 8. If you are building a server for 1.6.4 or 1.7.2 you will need Lexmanos' Legacy Java Fixer mod. If you are building a server for 1.7.10 you will need to use Forge #1230 or later. Download the latest version of the Cauldron Forge installer for your version of MC: http://files.minecraftforge.net Install Cauldron Forge to a new folder. We'll refer to that folder as SERVER. Copy your config and mods folders from your client pack to SERVER. If you have other mods which require top level folders (like BetterDungeons or Flan for example) those must be copied over as well. Remove any client-only mods from SERVERmods. These are mods which only operate on the client. Mods like Animated Player, ArmorStatusHUD, Damage Indicators, Minimap mods, NotEnoughKeys, etc. Basically if the mod only changes the way that things look in the game, but not saved into the world it is probably a client only mod. Most mod authors are kind enough to indicate when their mods are client-only. If you start the pack and are getting errors about "client" or "render" then you probably have a client-only mod in your pack. Create a batch or script file to start your server. I won't get into the intricacies of fancy Java parameters here. This is a simple way to start your server: startserver.bat: @echo off java -Xms2048m -Xmx2048m -jar forge-server-filename.jar nogui startserver.sh: #!/bin/bash java -Xms2048m -Xmx2048m -jar forge-server-filename.jar nogui Adjust the -Xms and -Xmx parameters to suit your needs and client load. Change "forge-server-filename.jar" to the actual filename for your Forge JAR. If running on a Linux server I highly recommend the use of Linux screen. Google for detailed usage instructions. Make sure you have the latest version of Java 8 for your OS. I recommend using the JDK instead of the JRE because it comes with some debugging tools which can be useful in the even of crashes and hangs. Make sure you have some kind of backup solution in place. Use a mod or some external solution, but use something lest you end up crying in your Wheaties.

For any system which is intended to be a dedicated server one should: Focus on Linux distros which are known to work well in a "headless" setup. Focus on Linux distros with great community support and a history of stability. Become familiar with tools which assist in running background processes: Linux screen, cron jobs, etc. Become familiar with monitoring tools: atop (stats over time, woohoo), Java profilers, etc. Become familiar with statistics reporting tools: rrdtool, MRTG, vnstat, etc. Have patience Become familiar with the use of (and etiquette for) IRC on Freenode (for Linux and services) and Esper (for many modded MC projects).

There is a box on your pack settings page labeled "Force Directory Change". Make sure it is NOT checked.

The "making modpacks for others" atmosphere is pretty dismal at the moment. You'll either need to make this yourself (again, try it and ask for help) or do without.

EE2 is only for <= Forge/MC 1.2.5. You are out of luck.

Why not make this yourselves? Making a client pack once you have the server pack takes about 30 seconds.

This request belongs in the Tracker for the Tekkit modpack. Follow the posting guidelines in the Tracker from the link at the top of this page.

Forge/MC 1.6+ does not use a coremods folder in any way. All mods belong in or below the mods folder. You have a CodeChickenCore mod in the coremods folder that is newer than the one in your mods folder. You have a mix of Forge/MC 1.7.10 and 1.6.4 mods. They must all be for the same version of Forge/MC.

Oh, it's not a problem to share it, it is just that if you deviate from the default pack and want other people to connect they will have to have the EXACT same mods and config files. That would require a custom modpack. As for how to add mods, kind of yes. Simply add them to the pack's mods folder. Start the client and it will error out if you have block ID conflicts. Those will need to be fixed if it happens. Once the pack starts you will need to check your ForgeModLoader-client-0.log file for the word CONFLICT to identify any item ID conflicts so that they can be resolved.

What server pack are you running? What is the API URL for the client pack? What server JAR specifically are you using? Saying you are using just "Spigot" makes no sense because that doesn't include Forge which would be required for modded MC. Which JAVA are you using? Keep in mind that current versions of Cauldron (if you are indeed using that) handle chunk loading and unloading differently than you may be used to.

The current/latest versions of BTeam have MobiusCore and Opis versions which are incompatible with Cauldron. If you are using that it won't work. Make sure you are using the latest versions of Cauldron for your server and that you ran the installer to get the latest libraries. Don't use Java 8. Many, many mods have issues with Java 8.

The big challenging with banning crafting is a combination of two things: Using anything but vanilla crafting tables or personal crafting spaces makes it very difficult for a Bukkit plugin to prevent crafting, especially when using automated methods like TE, AE and LP. Blocking a recipe completely requires something to get in the way of a tremendous amount of API code by the mod in question which is trying to hook into Forge dictionary registries. Futzing around with that is a recipe (pun intended) for disaster.

With the amount of memory your system has, running an X session won't have any negative impact on the performance of the server. And no, you can safely ignore what's in buffered space vs. swap vs. cache, etc. Until you are starting your server process on a 32G system with -Xmx30G it is a non-issue.

That atop output show a system that is barely loaded down at all. There is no reason you should see the "can't keep up" message with those stats.

CentOS is a good, solid distro and has a large install base so getting to know that is always a good option. As for as performance of different distros, they should all be within most test scenarios. All Linux distros pull from the same kernel and utilities (mostly) so the performance is largely based on hardware and tuning. Assuming you are running on the same hardware there should be no real difference. Any "can't keep up" messages are either due to memory, disk I/O or CPU cycle starvation. Run something like atop ( http://www.atoptool.nl/ ) to see what is getting hit the hardest to help you figure out where to focus your efforts.