plowmanplow

@RanmaKei: Took a quick look at the contents of your pack. You don't have any of the config files for your mods in place. This is ill-advised for many reasons: item/block ID conflicts provider or entity ID conflicts No customization of mods for things like which microblocks are cuttable or which tools work in Treecapitator, etc. No tuning away from the defaults which OFTEN needs to be done when you have many mods installed for things like blacklists for IC2 Macerators, Tesseract/conduit energy loss (in 1.5.2), etc. No ability to make the mods work well together for things like ore and resource spawning. By taking the defaults you might have 4 or 5 mods all trying to spawn copper, which may not be what you want Making the mods play well with each other can be really tricky. Ore spawning is a big one, but there are lots of little things. For instance, modular power suits and addons can have recipes for Thermal Expansion, Vanilla, and IC2. Do you want all the chipsets to be interchangable? Do you want all three kinds or only one? (also, you haven't included any recipe files so you'll get none of the above). One of my packs that has a ton of mods (the game shows 133 but some mods files have multiple included, which is normal) has 144 files in the config folder and subfolders. Except for the language files I probably had to tweak the vast majority of those files.

Well, the Technic folks are currently working on a Tekkit 1.2.x version based on MC 1.6.4 Forge mods but it is still in testing. The OP did state that he was using 1.5.2 :)

1) Put the MCPC+ jar into a folder (we'll call this SERVERFOLDER) and start it once, then stop the server. This will download libraries and make your folders. 1a) For now you can just open a command prompt in the SERVERFOLDER folder and type "java -jar mcpcblahblahblah.jar nogui". When running the server for real you will likely want to use a number of command line options here as well. While the details are beyond the scope of this post you will probably want at least "-Xmx2048m" where 2048 should be set to how much memory in megabytes you wish to allocate to the server. This will be dependant on how many mods you have, how many concurrent players you have, and how many chunks are force loaded by things such as quarries and chunk loaders. 2) Copy your mods from your custom pack to SERVERFOLDER\mods 2a) If you want to do this RIGHT you will copy these one at a time along with the mod config (see Step #3) and start/stop your server. This way you will know when you copy a new mod over that it is probably a client only mod when your server crashes instead of copying over 100 mods and having no idea which one is causing the problem. 3) Copy your configs from your custom pack to SERVERFOLDER\config. 3a) See Step #2a 4) Delete any mods that are client only. Things like Damage Indicators, Optifine, Minimap, etc. If you try to start the server and it complains about lwjgl, you probably have a client mod still in the mods folder. 5) Now comes the fun part. You'll need to configure bukkit.yml, mcpc.yml, server.properties to suit your needs. Explaining those is well beyond the scope of this short post. 6) Assuming you actually wish to run a server where folks other than you are logging in you will likely want to have some protections in place and a few "conveniences" that folks have become accustomed to. This will require some bukkit plugins. Here are a few suggestions: BanItem - Gives you some ability to prevent users from using/placing/owning items. Doesn't always work because of how some mods are coded. Essentials - Lots of player management features as well as features players can use such as homes, usable signs, kits, etc. GriefPrevention - Lets players manage their own "claims" which provides build/access permissions. PermissionsEx+ModifyWorld - Permissions plugin. Allows you to control access to features/blocks/items/etc. from other mods and plugins. WorldEdit - Great for helping you make/fix things in-game WorldGuard - Useful for protecting things like fire spread, block damage from mobs, etc. Similar to GriefPrevention but more for administration, not players. WorldBorder - Lets you set a maximum distance from spawn that players may travel. Helps limit world growth. Good luck. If you intend to distribute the server once you have all the files/mods/configs set up you probably do NOT want to include anything but your "config" and "mods" and any other miscellaneous files associated with the mods themselves. Let people get their own download of MCPC+ and let it download its own libraries (you don't want to distribute those anyway).

You guys are pointing him at the 1.6.4 MCPC+ and he's running Tekkit 1.1.10 on MC 1.5.2. He needs this version of MCPC+: http://ci.md-5.net/job/MCPC-Plus-Legacy/lastSuccessfulBuild/artifact/target/mcpc-plus-1.5.2-R1.1-forge738-B653.jar

norman: yes, that would be my assessment. There is just such a HUGE amount of momentum with the current system that it will take a while to switch over even after it is rolled out and feature complete. As for the required tech knowledge, yeah, I do get that. However, as an example, this is would be the steps for a single mod modpack (and more is just repeat the steps after add mod) 1) Get the example/starting file from the top-ish post in the Platform Pagoda forum here and extract it somewhere. We'll call that PACKLOC 2) Download mod and copy into mods folder in PACKLOC 3) Zip up the contents of PACKLOC 4) Put the zip somewhere you can download it with a public URL (dropbox, amazon, self, etc.) 5) Register on technic page and "add pack" with the URL from Step 4 or edit pack properties with new zip download if updating 6) Add custom pack from Step 5 into the launcher 7) Run pack and resolve any ID conflicts the game complains about 8) Copy config files to the config folder in PACKLOC 9) Repeat steps 2, 3, 4, 5 ... Alright, you got me. Once you know how, or understand the back-end it's trivial. Otherwise it's probably overwhelming. My bad. Of course, this is why I maintain custom packs for my servers because expecting just anyone to be able to assemble a bunch of different mods into a coherent pack can be a tall order.

