...or a dipstick...
Posts by McyD
-
-
When? Last version still spammed a ton of null pointers in the gt.log and still took 50 minutes to load.
-
The only mods I have noticed increasing the loading time is extrautilities and reliquary with 231 mods, these are the only to that significantly increase the loading time.
-
Refined iron was removed from IC2, you have either a mod that has not updated its recipes (which shouldn't matter as all refined iron recipes should show iron as an alternate) or you are using the wrong version of IC2 (more likely).
-
It is probably the issue with Extra-utilities and reliquary (if not more) that I reported a while back that was ignored. I don't know if it is on GT's side or theirs, but it fills the GT log with null pointer errors, when loading the items/recipes from those mods. Just the two mods I had the issue with created 70k+ lines in the log, not hard to see how a big mod or a few medium sizes ones could cause it to become massive quickly.
-
Extrautilities also causes a huge slow down in loading as well. I reported it before, but Greg never said if it was on his side or extrautilities.
-
What MDiyo cause drama!? ... oh wait, that MDiyo, what else does he do again?
-
Bukkit got DCMA'd because wolv was mad that Mojang owned bukkit, and felt like sabotaging the whole thing. Funny thing is, is that Wolvs commit 2yrs ago that that broke the Licensing allowing the whole DCMA to take place.
-
-
BC 6.1 won't happen until it's released, it's just incompatible with 6.0 APIs.
Well, it is official, as of 6.1.2 build-craft is going to RF, so I guess you no longer have to worry about that.
-
A few of the big mods still have not updated to 1.7. Ars Magica, Mystcraft to name a couple.
-
Sorry, my bad, I did not notice the 1.7.2. I assumed since .06 was for 1.7.10 then .07 was as well. Most authors don't go back to older versions on later releases.
-
Seems to be a crash bug on world load with the newest IC2(.630) using .07.
[B#439] [21:18:09] [Client thread/ERROR]: There was a critical exception handling a packet on channel NEI
[B#439] java.lang.NoSuchMethodError: ic2.api.item.IElectricItemManager.charge(Lnet/minecraft/item/ItemStack;IIZZ)I
[B#439] at shedar.mods.ic2.nuclearcontrol.items.ItemToolDigitalThermometer.func_150895_a(ItemToolDigitalThermometer.java:102) ~[ItemToolDigitalThermometer.class:?]
[B#439] at codechicken.nei.api.ItemInfo.searchItems(ItemInfo.java:397) ~[ItemInfo.class:?]
[B#439] at codechicken.nei.api.ItemInfo.load(ItemInfo.java:97) ~[ItemInfo.class:?]
[B#439] at codechicken.nei.NEIClientConfig.bootNEI(NEIClientConfig.java:258) ~[NEIClientConfig.class:?]
[B#439] at codechicken.nei.NEIClientConfig.loadWorld(NEIClientConfig.java:208) ~[NEIClientConfig.class:?]
[B#439] at codechicken.nei.NEICPH.handleSMPCheck(NEICPH.java:109) ~[NEICPH.class:?]
[B#439] at codechicken.nei.NEICPH.handlePacket(NEICPH.java:23) ~[NEICPH.class:?]
[B#439] at codechicken.lib.packet.PacketCustom$ClientInboundHandler.handle(PacketCustom.java:98) ~[PacketCustom$ClientInboundHandler.class:?]
[B#439] at codechicken.lib.packet.PacketCustom$CustomInboundHandler.channelRead0(PacketCustom.java:75) ~[PacketCustom$CustomInboundHandler.class:?]
[B#439] at codechicken.lib.packet.PacketCustom$CustomInboundHandler.channelRead0(PacketCustom.java:62) ~[PacketCustom$CustomInboundHandler.class:?]
[B#439] at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:98) ~[SimpleChannelInboundHandler.class:?]
[B#439] at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:337) ~[DefaultChannelHandlerContext.class:?]
[B#439] at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:323) ~[DefaultChannelHandlerContext.class:?]
[B#439] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785) ~[DefaultChannelPipeline.class:?]
[B#439] at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:169) ~[EmbeddedChannel.class:?]
[B#439] at cpw.mods.fml.common.network.internal.FMLProxyPacket.func_148833_a(FMLProxyPacket.java:77) [FMLProxyPacket.class:?]
[B#439] at net.minecraft.network.NetworkManager.func_74428_b(NetworkManager.java:212) [ej.class:?]
[B#439] at net.minecraft.client.multiplayer.PlayerControllerMP.func_78765_e(PlayerControllerMP.java:273) [bje.class:?]
[B#439] at net.minecraft.client.Minecraft.func_71407_l(Minecraft.java:1591) [bao.class:?]
[B#439] at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:962) [bao.class:?]
[B#439] at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:887) [bao.class:?]
[B#439] at net.minecraft.client.main.Main.main(SourceFile:148) [Main.class:?]
[B#439] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_55]
[B#439] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_55]
[B#439] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.7.0_55]
[B#439] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.7.0_55]
[B#439] at net.minecraft.launchwrapper.Launch.launch(Launch.java:134) [launchwrapper-1.9.jar:?]
[B#439] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.9.jar:?] -
Trying to track down the long loading time, looking at the GT log. I see a ton of null pointers listed from reliquary and extrautilities, seems to be about every item they add, as it is at least a few thousand lines worth, 24k just for reliquary. I don't know if it is a GT issue or with their mods, but thought I would put it out here, as it probably needs to be addressed anyway.
All similar to:
GT_Mod: Activating OreDictionary Handler, this can take some time, as it scans the whole OreDictionary
java.lang.NullPointerException at xreliquary.items.alkahestry.AlkahestryRedstoneRecipe.func_77569_a(AlkahestryRedstoneRecipe.java:23)
Edit: Removing both mods drops the pack load time from 52 minutes to 19.
-
2014th page, anybody else notice that's the same as the current year number?
well, I don't think that will happen again.
-
Indeed my good sirThat is only 37 mods... where are the other 53 you claim?
-
I smell a troll.
Takes 21 minutes first-time load and 11 minutes each after, on a single-core 1.8 GHz Celeron with 2 GB DDR (400 MHz), 90 GB 5400 RPM HDD, and onboard Intel video. Using 35 mods. (My awful laptop). If yours takes longer, then you have clearly either fucked up ROYALLY to the point of scientific fascination, or you're lying outright and exaggerating the load time.
(Said laptop gets 2-5 FPS on minimal settings, btw)I report an issue and you think I am a troll and lying... nice. I reported the previous load time of 20+ minutes months ago, look back on the thread and find it if you think I am lying about that as well. And Adding one mod to the pack and having the load time increase by 10x, how is that me messing anything up? I think you would be the troll, if you don't have anything constructive to add, then don't add anything.
I have tried to track down what is causing the long load time since 1.6.4, but have not had any luck.
My computer is a AMD Phenom II @ 4.0, 10gb ram, and a Gforce 650 TI Boost. BTW the dedicated server is a quad core Xeon @ 4.3, 32 gig of ram, SSD in raid on centos 6.5, running nothing but the pack and mysql, it only loads about 2 minutes faster.
Current mod list for the pack,
though it is not100% up to date as I just updated it,the pack to 1.7.10 a few days ago and still am in the process of updating it. Anything with an asterisk is not currently in the pack, as the list covers the pack back to 1.5.2.Here: https://docs.google.com/spread…YU0xTEE&usp=sharing#gid=0 -
I know the mods are part of the problem, Gregtech is the rest :). I have 156 mods, and without Gregtech a 5 minute load time. I run a private pack server, every mod is used, otherwise it wouldn't be in the pack.
-
Congrats Greg, new record, 52 minutes to load my pack with the newest Gregtech installed, up from 1.6.4's record of 22 minutes.
-
yeah, thanks for repeating what I found out 5 posts ago.