plowmanplow

There is no "right place to put it". Don't be a thief. Buy the game.

Likely. I am all about "teaching a man to fish", but if the man is starting from a place where they couldn't tell a fish from a horse... ain't nobody got time fo dat.

I also maintain a modpack called "BareBonesPack" which has just Forge installed. I use the Solder API so you can select which version of Forge you wish to use from the pack settings. Everything from 1.4.7 to 1.7.2. You can start with that and just add mods and such as you wish. Makes it easy to start out fresh.

Honestly, security through obscurity is seldom a good choice. The information will get out there and the only people who will know about it are the people who like to exploit this kind of stuff. TekkitLite still has many dupe bugs that were never fixed and anyone wanting to run a server has to scramble all over looking for what they need to ban/block. The more people who know about these, the more pressure is put on folks to fix them, and the more server owners can mitigate the impact until a fix shows up (if it ever does).

Your items should be going into a "gravestone" at or near your death. Try checking vertically.

Build and place a Calcinator. Cook diamonds in the Calcinator to get minium dust. Craft an Aludel and a Glass Bell then place them (glass bell goes on top of the Aludel). Make a Inert Stone and put it in the top slot of the Aludel. Put 8 Minium Dust in the middle slot of the Aludel. Cook them (put some kind of fuel in the bottom slot). Profit!

Case sensitivity matters: Your modpack.jar is named "ModPack.jar". Make it all lower case. Your mods folder is named "Mods". Make it all lower case. If you are going to try things out just to test, just include modpack.jar. It is not necessary to include any other mods. Just start the client and the Forge version should be listed in the lower left corner. If it isn't, then you did something wrong. If you are going to test with a mod, get something current. IC2 .117 is ooooold. If you want to use that as your test, get the latest IC2 Experimental branch version.

You have to use the Solder API. This is "non-trivial", but there is a whole thread dedicated to accomplishing this.