And making a modpack for use in the Technic Launcher is really pretty trivial. Making one with 135 mods where everything works well together (TreeCapitator, Forge/Immibis Microblocks, and a ton of others) can be challenging, but a pack with 15 or 20 mods is easy. You could start from scratch and have a pack up and running that everyone could use in less than an hour, easy peasy.

One of the challenges I'm having is block protections using something like GriefPrevention on MCPC+. When protected, some blocks yell at the player about not having access/permission but allow the player to access the block/machine anyway. For instance, with TE2 everything worked perfectly. With TE3, most of the machines exhibit this behavior. The TE conduits, however, do seem to play well with the protections. I realize this isn't a Technic issue and it is probably up to King Lemming and company to play better with the event system so that the access can be controlled... but it'll make running a public server a lot harder until that happens.

yeah, I see no reason why WR-CBE wouldn't be added in. It plays well with Project Red, but works fine without it.

edit: Scratch that. Looks like the dev is having computer problems and not able to keep the code up at the moment. Hopefully someone else can jump on that. :)

IC2 Experimental is current with 1.6.4 (which TekkitMain is moving to with the new 1.2.x versions). It has had so many changes which I feel improve the playability of the mod and will potentially be more scalable (their energy network works a lot more like TE now, no more packets). However, the development of the mod is VERY fast and loose. When new bugs show up there doesn't seem to be a lot of interest or procedure in place to resolve them. Even when they are reported and confirmed, and literally require a one line change which is put into the issue ticket, they will stick around for many versions. There are some recipe display bugs which have been in for 5 or 6 new builds. Is it a lot more fun now? I think so. Is it likely a nightmare to try to keep integrated and stable? You betcha. That is why it doesn't belong here, imho.

Step 1) Assuming you are using the "hires" template, edit templates/normal-hires.txt and set "enabled" to false Step 2) Edit worlds.txt and only define worlds for the dimensions you wish to have enabled Step 3) Edit worlds.txt and set the "template" for your enabled worlds to something unique. For mine I use "template: mainworld" Step 4) Copy "normal-hires.txt" in templates/ to what you set in Step3 with "-hires.txt" tacked on (I use "mainworld-hires.txt") Step 5) Edit templates/mainworld-hires.txt (or whatever you named it), set "enabled: true" and comment out any renders you don't want to use (i.e. "cave" or "surface", etc.) Step 6) Reload dynmap

Installing Optifine in 1.6.4 is as simple as dropping the mod zip into your mods/ directory.

It is easy enough in Dynmap to only display worlds and renderings you wish to have displayed. That way the map doesn't get distracting and/or so huge.

The short answer to this question is "no". Not only are there many 100s of items/blocks you would need to try to sync up, there is massive terrain generation differences and even if you were able to match up most of the item/block IDs, there are so many that have new/different functionality that the stability of the world would be a disaster.

erik: alright, you should be good... again... :)

I have encountered this same problem. I narrowed it down to something between DD and Galacticraft. Simply removing the DimensionalDoors folder from your world (while shut down) gets you back up and running. I'm hoping there is maybe a way to blacklist the Galacticraft dimension IDs (there is a blacklist.txt file in DimensionalDoors/data/ but it is undocumented) as I expect that would resolve this problem.

No. When you have multiple mods that all have the same kind of resource all the resources of a "type" get registered in the Forge dictionary. So, "Tin" from every mods gets registered in Forge as interchangeable in recipes and such. This is a good thing. Which mod's resources you get out of a processing machine depends on a few different factors, but can often be unpredictable at first. Just use the unifier to turn all your different kinds of resources that are the same in the dictionary to a single type of resource.

@Gio You can just use a MFR Unifier to turn different mod's ores/dusts/ingots to a single type. This machine can be automated.

@erikhemmila You should be fine now. I moved you to the spawn building.

How are you shutting down the server? Are you just closing the window it is running in? The proper way to stop the server is to type "stop" in the console (or "/stop" in game). If you don't tell the server to shut down cleanly it can corrupt the world files.

Current builds of OpenModsLib/OpenPeripheralCore/OpenPeripheralAddons (http://www.openmods.info:8080/) have support for pretty much everything in the pack.

I threw together a "mostly complete" 64x patch for Sphax for the new MC 1.6.4 based Tekkit: https://www.jaj.com/tekkit/SphaxTekkit_1.2.x_64x_Patch.zip

Hmm, well, just from some small testing, On a world created with Tekkit 1.1.x, if I make a NEW world with the same seed, same everything, it is quite different. Maybe I'm way off the boat here, but was just relaying my personal experience. I'd be quite happy to be wrong here. One of the ways this crept up was that a couple chunk "resets" ended up with completely different terrain. In a desert, for instance, a single chunk got reset and is now very different. I may have something else going on. Who knows? The map has been around since the first release of the new Tekkit. Edit: <cough> Hmmm <cough>. I may have gotten my servers confused (running...so...many...). By way of an apology, here is a link to a wonderful walk-through of the new Thermal Expansion:

For those folks interested in moving a 1.1.x world up to this version, keep in mind that the worldgen changed dramatically between MC1.5.x and MC1.6.x. While this won't be a huge issue, the "borders" could get funky, and any "regenerated" chunks will be way off.

Heh, well, hope to see you on again soon. Lots of the old folks are still around and a fair number of new ones to boot.