plowmanplow

I sent you a PM. Look in the upper right corner of this page and you should see a red envelope.

There is a link right at the top of this page: http://forums.technicpack.net/tracker/project-4-attack-of-the-b-team/

If their limit is 1G then they have 32bit Java installed or very little memory in their PC. If they have a 64bit OS they need to uninstall the 32bit Java and install the latest 64bit Java 7 for their OS. If they have very little RAM then there's nothing you can do. If they only have a 32bit OS there is nothing you can do.

The server.properties file is just a file which has settings for the server process. You don't "run" the file. You can edit it with any text editor, but I would recommend something like Notepad++ instead of Notepad or Wordpad.

Because there are different developers for every different mod. If you have 50 mods in your pack you have 50 different developers or teams of developers and they all have to create their mods to pull from the same pool of IDs. Block IDs are <=4095 and item IDs should be between 4096 and 31999. Mods are almost never aware of each other in a way which would allow them to resolve their IDs safely. This is why the whole system was redone for Forge/MC 1.7+. That doesn't mean that you can leave out the configs in 1.7+ packs, but just that resolving conflicts is far simpler (and usually a non-issue).

Packs should be built methodically. One should not drop dozens of mods in a pack and hope that it works. Add them in singly or in logical groups (multi-file mods like ProjectRed or mods with dependencies like ThermalExpansion with CoFHCore) so that you can debug and resolve issues as you go. That way if you add something new and it starts acting up you will know for certain where the source of the problem is.

Without a lot of additional information (which modpack is this server for, what Java version, memory, etc.) it will be impossible to say. If everything else is fine though that might just be a debug message from a mod and can probably be safely ignored.

Why would you think this is a Dimensional Doors crash when there is nothing about DD in the exception output?This seems like a case of "correlation vs. causation". You might try using MCEdit to examine exactly what is at the block locations mentioned in the crash report. Maybe even remove them and see what that gets you (after making a backup, of course).

Nariko, here is the source of my frustration. I keep telling you, clearly and at length, precisely what you need to do to get the pack working correctly. You completely ignore me and then keep asking for help with the issue. Yes, your issue may be coming from something different or in addition to the issues I have outlined which need to be fixed. However, the way problems get resolved is that you fix the things you KNOW are wrong so that anything that still produces errors can be clearly isolated as the source of the issue. This isn't my first time 'round the rodeo. Fix what I report that needs to be fixed and if there are still issues we will address them. I know what is causing your "screen flickering" problem, but I'm hesitant to mention it at this point because I get the sense that as soon as the flickering goes away you will immediately try to start up a server. However, since the pack is still jacked up (see all previous posts) you'll end up coming back here and I'll have to report the same issues all over again. I'll try to make a deal with you. I'll not only tell you what the problem is, I'll explain how I tracked down the issue. In exchange, you will go back through your pack while applying everything I've referenced, line by line and bullet point by bullet point, until your client pack is "correct" before following the guidelines in the "making a server" post I referenced. You mentioned that "there is no ... errors on the fml log file". This is not true. The FML log shows this, over and over again: 2014-08-15 13:16:27 [INFO] [STDERR] GL error 0x0502: Invalid operation at pre-composite 9 times out of 10 a GL error like that will be caused by either OptiFine or a Shaders mod. In your case it is the ShadersModCore that is causing the problem. It must be incompatible with one of your mods. I don't know which one and couldn't find out without extensive testing of the pack, to which I'm currently disinclined.

This post on fixing ID conflicts should help you:

This post belongs in the Tracker for BTeam. You need to follow the posting guidelines there, following the template to create your post.

Anytime one is working with a web application there are always log files for every single interaction between the client and server. The most common logs are the access and error logs. If you put the version number in place and the interface does absolutely nothing when you click on the add version button you are going to need to examine your web server logs to help determine what is going on. Additionally, one could put some debug code into the PHP that is serving the Solder API out in order to get more information about what is going on behind the scenes. All of these actions are well outside the scope of support that can be offered here.

Short of taking your broken and incorrectly constructed modpack and fixing it, then making a server for the fixed modpack I don't know what else to suggest. The links I have provided are very straight forward and clearly outline, in simple methodical steps, the process of making a client modpack and turning that in to a server. I do not currently have time to do that work for you.

Yes. You should always use a code-based text editor like Notepad++ or Vim (sweet delicious Vim) to edit any text files associated with MC.

Okay, from your links I am assuming the slug for that mod is "mcheli". Double check that to make sure. Your file seems to be named correctly in that it has the slug name followed by "-versionnumber" and is a zip file. When adding the new version you are entering "1.7.10.0.9.3" in the version field?

Your bin folder has too much stuff in it. The bin folder should only contain the modpack.jar file. Your Reika mods don't match. DragonAPI is much newer than GeoStrata. Your IC2 version is out of date and has known issues. This post should help: You have MicdoodleCore mod but neither of the other two Galacticraft mods. You either need to have all three or none of them. You have a fatal item ID conflict with the updated GeoStrata. It is safe to change all the item IDs in the config from 10000-10006 to 10700-10706. You have about 35 block ID conflicts with the updated GeoStrata. The client will generate an IDCOnflicts.txt file with specifics. You have two fatal block ID conflicts. The client will generate an IDConflicts.txt file with specifics.

I have never had the mod work incorrectly where it continues to drain XP with the setting "B:elevatorDrainsXP=false" on the server. Please provide your OpenBlocks.cfg file.

You are not following directions... at all. What does Post #5 say? It says that you need to have three and only three folders in your modpack archive. Those folders should be: bin, config, mods. It also states that your bin folder should ONLY contain the modpack.jar file. It also states that you need to upgrade your Forge version to Build #1147. Why have you not done this? I cannot help you if you don't heed my advice. You have not installed Player API Core or Render Player API correctly. Open those ZIP files and follow the instructions.

Your modpack.jar file in the bin folder is actually named "modpack.jar..jar". Google "windows always show file extensions" to find out how to prevent this kind of error. You have WailaHarvestability mod but not Waila and NEI (which depends on CodeChickenCore) on which it depends.

@jominer: The pack is properly assembled and does work in a test environment. The issue (most likely) is that millenaire mod is a piece of dookie (from an installation and maintenance perspective) and often fails when in a Technic modpack. Reinstalling millenaire often fixes the issue.

That should be: java -Xms2048m -Xmx2048m -XX:PermSize=128m -jar KWR.jar nogui PAUSE notice the "-jar" before your JAR name.

This happens very often with Millenaire in modpacks. If the author would get with the program and package the mod properly (and use "normal" configs) it wouldn't be an issue. Try removing all the millenaire stuff, download the latest version from the author's website again and reinstall the mod (and extra files which come with it).

Make sure you have used a 1.7.2 Cauldron installer JAR at least once so it gets all its libraries. There are additional libraries over straight Forge. Please provide the contents of your startup script in a code tag.

All the mods you listed have SMP components and can be left in the server. Don't forget about the "should work but don't" mods.

I try to avoid Skype and only use it as a last resort. Support through the forums is asynchronous and I can do it when I can get to it. I have a modpack called BareBonesPack which i use to debug and build modpacks. The writeup I did on how to use it to make a modpack may be useful to you: Give that a run though.