Ravenleft

Some notes on reading error logs to try to figure out what the problem is. Look for the part that has this structure: [11:58:42] [sEVERE] 2013-03-25 11:58:42 [sEVERE] A critical error has occurred. java.lang.IndexOutOfBoundsException at eloraam.core.ItemParts.b(ItemParts.java:32) at yr.g(Item.java:244) at aan.b(SourceFile:84) at tw.a(RenderItem.java:278) at aiy.a(GuiIngame.java:756) at aiy.a(GuiIngame.java:333) at lr.b(EntityRenderer.java:1087) at net.minecraft.client.Minecraft.x(Minecraft.java:876) at net.minecraft.client.Minecraft.run(Minecraft.java:753) at java.lang.Thread.run(Unknown Source) This is the actual error message which gives you the error message itself and where the error occured. java.lang.IndexOutOfBoundsException This means you had an Index Out Of Bounds Exception which means that there is an index, usually a number of some kind, that had an unexpected value. at eloraam.core.ItemParts.b(ItemParts.java:32) The top row below the error message will usually tell you where the error was thrown, in this case it's Red Power 2 (Eloraam is the creator of RP2) and a part of RP2 named ItemParts. at yr.g(Item.java:244) The following rows will hint as to what the client was trying to do. Here we see it's doing something with an item. at aan.b(SourceFile:84) Doesn't tell us anything obvious. at tw.a(RenderItem.java:278) The client wanted to render an item. at aiy.a(GuiIngame.java:756) at aiy.a(GuiIngame.java:333) Inside a GUI of some sort. at lr.b(EntityRenderer.java:1087) The client wants to render an entity. Now, read that backwards from bottom to the top and we get something like: Client tries to render an entity which is a GUI containing an item that was added to the game by RP2 but crashed because the item's ID appears to be invalid. This doesn't really make any sense because the crash occured before any game was started so there shouldn't be any containers with RP2 items to render. What this really means then has to be something like that there was some kind of initialization going on that happened to fail when passing through the rendering engine. If you're not a developer it now helps if you have a bit of experience with Minecraft mods. The error involves RP2, if RP2 cause a crash it's pretty much ALWAYS a problem with IDs. Check the RP2 configs (located in .technictekkitredpowerredpower.cfg by default for MC1.2.5/Tekkit3) and look for any crazy values, the blocks should all be below 255 and the items below 4096 (Forge included support for 4096 IDs in build 139, it wasn't until forge for 1.3.x came out that the ID space was expanded further with block IDs up to 4095 and Item IDs up to 32000). This is a working RP2 config from Tekkit3: # RedPower 2 Configuration blocks { base { appliance.id=137 microblock.id=136 } control { backplane.id=133 peripheral.id=134 peripheralFlat.id=148 } lighting { lampOff.id=147 lampOn.id=146 } logic.logic.id=138 machine { frame.id=152 machine.id=150 machinePanel.id=151 } world { crops.id=144 leaves.id=141 log.id=143 ores.id=140 plants.id=139 stone.id=142 storage.id=145 } } enchant.disjunction.id=79 items { base { alloy.id=1002 drawplateDiamond.id=1075 dyeIndigo.id=1003 handsawDiamond.id=1005 handsawIron.id=1004 lumar.id=1000 nuggets.id=1078 resource.id=1001 screwdriver.id=1006 } control.disk.id=1077 logic.parts.id=1007 machine { battery { empty.id=1070 powered.id=1072 } sonicDriver.id=1071 voltmeter.id=1069 } world { athame.id=1073 axeEmerald.id=1029 axeRuby.id=1028 axeSapphire.id=1030 handsawEmerald.id=1009 handsawRuby.id=1008 handsawSapphire.id=1010 hoeEmerald.id=1032 hoeRuby.id=1031 hoeSapphire.id=1033 paintbrush { black.id=1068 blue.id=1064 brown.id=1065 cyan.id=1062 dry.id=1052 gray.id=1060 green.id=1066 lightBlue.id=1056 lime.id=1058 magenta.id=1055 orange.id=1054 pink.id=1059 purple.id=1063 red.id=1067 silver.id=1061 white.id=1053 yellow.id=1057 } paintcan { black.id=1051 blue.id=1047 brown.id=1048 cyan.id=1045 empty.id=1035 gray.id=1043 green.id=1049 lightBlue.id=1039 lime.id=1041 magenta.id=1038 orange.id=1037 pink.id=1042 purple.id=1046 red.id=1050 silver.id=1044 white.id=1036 yellow.id=1040 } pickaxeEmerald.id=1026 pickaxeRuby.id=1025 pickaxeSapphire.id=1027 seeds.id=1034 shovelEmerald.id=1023 shovelRuby.id=1022 shovelSapphire.id=1024 sickleDiamond.id=1014 sickleEmerald.id=1017 sickleGold.id=1015 sickleIron.id=1013 sickleRuby.id=1016 sickleSapphire.id=1018 sickleStone.id=1012 sickleWood.id=1011 swordEmerald.id=1020 swordRuby.id=1019 swordSapphire.id=1021 woolcard.id=1076 } } settings { core { # Automatically remap conflicting IDs. # WARNING: May corrupt existing worlds autoAssign=0 } logic.enableSounds=1 machine { frame { alwayscrate=0 linksize=1000 } } world { generate { copper=0 silver=1 tin=0 } tweaks { craftcircle=1 spreadmoss=1 } } } The easy way to fix this, in case there's nothing wrong in the RP2 config as such but rather a plain ID conflict and you don't feel like hunting it down, is to simply delete the entire tekkit folder and then redownload the Tekkit version you want to play (backup any saves you may have if you want to keep them). Tekkit should normally never have any conflicts or bad values in configs by default but strange things do happen, especially when you switch between different Tekkit versions. This is the most simple and straight forward interpretation of the error, there is of course a chance that I'm wrong and it's not an ID problem at all but in my experience the easy answer is usually the correct answer, especially when it involves RP2. I just realized I'm answering the wrong question. The log is describing what looks like a Minecraft crash, not a launcher crash. The log you want is the one in .techniclogs named something like techniclauncher_2013-10-10.log (there are probably several logfiles, past the latest one).

First of all, make backups of everything important. Did you install anything between when Minecraft was working and when it was not working? _anything at all_even a windows update or similar? If so, do a system restore to a point before installation (don't just uninstall, something is seriously messed up here so chances are a simple uninstall wont undo the problem). Do a system restore to a point where you know it was working anyway wether you installed anything or not. If you're lucky this was caused by a severe software screwup and then a system restore may fix it. (my first target would be Java but in this case I'd probably still prefer to do a full system restore rather than try uninstalling and reinstalling Java, whatever the cause something has done something very unexpected so a simple reinstall may not fix it) If you're overclocking something, stop doing that and put everything back to spec and then hope you didn't actually break anything. If you're not lucky then you're having real hardware problems. If you still have warranty or some service agreement or whatever, now is a good time to cash in on that. If not then I guess you're on your own here. Open the computer up and pick it apart completely, remove all the dust while you're at it. Check all connectors, pins, circuit boards, whatever to see if they look ok (no bent pins, no odd looking burns , no oxidation, no blown capacitors, etc). Then reassemble everything and make sure everything is seated properly, especially the cpu cooling and the memory sticks. Regardless of results (both in the software and hardware case), run diagnostic checks on everything, especially RAM and the CPU. The error you get can have a number of different causes where most are hardware related. Overheating due to overclocking or badly seated cpu coolers isn't uncommon but it can also be faulty memory, PSU, motherboard, etc. Basically, it can be a bitch to figure out what exactly is failing but if you get a Machine Check Exception it's something you should take seriously (Windows isn't kidding around with this particular BSD, it's caused by the CPU throwing an exception because something, from the CPU's perspective, isn't wired quite right). So, yeah..this probably has nothing at all to do with the Technic launcher, it just happens that the launcher does something that triggers the BSD.

Operating System: windows xp That's likely your problem right there. Try running the .jar directly, seems to work for some people using 32-bit Win XP. If .jar files are associated with Java then just double click, if it's not associated then you'll get a dialog asking you what program you want to use to open .jar files with...pick Java Platform SE binary..if that doesn't show up (was a while since I used XP so don't quite remember how it behaves) or if the previous options didn't work, manually browse to c:\program files\java\jre7\bin and pick javaw.exe. If it still doesn't work, upgrade to a 64-bit system. More than likely you already have 64-bit hardware..unless your computer is really ancient...in that case you can install a 64-bit Linux dist and run minecraft from there. Dual booting is usually not a problem and you can run Linux from USB-sticks, Live versions from CD/DVD, etc so you don't have to drop Win XP if you don't want to but for help and how to's on that, Google is your friend Only remaining options would be to try stuff like turning off anti virus (doubt AV would prevent Java from running like that but who knows), uninstall and reinstall Java..try different versions of Java (ie Java 6 allthough you then should take extra care to disable Java-plugins in your browser cause Java 6 is no longer supported and contains unpatched sexurity exploits), perform vodou rituals involving live chickens and big scary dudes with skeleton masks, get really pissed and start learning Java, pull the source code to the launcher, find these pesky issues that cause the launcher to fail on some 32-bit systems and fix them. Don't forget to do a pull request to the main Technic launcher branch so they can include the fixes if you do though. The Technic launcher really doesn't like 32-bit Windows very much though so even the vodou trick might fail and if so, you'd better walk away and do something else...you don't want to mess with Papa Legba.

First, check this thread: http://forums.technicpack.net/threads/bans-will-be-handed-out-for-posting-modpack-bugs-here-from-now-on.30664/ You may barely dodge that one though since you do actually have issues relating to the launcher itself even though your main problem (Minecraft ferezing) is something game/modrelated and has nothing to do with the launcher as such. Get rid of 32-bit Java all together, you don't need it. In fact, you should make a point of disabling any Java-plugin in your browser because those are prone to security exploits. For some reason it's still a common misconception that it's very useful to have Java support in your browser even though there are actually very few services that requires Java anymore and pretty much all of them are old legacy systems most never heard of to begin with. If by chance you do actually use such a service, have a really crappy bank that thinks security is for sissies or something else where you feel you really do need Java then you should still disable the Java-plugins and only enable them momentarily when you actually need them. By looking at your log it looks like you're not allowing the launcher to communicate over the Internet at all. Check your firewall settings and allow java to access the Internet. You can find the firewall settings through the control panel in the System and Security category. It should be pretty straight forward to allow a program. Remember that it's not the Techniclauncher.exe file you need to allow, it's java itself. I'm not sure if you need java.exe, javaw.exe or both. You seem to be trying different memory settings, you have 16 GB so just give Minecraft say 4 GB and you should never have any issues with that. What you may want to do is to check that checkbox that says "Increase PermGen Size". Minecraft loads a lot of classes on it's own, some mods loads a ton more of them and the most ambitious ones even generates new stuff dynamically (this is why you sometimes can play for a while and then suddenly, out of nowhere, you crash with an out of PermGen memory error making it all seem a bit random). So, Java stores info about all these objects and classes in the Permanent Generation heap, which is a dedicated space in memory where the garbage collector never goes (simply because these objects are static and should probably never unload before the whole program does so)...or something, I'm not a programmer! Anyway, if this space runs out Java will crash hard. This is probably not the cause of your freezes but checking the increase permgen size setting wont hurt anything. Finally, check your Minecraft folder (the relevant one is probably, in your case, "C:\users\admin\AppData\Roaming\.technic\NameOfModpack\" where NameOfModpack is the name of the modpack you're playing. In that folder there are several potentially interesting logs. One is located directly in the folder and is named ForgeModLoader-client-0.log (0.log is the most recent one, 1.log is the previous one, etc..there may be 0.log.1, etc and various files with a .lck ending too..don't worry about them). The other one is in a sub-folder named crash-reports and is named "crash-[date/time of crash]-client.txt " Post thes crash-report here and I guess I/we/someone can take a look at it. Hold the Forge-one until someone requests it as it can be massive.

Launcher Version: Latest, possibly others Operating System: Windows 7, possibly others Java Version: Java 7 64 bit, possibly others Antivirus Program: MS Essentials, possibly others Description of Problem: Description: I'm running a private server with 4 players using a custom modpack via the technic platform. When 2 of our users tries to update the modpack, the zip file is downloaded ok but is then only partly decompressed. No crashes, the MC client then usually launches without problems but the users can't connect to the server due to various mods missing. Decompressing the file manually from the cache folder works and allows them to connect. For the other 2 users this problem never occurs. This problem started happening a few weeks/a month ago, before that no one had any problems. This issue may be related to some of the reports in http://forums.technicpack.net/threads/error-uzipping-file.47203/ but at least the OP is not related as the errors he's getting points to something blocking the download leaving him with a 0 size zip which of course can't be unzipped (no valid zip header, MD5: Null, etc). In our case the zip always downloads and in the odd case where the download has failed in some manner it has been caused by connection issues. Problem Troubleshooting: Now, since it's working for 2 of us and not working for the other 2 I have tried to figure out what people have in common. What I've found is that the 2 of us who don't have this problem both have fairly new computers with quad core Core i7 CPUs, 8-16 GB RAM and SSD disks while the two who are having this problem both have more dated computers with Core 2 Duo CPUs, 4-6 GB RAM and mechanical disks. Add that this problem didn't always occur but suddenly started happening a while ago. The only thing that has changed and that could reasonably have something to do with this (ie. I can't see how the Forge version could have anything to do with wether a zip is uncompressed successfully or not) is that the modpack.zip has grown in size. Our modpack.zip has always been rather large and is now 77.7 MB in size, uncompressed it's 535 files, 85 folders and 179 MB. I'm not sure how large it was at first but I'm pretty sure it was around 60 MB at some point, no idea at all of how many files and folders it had. Decompression always partly works, some files are unpacked properly while some files are left missing. Possible Causes: The problem may be related to how long it takes for the modpack.zip to unzip and that there is something, possibly in the launcher, that times out and cuts the decompression process short, regardless if it's done or not. It could also be a caching problem, the unzip program often unzips files to a temp folder and then moves them to the final destination. It's possible this operation fails likely also because it's taking too long to finish and is then interrupted for some reason. (this is more of a wild guess, I have no further information that supports this at the moment.) Final Thoughts: I can't really say where I think the problem actually lies, is it something in the launcher that times out, is it the unzip program used that freaks out or is it something completely different? The reason I posted this here is to share my information with the hope that there are others who can add more concrete information to help us all figure this out (I'm assuming this is at least loosely related to at least some of the others who have problems unpacking modpacks and that my case isn't unique). Myself I'm going to do some hands on investigating (I have access to one of the computers involved) and if I find something new I'll add to this. Error Messages: None reported Error Log: Don't have one availible but I'll try to get logs from both of them and add them later if I find something interesting.

I'd like to play with that mod on my Tekkit-server but I haven't tried cause I can't see how it could possibly work (without a LOT of manual tweaking and I mean a whole fucking LOT of tweaking). What did you expect to happen here? It's difficult to miss that the Trains.. 2.1.2b client and server mods are incompatible with Buildcraft 2 and thus would be incompatible with Tekkit as Tekkit inculdes BC 2 so a crash at some point would be the expected behaviour, no? What you got here though is an ID conflict, which you would also be resonable to expect from a mod that includes some 80 new train-entities (locomotives, wagons, etc) when you attempt to install it over Tekkit. I'd expect there to be a lot of manual ID shuffling due to conflicts...which is a pain as you need to make sure you have the same config on both the server and the client(s). I'm a bit puzzled though, you have to be aware of the BC2 incompatibility issue and you're obviously confident enough to try to install a huge mod that modify a ton of base classes into the modpack.jar so you're reasonably not flailing in the dark here and should therefore easily be able to solve a simple ID conflict. I don't quite get why you'd post about it on the Tekkit bug board? Why is an ID conflict generated by an external unsupported (by Tekkit) mod a bug to begin with and how does it relate to Tekkit at all? Personally I might try to install Trains... onto Technic 7.2, that might work a bit better. 7.2 has BC 3 but that's not even really an issue as you can here use the Trains... 3.0.7 client which has no compatibility issues with any BC version (at least not related to the API) (sadly there isn't a 3.0.7 server mod, much less one ported to Bukkit, so this client is a no go with Tekkit). The ID resolver might deal with the ID conflicts but if not, modifying the configs of an SSP client isn't a big deal.

I've been using dynmap for a good while now and can tell you that the real power of dynmap isn't it's live features but rather it's configurability, you can configure it to behave in pretty much any way you want and when you want it. If you crank up the resolution and play around with zoom levels, view angles, etc you can get it to create highly detailed and very beautiful dynamic, or static if you prefer, maps. If you've only read about dynmap, I recomend installing the plugin (very easy) and play around with it (dig deep into the config files that it creates in the plugin folder to see what you can make it do, also check out the plugins for dynmap itself.) However, I'm not here to try to talk you into using dynmap or any other specific mapper. NEI can dump a list of block and item IDs but it wont dump ALL the custom blocks in Tekkit (afaik) due to how some of the mods use block metadata to identify different blocks rather than unique block ID's. The obvious example is Redpower, as it was Eloraam that first came up with/implemented the idea to use metadata this way, that adds a shitload of "microblocks" (all the panels, covers, slabs, etc). You can find the names of the blocks in the redpower.lang file (inside the repower folder in the root of the server), that list contains 2282 entries where the vast majority are tiles (as opposed to items) so trying to create a custom config that spans 100% of Tekkit, regardless of mapper used, will likely drive you insane.