Ignore this post, thought I had an error nailed down. Turns out I was wrong.
Fastcraft has become Slowcraft for me.
There seems to be some form of incompatibility bug regarding chunk gen in other dimensions besides the Nether. After new chunks are generated server CPU usage spikes.
Warmroast suggests Fastcraft hooks as being the culprit: http://i.imgur.com/VhXCVwc.png
Any chance of getting this sorted out? This mod is a must for me.. chunk gen lag is horrible.
Edit: On second thought, this might not have anything to do with Fastcraft. I spent about four hours testing various configurations both with and without Fastcraft installed. Certain Twilight Forest biomes cause some unusually high cpu spikes. Mystcraft was generating TF biomes thus these might be false readings. I'm leaving this post here just in case.
Hold on guiz, let me spend about two hours collecting arbitrary data so that I can demonstrate how having your machines scan the entire ore dictionary twenty times a second is a bad thing. At least this is what I assume and, I use that word on these forums loosely less I be attacked by the oh so wonderful modding community for something else, that Greg's machines are indeed doing this.
Here's an example message of a GT machine spamming the console about lag: WARNING: Possible Lag Source at [-915, 122, 281] in Dimension 0 with 106ms caused by an instance of class gregtechmod.common.tileentities.machines.GT_MetaTileEntity_Electrolyzer
Note that this one is "behaving" though I'd hardly call 102ms for a completely idle machine optimal. There are thirty machines, thirty times one hundred equals three thousand. Three thousand milliseconds equals three seconds. That's three seconds times twenty. So roughly translated and, highly simplified, my server spends a good minute going "Hey Gregtech machines, sup" every cycle.
Please keep in mind that this number spikes substantially for idle machines and, more so for machines currently processing items.
Here's a "horribly cropped" image for you, hopefully it meets your strict standards of image cropping. I'm just a wee little paint using plebeian after all, I wouldn't want to step on the toes of the photoshop using Minecraft playing master race: http://i.imgur.com/Bk0wHGR.png
Since I'm new to Opis, I'm not entirely sure how it's gathering this data nor do I know why Greg's machines read as an error. Mind you, they are the only machines that suffer from this problem. I would assume that it produces data on a per tick basis and, I shouldn't have to explain tick mechanics to a mod developer so I'll leave it up to the peanut gallery to perform their research. If someone wants to elaborate on how Opis is actually recording this information, I'd be delighted. Try to resist your innate urge to patronize others though, it comes across as hostile.
The machine in question is a single plate bending machine with a tin plate in its inventory.
What I can infer from the above picture is that idle GT machines with items in their inventory are spending a great deal of time doing something. When you consider that my factory has hundreds of machines, thousands of ME cables, thousands of energy conduits and, dozens upon dozens of pulverizers/redstone furnaces near constantly running you wouldn't think a single machine doing nothing wouldn't top that list, hm?
Processor usage: http://i.imgur.com/VhWvMVJ.png This jumped up from fifteen to fifty when I activated a small Bauxite processing system.
Mr. laggy platebender: http://i.imgur.com/0PKOgKC.png There it is, driving my tickrate into the bowls of hell. Opis has gone and highlighted it red for me, if it weren't obvious enough.
Here are the internals: http://i.imgur.com/xCCs8NX.png There it sits, a single tin plate. Greg's machine unified it into the Gregtech version of tin plate which I'm sure it's constantly trying to do despite the fact that it has already been done.
Ah yes, cpu usage has dropped by three percent: http://i.imgur.com/RTrbL0u.png I'm sure by removing any items from within the inventories of GT machines would drop this significantly based upon this simple trial. There by using the scientific method, I will run about my base applying my hypothesis in a "real" world environment.
End results weren't producing the cpu usage decline I was hoping for. I'm guessing that I'd have to remove the machines or disable Gregtech and, start the server again. I'm currently not in the mood to do this right now. I came home to relax, not to create in-depth bug reports.
Tickrate improved drastically. The server went from barely sustaining ten tps to a solid comfortable twenty. Opening chests/doors, teleporting, moving about felt fluid and smooth as it should.
Opis wasn't registered any laggy chunks, only a single Ore Washing plant and a logistics pipe chassis were registering.
Based upon this brief experiment, Gregtech machines appear to decrease server tickrate when sitting idle with items waiting to be processed. Perhaps someone with access to Greg's code, or Greg himself can elaborate here. What exactly are these machines doing?
After reactivating my Gregtech machines server tickrate immediately plummets: http://i.imgur.com/yF0RiYC.png
Hopefully that's worthy of recognition. I'm going to go back to what I originally planned on doing after coming home from work. Relaxing.
For anyone else making this connection, please provide your data. I'm sure it would help Greg and, for the love of all things I'm being witty and sarcastic not dickish. Just making sure we understand that.
you mean a lag of 0,001841 sec is huge ?
Are you smoking the ganja?
It's more like 301 seconds of mean time per machine. There are currently thirty machines in my world dropping tickrate to a whopping 3 when processing. Server CPU usage spikes as high as seventy percent while my factory is processing. Any way you look at it, there's something wrong with that. Hell, the entire ME network uses less overall tick time than a single GT Machine....
Certain Gregtech machines are generating inordinate amounts of lag while idling with items in their inventory or processing.
Here's a screenshot demonstrating this: http://i.imgur.com/X339KZa.png
At times they can reach as high as 3500 per machine.. that's pretty insane. I have wire networks thousands of cables long wreaking less havoc on my server tps. This is a single industrial electrolyzer. They do have overclocker upgrades in them, could this be caused by the machines lacking an appropriate internal buffer? Either that or they stop to calculate pi to the billionth digit per each operation. I'm afraid to finish my workshop.. I'll probably get booted off my node for excessively high cpu usage long before that.
PsionicArchon: Do you have rotarycraft installed?
Nope, I haven't gotten around to balancing that one out yet. I stopped at 'this mod includes steel' and allows players to break bedrock.
okay, so I got curious and did some testing.
With Gregtech installed it takes 12 minutes to start my client.
Without Gregtech it takes 3.
So out of the 239 mods and my 128x texture pack, Gregtech alone accounts for 75% of the packs loading time.
I understand Gregtech makes a ton of changes, which I enjoy it and I won't play without Gregtech, but I think some optimization might be called for.
You can blame the lovely (infuriatingly unoptimized) ore dictionary handler for that. Though it does serve a purpose. My log likes to hang out at some quicksilver not melting in an ice desert for ten minutes.
Speaking of the ore dictionary and, unification. Why is this still happening and, what can I do to prevent it from happening.
Rubber production switching over to rubber bars 'magically':
Here's the setup, note that I've detached the pipe for demonstration purposes: http://i.imgur.com/kV6lkHD.png
Here's the byproducts the centrifuge produces. Notice that it's producing Traincraft plastic for some mysterious reason. At one point in time it produced MFR plastic and, occasionally it will revert back to producing MFR plastic: http://i.imgur.com/smN5xIQ.png
Finally, what I've dubbed the rubber bait'n switch. Pay close attention to the MFR rubber bars being produced from the rubber pulp: http://i.imgur.com/4ZTmFvH.png
Yes, this happens across all smelting apparatus.
Here we are, back to the ic2 rubber again: http://i.imgur.com/1sdancr.png
Yes, this is the same server after having restarted it twice.
Oh hey, look who's made a return: http://i.imgur.com/K1NRLDm.png
Something has clearly gone awry with the recipe handler. Is there a simple fix? For something that isn't happening, it sure is happening a lot. Not only is it incredibly frustrating, it requires I restart a server between one and three times that takes ten minutes to start.
Blame mod makers who register their materials in the oreDict but don't use it for their recipes.
Right now I'm blaming both developers. I'm alright with developers making changes so long as they can take into account transitioning. Making sweeping changes that break compatibility locks people out of worlds. I'm currently waiting for this to be resolved before I can actually play... hopefully some compromise can be met. I don't feel circuits break balance that badly and, I'm sure the Mekanism dev can re-enable oreDict compatibility rather easily.
I have (I think), the process isn't exactly straight forward. I enabled some unification options for Osmium in the Unification.cfg which seems to have mopped up one problem.
I just fixed that several UE Circuit Recipes are breaking the balance of GT. And if that is really happening, then Mekanism should use the OreDict for Circuits, since GT Circuits are interchangeable.
I don't have any Unification happen at random.
I have a good thirty plus recipes stored in my Molecular Assembly Chamber from AE that must now be reset. Without the ability to craft control circuits, I have to manually switch their recipes to ic2 circuits as AE will not automatically use ore dictionary equivalents. It's not as if I can't do it or, I lack the resources to make ic2 circuits (I have over 20,000 redstone and, a rubber farm). Perhaps a more difficult control circuit recipe to put it in line balance wise? That way I would only have to replace the control circuit's recipe pattern in the ME Chamber.
Osmium ingots from Gregtech are no longer compatible with the osmium compressor... That's even more recipes I need to change, as well as converting all of my osmium into Mekanism osmium.
Total recipes being overridden by recent changes 60
Gregtech's Osmium is no longer compatible with various Mekanism recipes. There's no way around this seeing as even when processing Osmium in Mekanism's machines I get Gregtech Osmium. I believe I was able to overcome this by mucking about in the Unification.cfg though I'm sure it will randomly switch back upon a server restart.
The newest release of Mekanism is no longer oredict compatible. I can't use IC2 circuits in Mekanism recipes and, since you disabled Mekanism's circuits I can no longer craft any machines form Mekanism.
I have an idea, add an option for allowing machines to produce content from their respective mods. This cross mod incompatibility is driving me damn near close to uninstalling Gregtech. This last week has been especially problematic. I've spent more time running around, cleaning up then I have actually playing the game. I can't build half of the things I need to, I had to swap half of my recipes to alternate recipes and, now I can't build Mekanism machines.
This appears to be the bad month for modded Minecraft. It seems to alternate, every other month produces stable usable releases.. This is not usable. I can't revert either mod now either as the damage has already been done.
After updating to the latest version of Gregtech I can no longer craft control circuits from Mekanism. This has broken a metric ton of my automation as quite a few recipes relied on those circuits.
Where is the config option located for re-enabling this? Between this and, rubber pulp producing rubber bars at random I'm starting to want to kick babies.
I'm running into a bit of an issue with rubber unification that's driving me insane.
For some mysterious reason, when smelted, rubber pulp will randomly stop producing rubber, switching to rubber bars from mfr and, vice versa. Is this addressed in a recent update? It's random enough to occasionally catch me off guard and, on a server reset will usually resolve its self.
Based on my log structure I'm going to assume that it's Gregtech spamming my console with these "registered late" messages.
If so, for the love of the gods can this be disabled or at least re-implimented in such a way that it does not overwhelm the cpu of the vps I'm hosting with. At times it can take me up to an hour re-executing my start script just to get into my server...
Recently, everything simply halts at registering bee species. Ex: http://i.imgur.com/1rkIjqA.png
If this is not a result of Gregtech, can someone in the thread point me in the direction of whomever I should direct the blame. In the mean time, I'm going to quell over an hour of pent up frustration and, reconcile with the possibility that for what ever unknown reason I have lost yet another world due to circumstances beyond my control.
Well, I'm happy to say that using the latest version of Gregtech has revealed that my previous crashing issue was in fact being caused by Natura. Natura is attempting to spawn trees in a Biomes O'Plenty biome and, is failing at doing so. No more Gregtech world generator messages are popping up in my crash logs so, if you did something you have my thanks.
My error logs now correctly point to this: mods.natura.worldgen.BaseTreeWorldgen.generate
Well, one way or another, there probably isn't a fix for this. mDiyo and his team soft-doomed compatibility last month, but they may have hard-doomed it this time...
Then again, I'm also noticing a lot of BoP spam in that first log...
Was the second log generated when you tried to re-load after the first crash? And/or were you able to log into the world after the first crash?
It will continue to crash unless I delete Gregtech/TC/Natura. Though after removing Natura it will run smoothly for about a minute before crashing again. The first log was generated with all three mods installed. The second log was generated upon removing Gregtech + Natura, booting into the world, re-adding Gregtech and Natura, then booting into the world a third time.
I hope this isn't some nonsensical hard coded incompatibility. I spend more time bug fixing then I do actually playing.. I payed for the game, I click the ad.fly links, I should have full reign to install which ever mods in which ever order I see fit. The only thing I'm certain of is that something attempted to generate and, was not able to. If it's a BOP bug I'll have to head over to their thread on the Forge forums. They're not the friendliest bunch...
I'm not even sure if these are Gregtech related. Gregtech world generator is mentioned, as is some nonsense Tinkers Construct compatibility stuff at the end. I know I posted a despawn timer issue a while back but, while testing for that I started getting this when generating worlds/exploring. It's taking precedence as it entirely locks me out of any world it occurs in. If it's malicious code, point me at the class file. I'll happily remove it myself.
Once again, I'm sorry if this isn't a Gregtech issue. It ceases to occur when Gregtech/Natura/TC is removed, which furthers my suspicion. If it is malicious code, I owe the creator a thank you for locking me out of my server.
Default time used to be 5 minutes (vanilla MC, i think) , 6000 ticks.
Unless Greg messed up timing (on his config).
I scanned through every configuration file, nothing mentions changing item despawnrate. I always change Buildcraft's despawn time to 6000 ticks so, there's no reason that should be causing any problems.
Currently I have the despawn time in the GregTech.cfg set to I:ItemDespawnTime=10000 which yields about four minutes and twenty five seconds... If this is supposed to be based on ticks, it's either broken or, I'm living in some form of dimensional distortion.
What is the proper conversion for this: I:ItemDespawnTime=6000 in the GregTech.cfg. I had an explosion destroy several chests, only to find out the hard way that 6000 = one minute... I watched all of my items despawn before my very eyes as I scrambled to sort everything into a new set of chests.
It can't be ticks. 6000/20 = 300 seconds = five minutes /= one minute.
Milliseconds? Nope because, 6000 Milliseconds = 6 Seconds /= one minute
Could another mod be interfering with this configuration option? As a test I increased 6000 to 60000 and, behold, my items did not despawn after 60 seconds.
I've seen pipes not connect but still work: See Feed the Beast Pyramid SSP V3. In that verison of buildcraft, while forestry's biogas engine works right, buildcraft's own combustion engine doesn't graphically appear to connect to the wooden conductive pipe, but I tried it anyway and power still flows.
My point, really, is that bugs happen, and the modded Minecraft player community expects them. What do we do? Try it anyway and see if it works. (Also, we keep the mod's forum page on a browser tab and hit refresh every time we notice the bug again... I'm looking at you Thaumcraft 4!)
Exactly this. As someone creating a mod pack, I constantly have to deal with strange bugs. I'm almost always testing the bleeding edge version of something for weeks before pushing it into my pack. I can't tell you how many times a pipe has or has not connected to something it should or visually connected without actually joining the network (the pipe looks connected yet doesn't function). Dare I mention automating an industrial centrifuge back before logistics pipes had been forked?
Well by the same Process I got the following: Does a Pipe connect to the Blast Furnace? No -> Does the Front of the Blast Furnace even look like it should receive Steam Power? No -> Does the GUI look like it is burning something? Yes -> Insert a bunch of Coal into said burning Slot. Does the other Slot look like an Ingot? Yes -> Insert Ingot into the other Slot. Does the Progress start up? Yes. => No Steam needed. You might have noticed that my two Bronze Furnii and my two Steel Furnii run off said principle of compressing Steam.
Funny thing is, I did follow that process initially. I put coal in the blast furnace with a stack of iron ingots and, nothing happened. It was only when I restarted the server that the blast furnace began to function again. It might be a good idea to implement the same code used for the industrial blast furnace, if I remember correctly it warns you if you haven't set up the machine casings correctly. Mind you I did but, the server wasn't registering it.