You include NEI and EnderStorage but do not have the CodeChickenCore parent library which they require. You have Buildcraft 4.2.2 but include Additional Buildcraft Objects for version 4.1.2. Get the correct version (right from the author's posts/links, imagine that) You don't include any config files with the pack. Why does no one do this? It is VERY likely that you will have a block/item/entity/biome conflict between mods if you don't get the configs right and distribute them with your pack. Speaking very loosely, these are the steps you want to take when making a pack: Get your pack working locally first. My "BareBonesPack" custom modpack can really help you here since it allows you to select which version of Forge/MC you want to use but has no other mods included. Add in mods a few at a time so you can get your config files tweaked properly. Make sure you have no conflicts. Even if MC starts you may still have a conflict. Open your most recent Forge client log and search for "CONFLICT". However, conflicts are only part of the challenge. You may need to tweak things like microblock configs or TreeCapitator to include tools and trees from other mods it may not include by default. Make a new folder somewhere with a "bin", "config" and "mods" folder. Copy the configs and mods from your test install over to the new structure. Then copy out ONLY the modpack.jar from your test environment to the new structure. Zip this up by going into the new folder, selecting all three folders (bin, config, mods) and (usually) right-clicking then select create new zip file using 7zip, WinZip or whatever you use. DO NOT make a RAR archive. It must be in ZIP format.

Yeah, that's a problem. He thinks he is ready, but quite demonstrably, he is not. Here are a few problems in no particular order: You have not heeded the advice from my posts in this thread. They say "third time's the charm" but I'm out after this. In just a couple minutes of looking at your pack I see at least 5 things I've mentioned that are still a problem. The fact that the problem mods are different than the ones before indicates that you are simply not paying any attention to detail. With Pixelmon in your pack the thing is HUGE. At that size you'll blow out your Dropbox quota in no time flat. New problem: you have two versions of NotEnoughItems. That never works. New problem: The contents of your modpack zip are in a subfolder. Must be top level. Your modpack.jar file has problems. 1) It is actually a RAR format file, not a ZIP format file. Must be ZIP. 2) You have all the contents in a subfolder. Must be top level inside the archive. 3) The contents of the archive look... off. There are files missing which I KNOW are in the Forge universal downloads so something is very wrong. Best of luck. You are going to need it.

Yeah, this was a big one. The RS Energy Cells became their creative versions. Same with portable tanks. That's an "inconvenience" since it can be fixed using a bukkit plugin that removes blocks from the world. Just fly around built-up areas and "poof". The biggest hassle was that for some reason, some of the items, both in inventories and those used in MAC patterns, would cause a client crash if they were either rendered in the world (item drop) or moused over in a MAC. These took a long time to resolve and there were only 4 MACs in the world (MAC = AE Molecular Assembly Chamber). Admittedly, some of these problems could have been from items in other mods. The pack I use has 135. However, the same admonitions still apply. Just make a new world when you are ready to update Or, as in my case, just run 5 servers. HA! (I might have a MC problem).

The implication is that you are missing the modpack.jar file in your new zip (or it is not configured correctly).

In order to use Bukkit plugins you need to use something like MCPC+ in place of the Tekkit jar file you normally start. http://ci.md-5.net/job/MCPC-Plus-164/

There are just way too many changes inside the mods. Items with different damage values or NBT data. Different mechanics for how items/blocks interact with each other, fundamental changes to how a mod operates (Thermal Expansion has MASSIVE changes). Is it possible? Yes, I did it with a pack that started with 1.1.10 and had enough extra mods to bring the mod count to 135. Was it painful and took a LOT of time and patience? You bet. I don't say this lightly. I have been a systems engineer/troubleshooter working with these kinds of things for over 20 years. Upgrading from 1.1.10 to 1.2.6 is what we jokingly like to call a "non-trivial process".

I'm talking about the modpack.jar file. For use in the platform, just go to the source. You never want to get core libraries like that from anywhere but their original creators. Go to http://files.minecraftforge.net/ and download the "Universal" jar for your preferred version of Forge/MC. Rename that file to "modpack.jar" and you are done.

The "modpack.jar" file in your bin folder is in RAR format instead of ZIP format.

Oh, I've got an extensive list of things in the appropriate categories. I've been using GP for a long time. My point was that I've never been able to get some of the TE blocks protected on a 1.6.4 server with the TE 3.0.0.2. They yell about not being trusted when someone tries to access them (telling me that the config is correct), but they still open anyway and the player can change what they want.

Your modpack.jar has a few problems You make a RAR archive instead of a ZIP archive. Forge/MC requires that it be in the ZIP format. Your archive is not constructed correctly. You have the files nested inside another folder. They should all be in the top level of the zip. To do this, go INTO your folder with all the files, select all and right-click then choose ZIP (assuming you have a program installed which will create archives in the ZIP format). You have unzipped the mod file in the mods folder. Don't do this. Just download the mod from the author's forum post and put that file into your mods folder. Remove the uncompressed version first.

Same basic principle, but you have to make sure you: Get the correct version of MCPC+ (since running a multi-person server without plugins is an exercise in frustration) for your Forge version. In this case, it is 1.5.2. This will make your live much easier. Remove any "client only" mods from the pack like the minimap mod and maybe others. If you get errors talking about "world/render" or similar you still have a mod that is client only. Some mods are written VERY poorly and don't work well (or at all) in SMP. Remove the "bin" folder. You don't need it on the server. Pray to the MC gods that it works.

You may have already done this, but you may still have conflicts you aren't aware of unless you have audited your Forge client logs. If you were to open your most recent "ForgeModLoader-client-0.log" and search for "CONFLICT" you may have conflicts for item IDs with other mods. Item ID conflicts don't cause a crash (usually) but they do make really weird things happen in-game. Not sure if Thaumic Tinkerer and Kami (you may not have added those Thaumcraft extras) does any dynamic ID allocation but when I did the Kami items were conflicting with Flan's. Just for giggles, I went through and deconflicted these mods with B-Team: Forestry Binnie Mods (ExtraTrees/ExtraBees, why would one ever use Forestry without it) Thaumcraft Thaumic Tinkerer Kami (goes with TT) And for some icing on that B-Team cake, here is a download link for the configs: https://www.jaj.com/tekkit/forestry_thaumcraft-bteam.zip I didn't do any tweaking of the TreeCapitator or Microblocks configs to integrate new trees/tools/blocks but these should get someone up and running without conflicts.

Also, keep in mind that it is all well and good to digress on the theory of how resources get allocated/consumed/etc. but when it comes to MC (and specifically Modded MC with texture packs) any time you allocate someof these precious resources to one thing you'll be preventing something else from using them. While it is true that MC doesn't do anything specifically 64bit, but running 64bit Java on system with a decent amount of ram will let you allocate more than the paltry 1G in the launcher that a 32bit Java/OS will allow you to do. Toss in a large texture pack (big packs with lots of mods with textures can see the resource pack exceed 100M in a hurry) and your memory usage can easily double over what you have set in the launcher. Assigning too much memory to the client and the OS may start to starve especially if you have a lot of other things running at once. I'm running 8G of memory with 1.5G set in the launcher. Using a modpack with 135 reported mods and a 100M texture pack and the Java process running MC can sometimes exceed 3G. Try that same setup on a PC with 4G of ram and you are going to have a bad day. Without putting it in really technical terms Java kind of acts like a gas in that it will expand to take up all the available space. If you set your launcher to 4G you better believe that before long it will be using the entire 4G of space. The Java garbage collection threads, which is what goes through and cleans up the "bloat" that isn't needed anymore can really chew on CPU cycles if you have the initial/max allocation set too high. A lot of the folks coming on here have zero understanding about how the internals work. I'm a huge proponent of "teaching a man to fish", but I would give these recommendations to the uninitiated: Set your launcher to the absolute minimum amount of memory that will allow you to successfully run your chosen pack(s) Keep an eye on the actual amount of memory that task manager reports your MC/Java process to be using. If it gets to within 1.5G of your actual physical memory (on Windows) your system will likely start to run poorly. The more things you have running will require this gap to be wider. If you have a browser with half a dozen or more tabs open and a few explorer windows you might want that gap to be 2G-2.5G or more. Start adding in Photoshop, SSH windows, Excel, Winzip/7zip and you'll fill up 8G in a heartbeat and start bulging at the seams. Y'all have given out some great details and information. This is just my two cents, for what it's worth.

You mention that you are using GriefPrevention for player claim protections. Have you been able to successfully block non-trusted players from accessing TE machines like pulverizers and furnaces?

Running a BTeam server and client on a Windows machine with 4G of ram will be almost impossible. Good luck.

The implication is that your computer has insufficient memory to reserve the minimum allocation you have set: -Xms2G More details would help: - How much physical RAM does your machine have - Are you trying to run the client and server from the same machine - How much free memory does your system report before starting client or server

The pack successfully starts for me, however, you have some problems. You are using some VERY old versions of mods for 1.6.4. You should be getting your mods from the author's own distribution channels, NOT from random sites around the internet. 1.6.4 has been around for a while so there are many releases for many mods. Going right to the source is always best. You are using the modloader version of TreeCapitator instead of the Forge version. You need to be using the correct version of the mod. Had you been on the author's forum post where releases are provided you would have seen explicit instructions. Some of your mod files do not have version numbers in the name (bspkrscore for example). If you renamed them yourself don't do that. The version numbers help you easily know what version of the mod you have. In this instance you have v3.04 of bspkrscore and te latest version for 1.6.4 is v5.3. Your BuildCraft Additional Pipes mod is for Forge/MC version 1.2.5. You are a couple years out of date on this one. See #1. You have included IndustrialCraft in your pack. However, you have the .118 branch which isn't really being updated anymore. You probably want to be using the experimental branch since it is current and quite stable (and compatible with other mods). Last but not least, you REALLY need to include config files in your pack. I didn't get into ID conflict checking but as you add more mods you will almost surely have to deal with that. Without including config files you'll never be able to assure that there won't be ID conflicts for people trying to use the pack.