Can you add some BC gate conditionals for the capacitor?
As well I seem to have an issue with the Power, I have 28 combustion engines running 4 refineries and then dumping the rest into a big capacitor and if i don't turn off the output on the capacitor it seems to lose power for some reason. Here's a picture of my setup except extended to add 16 more engines on the end: http://imgur.com/3vrQNT3
As well I seem to have an issue with the Power, I have 28 combustion engines running 4 refineries and then dumping the rest into a big capacitor and if i don't turn off the output on the capacitor it seems to lose power for some reason. Here's a picture of my setup except extended to add 16 more engines on the end: http://imgur.com/3vrQNT3
Which version of mc are you using?
There are definitely some issues with power conduits in 1.5.2, I haven't determined if they are effecting 1.6.2 yet. I will get a fix out ASAP but I don't get much time to work on it over the weekend so it might not be fixed until early next week.
As a note to all, if you are raising an issue, could you let me know which version you are using? There where major changes to both the build craft power api and forge fluids api between the two versions so the code is quite different in some places and bugs may only exist in one of the versions.
Which version of mc are you using?
There are definitely some issues with power conduits in 1.5.2, I haven't determined if they are effecting 1.6.2 yet. I will get a fix out ASAP but I don't get much time to work on it over the weekend so it might not be fixed until early next week.
As a note to all, if you are raising an issue, could you let me know which version you are using? There where major changes to both the build craft power api and forge fluids api between the two versions so the code is quite different in some places and bugs may only exist in one of the versions.
i'm on 1.6
the reason i asked for BC gate conditionals btw is so i can have engines turn off when the capacitor is full though i wouldn't mind a 90% conditional too
Just to let you know, I am aware that there are some serious issues with the transfer rate of the power conduits at the moment. I have started looking into it and should have a fix very soon. I don't get that much time to spend on this on the weekend (particularly tomorrow being a dad an all ;-)) so it might be a couple of days.
Hey, Crazypants.
Just a quick little suggestion. Would it be possible to make the reservoir work in a 4*4 and a 3*1 pattern?
There's no real problem with 4*4, just that a 4*4 space with just one pipe coming out of it, just doesn't look right and hurts my ocd a bit :-P
3*1 with a pipe out of the middle is just so nice an symmetrical.
that or it may be more simple to let facades mask the block when placed on it
Hi CrazyPants. As mentioned before i love the mechanics of Your mod and became a quite heavy user of it shortly after the first few releases. I do have a suggestion if You really come around implementing item pipes:
Make them sneaky: You can connect the pipe to any face of a machine and are able to configure which side the machine thinks the pipe is connected to via a GUI on the pipe itself.
Don't know if that makes a lot of sense but it would allow for very compact and non messy factory layouts. I'm thinking especially about forestry machines here
I have just uploaded a new version for 1.6.2 that should fix the bad behaviour of power conduits and the capacitor bank.
The amount of power going through the conduits is now correct (no more machines running at half power) and the behaviour of the capacitor banks are vastly improved.
The cap. banks should now store all excess power on an attached conduit network and only output power if there is a deficit. A really cool use for this behaviour (I just though of this, I haven't actually tested it yet ) is to place the cap bank between your bases main power network and your quarry. In this case, only any excess power from your main network will arrive at the cap bank, and then be passed on to your quarry. Thus you can give your quarry every bit of extra juice you have without slowing down any of your 'main stuff'.
Anyway, this release will need some good testing so anyone who had seen any issues could you please report back to let me know if it is fixed, or if you are still seeing issues.
I will add the config option for the size of the conduits and start work on new features once I have ported this fix to 1.5.2 and am happy that all the functionality implemented so far is (pretty much) bug free.
Just wanted to let you know if you didn't see already: your mod got the top comment on Dire's recent Buildcraft spotlight. It's picking up steam and fast.
---- Minecraft Crash Report ----
// I bet Cylons wouldn't have this problem.
Time: 1/09/13 12:27 AM
Description: Initializing game
java.lang.RuntimeException: Item ID Conflict has occured using ID 8781. The item binnie.extrabees.products.ItemPropolis@30e3f92 has been overwritten by crazypants.enderio.enderface.ItemEnderface@1c6f8bcf
at binnie.core.BinnieCore$ItemData.getRuntimeException(BinnieCore.java:305)
at binnie.core.BinnieCore$ItemData.getRuntimeException(BinnieCore.java:296)
at binnie.core.BinnieCore$Data.check(BinnieCore.java:279)
at binnie.core.BinnieCore.checkBlocksAndItems(BinnieCore.java:244)
at binnie.core.BinnieCore.doInit(BinnieCore.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:540)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:194)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:105)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:697)
at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:232)
at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:506)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:796)
at net.minecraft.client.main.Main.main(SourceFile:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:57)
at net.minecraft.launchwrapper.Launch.main(Launch.java:18)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- Head --
Stacktrace:
at binnie.core.BinnieCore$ItemData.getRuntimeException(BinnieCore.java:305)
at binnie.core.BinnieCore$ItemData.getRuntimeException(BinnieCore.java:296)
at binnie.core.BinnieCore$Data.check(BinnieCore.java:279)
at binnie.core.BinnieCore.checkBlocksAndItems(BinnieCore.java:244)
at binnie.core.BinnieCore.doInit(BinnieCore.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at cpw.mods.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:540)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.sendEventToModContainer(LoadController.java:194)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.common.eventbus.EventHandler.handleEvent(EventHandler.java:74)
at com.google.common.eventbus.SynchronizedEventHandler.handleEvent(SynchronizedEventHandler.java:45)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:313)
at com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:296)
at com.google.common.eventbus.EventBus.post(EventBus.java:267)
at cpw.mods.fml.common.LoadController.distributeStateMessage(LoadController.java:105)
at cpw.mods.fml.common.Loader.initializeMods(Loader.java:697)
at cpw.mods.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:232)
at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:506)
-- Initialization --
Details:
Stacktrace:
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:796)
at net.minecraft.client.main.Main.main(SourceFile:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:57)
at net.minecraft.launchwrapper.Launch.main(Launch.java:18)
It's just an I'd conflict. This has already been answered. Look through the previous posts, I have already posted a non conflicting config for bunnies mods.
Ok, since I can't completely determine which mod (EnderIO, UE, Mekanism or Atomic Science) is the one at fault here, I'm just sharing this crash log rather than posting an actual bug report.
Judging from the stack trace, EnderIO is the most likely culprit, but I can't say that with 100% certainty
The situation is thus: Atomic Science Fission Reactor with EnderIO liquid conduit with facades attached to the bottom, goes a few blocks with facades attached, then attaches to a Mekanism liquid pipe to intentionally be visible (part of the visual design) before reconnecting back up to EnderIO liquid conduits under facades.
So the Atomic Science reactor, via UE, is pumping the radioactive waste out directly to EnderIO just fine. Visually, I saw it enter the EnderIO pipe just fine, it crashed when it reached the Mekanism pipe and the world save is now unloadable.
Just looked through the stack trace. It is certainly a mod interaction bug. Couldn't really say if it was it is my fault, UEs, both or neither
What is happening is this: I call 'fill' on the mekanism pipe, before that call returns, it call fill on my pipe, I then call fill back on theirs, and they call fill on mine, and I call fill on theirs etc etc etc untill it crashes.
My best guess at the moment is that neither mod should be calling fill on an object that has just called fill on it. It seems neither of us considered this situation/interaction and thus haven't guarded against it.
I will look into adding such a check.
Have you lost much with your world not reloading? (I hope you have a recent backup already!)
Just looked through the stack trace. It is certainly a mod interaction bug. Couldn't really say if it was it is my fault, UEs, both or neither
What is happening is this: I call 'fill' on the mekanism pipe, before that call returns, it call fill on my pipe, I then call fill back on theirs, and they call fill on mine, and I call fill on theirs etc etc etc untill it crashes.
My best guess at the moment is that neither mod should be calling fill on an object that has just called fill on it. It seems neither of us considered this situation/interaction and thus haven't guarded against it.
I will look into adding such a check.
Have you lost much with your world not reloading? (I hope you have a recent backup already!)
Oh no, because EnderIO is new I'm still in the testing process with it before I run it on my live worlds. The world it destroyed is named (you can see it in the log actually ) "Flatland - Safe to Destroy"
Oh, a slightly related issue: I've noticed that because when machines attach to EnderIO's liquid conduits they default to bidirectional, if any fluid is in the conduit it can forcibly fill the machine, even machines like the BC refinery which don't normally accept all liquids (I keep getting fuel clogging up my oil tanks )
Perhaps have it default to export mode when attaching to machines?
finally a mod that can have solar panels and doesnt crash my game like IC2 plus i can't power a quarry with IC2's solar panels but i can with this
Hrm, I'm on 1.6.2 and have IC2 Experimental with Compact Solars on BC quarries via Mekanism power cables working just fine... o_O maybe it's the versions you're using?
Head developer for the CivilMagicks former developer for runix
Apparently I'm a horrible person for telling people the the truth. If telling people that MCreater and programs like it are crap and used by lazy people unwilling to learn java then I'm a horrible person and I'm ok with it
As well I seem to have an issue with the Power, I have 28 combustion engines running 4 refineries and then dumping the rest into a big capacitor and if i don't turn off the output on the capacitor it seems to lose power for some reason. Here's a picture of my setup except extended to add 16 more engines on the end: http://imgur.com/3vrQNT3
Which version of mc are you using?
There are definitely some issues with power conduits in 1.5.2, I haven't determined if they are effecting 1.6.2 yet. I will get a fix out ASAP but I don't get much time to work on it over the weekend so it might not be fixed until early next week.
As a note to all, if you are raising an issue, could you let me know which version you are using? There where major changes to both the build craft power api and forge fluids api between the two versions so the code is quite different in some places and bugs may only exist in one of the versions.
the reason i asked for BC gate conditionals btw is so i can have engines turn off when the capacitor is full though i wouldn't mind a 90% conditional too
Make them sneaky: You can connect the pipe to any face of a machine and are able to configure which side the machine thinks the pipe is connected to via a GUI on the pipe itself.
Don't know if that makes a lot of sense but it would allow for very compact and non messy factory layouts. I'm thinking especially about forestry machines here
The amount of power going through the conduits is now correct (no more machines running at half power) and the behaviour of the capacitor banks are vastly improved.
The cap. banks should now store all excess power on an attached conduit network and only output power if there is a deficit. A really cool use for this behaviour (I just though of this, I haven't actually tested it yet ) is to place the cap bank between your bases main power network and your quarry. In this case, only any excess power from your main network will arrive at the cap bank, and then be passed on to your quarry. Thus you can give your quarry every bit of extra juice you have without slowing down any of your 'main stuff'.
Anyway, this release will need some good testing so anyone who had seen any issues could you please report back to let me know if it is fixed, or if you are still seeing issues.
I will add the config option for the size of the conduits and start work on new features once I have ported this fix to 1.5.2 and am happy that all the functionality implemented so far is (pretty much) bug free.
Enjoy!
cp
Just a normal guy. Except I'm not. No, really.
what can I do ??? I don't want delete your mod
http://pastebin.com/PYfnazTV
Judging from the stack trace, EnderIO is the most likely culprit, but I can't say that with 100% certainty
The situation is thus: Atomic Science Fission Reactor with EnderIO liquid conduit with facades attached to the bottom, goes a few blocks with facades attached, then attaches to a Mekanism liquid pipe to intentionally be visible (part of the visual design) before reconnecting back up to EnderIO liquid conduits under facades.
So the Atomic Science reactor, via UE, is pumping the radioactive waste out directly to EnderIO just fine. Visually, I saw it enter the EnderIO pipe just fine, it crashed when it reached the Mekanism pipe and the world save is now unloadable.
What is happening is this: I call 'fill' on the mekanism pipe, before that call returns, it call fill on my pipe, I then call fill back on theirs, and they call fill on mine, and I call fill on theirs etc etc etc untill it crashes.
My best guess at the moment is that neither mod should be calling fill on an object that has just called fill on it. It seems neither of us considered this situation/interaction and thus haven't guarded against it.
I will look into adding such a check.
Have you lost much with your world not reloading? (I hope you have a recent backup already!)
Oh no, because EnderIO is new I'm still in the testing process with it before I run it on my live worlds. The world it destroyed is named (you can see it in the log actually ) "Flatland - Safe to Destroy"
Perhaps have it default to export mode when attaching to machines?
Apparently I'm a horrible person for telling people the the truth. If telling people that MCreater and programs like it are crap and used by lazy people unwilling to learn java then I'm a horrible person and I'm ok with it