So now we have to have a redstone signal for the itemducks/fluidducks to work? how stupid is that? or we have to have a chest next to it to set the output? i hope this gets fixed cause it is STUPID! i am uninstalling this mod till you fix this!
Well no it's not stupid... It's the way it should be considering how simple they are to use instead of using Buildcraft pipes with a redstone engine and then a redstone single.
Using the latest DireWolf20 1.6.4 pack (1.0.4 - TE3 b9 and MineFactoryReloaded 2.7.4B1-215). Attempting to open a Harvester connected to an output ItemDuct (with or without a Servo installed) results in a client crash.
Update: On the fourth or fifth try (different orders of placement) t stopped crashing. I had gone and fixed up other areas as well, but there was something wrong there somewhere.
The main difference now is the harvester has a tank next to it to pipe the sludge into. I'll update if I can reproduce the earlier crash.
Is it possible to run the latest version in a development environment (Eclipse)? Previous versions (b7 and below. Never tried b8) ran fine when placed in mcp/jars/mods/ and ChickenCodeCore was present.
Caused by: java.lang.NoSuchFieldError: field_71957_Q
at cofh.CoFHCore.registerOreDictionaryEntries(CoFHCore.java:139)
Full Log:
---- Minecraft Crash Report ----
// Everything's going to plan. No, really, that was supposed to happen.
Time: 18/12/13 19:22
Description: There was a severe problem during mod loading that has caused the game to fail
cpw.mods.fml.common.LoaderException: java.lang.NoSuchFieldError: field_71957_Q
at cpw.mods.fml.common.LoadController.transition(LoadController.java:156)
at cpw.mods.fml.common.Loader.loadMods(Loader.java:523)
at cpw.mods.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:183)
at net.minecraft.client.Minecraft.startGame(Minecraft.java:473)
at net.minecraft.client.Minecraft.run(Minecraft.java:808)
at net.minecraft.client.main.Main.main(Main.java:93)
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:131)
at net.minecraft.launchwrapper.Launch.main(Launch.java:27)
Caused by: java.lang.NoSuchFieldError: field_71957_Q
at cofh.CoFHCore.registerOreDictionaryEntries(CoFHCore.java:139)
at cofh.CoFHCore.preInit(CoFHCore.java:98)
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:545)
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:201)
at cpw.mods.fml.common.LoadController.propogateStateMessage(LoadController.java:181)
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:112)
at cpw.mods.fml.common.Loader.loadMods(Loader.java:522)
... 10 more
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- System Details --
Details:
Minecraft Version: 1.6.4
Operating System: Windows 7 (amd64) version 6.1
Java Version: 1.7.0_25, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 777154104 bytes (741 MB) / 1037959168 bytes (989 MB) up to 1037959168 bytes (989 MB)
JVM Flags: 3 total; -Xincgc -Xmx1024M -Xms1024M
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: FML and Forge are installed
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
FML: MCP v8.11 FML v6.4.45.953 Minecraft Forge 9.11.1.953 16 mods loaded, 16 mods active
mcp{8.09} [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized
FML{6.4.45.953} [Forge Mod Loader] (bin) Unloaded->Constructed->Pre-initialized
Forge{9.11.1.953} [Minecraft Forge] (bin) Unloaded->Constructed->Pre-initialized
CodeChickenCore{0.9.0.7} [CodeChicken Core] (minecraft.jar) Unloaded->Constructed->Pre-initialized
Stucuk_MCICraft{1.0.1} [MCICraft] (bin) Unloaded->Constructed->Pre-initialized
CoFHCore{2.0.0.b9e} [CoFH Core] (CoFHCore-2.0.0.b9e.jar) Unloaded->Constructed->Errored
Stucuk_MCICraft_Machines{1.0.1} [MCICraft Machines] (bin) Unloaded->Constructed->Pre-initialized
Stucuk_MCICraft_Redstone{1.0.1} [MCICraft Redstone] (bin) Unloaded->Constructed->Pre-initialized
CoFHLoot{2.0.0.b9e} [CoFH Loot] (CoFHCore-2.0.0.b9e.jar) Unloaded->Constructed->Errored
CoFHMasquerade{2.0.0.b9e} [CoFH Masquerade] (CoFHCore-2.0.0.b9e.jar) Unloaded->Constructed->Errored
CoFHSocial{2.0.0.b9e} [CoFH Social] (CoFHCore-2.0.0.b9e.jar) Unloaded->Constructed->Errored
CoFHWorld{2.0.0.b9e} [CoFH World] (CoFHCore-2.0.0.b9e.jar) Unloaded->Constructed->Errored
ForgeMultipart{1.0.0.219} [Forge Multipart] (ForgeMultipart-dev-1.6.4-1.0.0.219.jar) Unloaded->Constructed->Pre-initialized
ThermalExpansion{3.0.0.b9e} [Thermal Expansion] (ThermalExpansion-3.0.0.b9e.jar) Unloaded->Constructed->Errored
McMultipart{1.0.0.219} [Minecraft Multipart Plugin] (ForgeMultipart-dev-1.6.4-1.0.0.219.jar) Unloaded->Constructed->Pre-initialized
ForgeMicroblock{1.0.0.219} [Forge Microblocks] (ForgeMultipart-dev-1.6.4-1.0.0.219.jar) Unloaded->Constructed->Pre-initialized
Oh no! Whatever will I do? I better change the entire balance structure of the mod to cater to the whims of a single player!
...seriously, apply the servo, change your settings. By default, the RS signal defaults to High. That is quite intentional. There's no "fixing" to be had here.
Ok i did rant a little bit to much sorry.. where in the config can i change it?
Oh, it is so awsome, I starting play again on 1.6.4 only for starting with the TE.
And i have one sugestion, if you plannig add equivalent of IC2 Batpack, can you make it something that you can put on yours legs? Batterybelt or something? I know TE is mod "in place of" IC2 but it would be a good to be able use TE tools and IC2 in the same time. (and with Gravi Chest Plate, Googles of Reviling and Boots of the Traveler i always feel my legs naked).
Get a powersuit, change the config around for balance, and your good to go.
There is no config. First upgrade the output with a pneumatic servo. Then use an empty hand and change the redstone setting (on the tab to the left) to either always on, only on when a redstone signal is active and on unless there is a redstone signal.
Overall I do think that the default option should be to output as soon as you upgrade the duct. Why else upgrade it to begin with?
Swapping the default to output leads to the situation where someone might be applying the servo for a filter from a tank that holds multiple fluid types and then BAM they start draining their tank and they don't want to. We're playing it safe.
Oh, it is so awsome, I starting play again on 1.6.4 only for starting with the TE.
And i have one sugestion, if you plannig add equivalent of IC2 Batpack, can you make it something that you can put on yours legs? Batterybelt or something? I know TE is mod "in place of" IC2 but it would be a good to be able use TE tools and IC2 in the same time. (and with Gravi Chest Plate, Googles of Reviling and Boots of the Traveler i always feel my legs naked).
There is no config. First upgrade the output with a pneumatic servo. Then use an empty hand and change the redstone setting (on the tab to the left) to either always on, only on when a redstone signal is active and on unless there is a redstone signal.
Overall I do think that the default option should be to output as soon as you upgrade the duct. Why else upgrade it to begin with?
I have over 100 item ducks and fluid ducks... this is gonna be fun since i have to do it every single output :/ thanks for the help though
With the new cells and portable tanks comes the opportunity for a tool that works like a powered bucket. It should have slots for a power cell and a portable tank. When facing a liquid reachable by bucket hold RMB to grab buckets and place them in the internal tank if possible for some RF/bucket. Speed could depend on the cell's power output. It should also have an internal energy buffer that drains from the cell to allow full operation if for a brief period. When the tank is full you swap a new one in and keep going.
00:59:38 [INFO] Registering Forge Packet Handler
00:59:38 [INFO] Succeeded registering Forge Packet Handler
00:59:39 [WARNING] The mod id CoFHCore attempted to register channels without specifying a packet handler
@bnod23: Item & Fluid Ducks? But seriously I get what you're saying, had to do that with forestry a couple times. Sorry for being a grammar & spelling Nazi.
I was getting the exact same error as you. I updated to the latest build just recently uploaded to Curse Forge and it seemed to work.
So try updating to CoFH Core 2.0.0.b10a and Thermal Expansion 3.0.0.b10a. Will probably fix your problem.
1. Is anybody else with b10 getting lots and lots of insta-closing GUI errors associated with trying to open TE machine GUIs? They've come back worse--much worse--for me with this version. The bright side is the GUI errors are so bad that I've actually had crashes, and so have been able to generate a crash report for the bug tracker. But I'm wondering if I'm alone.
2. Are fluiducts supposed to require pneumatic servos to operate now? I keep seeing posts that suggest that they ARE necessary, that attaching a fluiduct should NOT automatically cause fluids to flow. But when I attach fluiducts to an aqueous accumulator, water instantly starts pumping through without installing a servo. Again, is this just me, or is this expected behavior?
3. How do you make a flux crystal? I wanna have fun too ...
2. Are fluiducts supposed to require pneumatic servos to operate now? I keep seeing posts that suggest that they ARE necessary, that attaching a fluiduct should NOT automatically cause fluids to flow. But when I attach fluiducts to an aqueous accumulator, water instantly starts pumping through without installing a servo. Again, is this just me, or is this expected behavior?
TE machines will auto-eject into ducts, chests, and so on. That includes the Aqueous Accumulator. That's normal.
Railcraft tanks, Buildcraft pumps, and Ender Storage ender tanks also do not require a servo. Buildcraft quarries I haven't tested, because I just throw an ender chest directly on top of the quarry instead.
I have a very odd puzzle. I have two test setups rigged on my test server. This is with b10a.
Here's the first:
Simple, straightforward; vanilla chest via duct to Immibis Advanced Machines rotary macerator, to induction furnace, to output vanilla chest. No servos in use on any connection. Each machine has a switch on the side setting it to continuous power, which also handily powers the duct connections on the bottom of each machine and the bottom of the input chest. Drop ore in the chest, it is extracted by the duct, passes through the machines, ore ends up in the output chest, bam, simple, no fuss.
Now let's look at test rig #2:
Different POV here so that all the pipe ends are visible. (I've tried to make everything important visible in both screenshots.) You can see the redstone torch powering the duct connection to the chest, which I have tried on top, bottom and several sides of the chest. We have a vanilla chest again serving as injection point into a loop of an autonomous activator and a terrain smasher, both set active on redstone high, both fired in turn by a sequencer set to 5 seconds interval. Regardless of connection setting, servo, redstone state, etc, the chest's duct connection will not extract from the chest. If I manually put a block of dirt into the Activator's inventory, the Activator obediently places it the next time it fires, and the smasher breaks it a couple of seconds later; then either it vanishes, or the duct will not extract it from the smasher, I don't know which. If I break the smasher, I don't get the dirt block back, but I don't know whether I should because I don't think a smasher has an inventory as such. Certainly no inventory is visible in its GUI. (Perhaps it should have one, even if only a single space?)
These two test rigs are only maybe fifteen blocks apart. In one, ducts work fine. In the other, they apparently don't.
To say the least, this is peculiar. Any insights.....?
@ Caermaster Maybe a stupid question, but where is the output inventory?
There isn't one. It's purely a test rig. The idea is for one or two blocks to flow around in a loop, place -> break -> place -> break. the input chest is just there to iinject a few blocks into the loop. This test rig was actually set up to troubleshoot permissions because for a long time, I couldn't get Autonomous Activators to place blocks inside the borders of a Towny town.
Well no it's not stupid... It's the way it should be considering how simple they are to use instead of using Buildcraft pipes with a redstone engine and then a redstone single.
Update: On the fourth or fifth try (different orders of placement) t stopped crashing. I had gone and fixed up other areas as well, but there was something wrong there somewhere.
The main difference now is the harvester has a tank next to it to pipe the sludge into. I'll update if I can reproduce the earlier crash.
Full Log:
Minecraft Info - Game Requirements - Minecraft Screensaver - MCI Craft
Using the latest version TE3 and Waila (given that it's mentioned in the error)
Ok i did rant a little bit to much sorry.. where in the config can i change it?
Get a powersuit, change the config around for balance, and your good to go.
Can't replicate this. Be sure and update WAILA and NEI.
Swapping the default to output leads to the situation where someone might be applying the servo for a filter from a tank that holds multiple fluid types and then BAM they start draining their tank and they don't want to. We're playing it safe.
We are not an IC2 replacement.
However, that is coming.
I have over 100 item ducks and fluid ducks... this is gonna be fun since i have to do it every single output :/ thanks for the help though
00:59:38 [INFO] Succeeded registering Forge Packet Handler
00:59:39 [WARNING] The mod id CoFHCore attempted to register channels without specifying a packet handler
With b9e. Is this important?
I was getting the exact same error as you. I updated to the latest build just recently uploaded to Curse Forge and it seemed to work.
So try updating to CoFH Core 2.0.0.b10a and Thermal Expansion 3.0.0.b10a. Will probably fix your problem.
1. Is anybody else with b10 getting lots and lots of insta-closing GUI errors associated with trying to open TE machine GUIs? They've come back worse--much worse--for me with this version. The bright side is the GUI errors are so bad that I've actually had crashes, and so have been able to generate a crash report for the bug tracker. But I'm wondering if I'm alone.
2. Are fluiducts supposed to require pneumatic servos to operate now? I keep seeing posts that suggest that they ARE necessary, that attaching a fluiduct should NOT automatically cause fluids to flow. But when I attach fluiducts to an aqueous accumulator, water instantly starts pumping through without installing a servo. Again, is this just me, or is this expected behavior?
3. How do you make a flux crystal? I wanna have fun too ...
Here's the first:
Simple, straightforward; vanilla chest via duct to Immibis Advanced Machines rotary macerator, to induction furnace, to output vanilla chest. No servos in use on any connection. Each machine has a switch on the side setting it to continuous power, which also handily powers the duct connections on the bottom of each machine and the bottom of the input chest. Drop ore in the chest, it is extracted by the duct, passes through the machines, ore ends up in the output chest, bam, simple, no fuss.
Now let's look at test rig #2:
Different POV here so that all the pipe ends are visible. (I've tried to make everything important visible in both screenshots.) You can see the redstone torch powering the duct connection to the chest, which I have tried on top, bottom and several sides of the chest. We have a vanilla chest again serving as injection point into a loop of an autonomous activator and a terrain smasher, both set active on redstone high, both fired in turn by a sequencer set to 5 seconds interval. Regardless of connection setting, servo, redstone state, etc, the chest's duct connection will not extract from the chest. If I manually put a block of dirt into the Activator's inventory, the Activator obediently places it the next time it fires, and the smasher breaks it a couple of seconds later; then either it vanishes, or the duct will not extract it from the smasher, I don't know which. If I break the smasher, I don't get the dirt block back, but I don't know whether I should because I don't think a smasher has an inventory as such. Certainly no inventory is visible in its GUI. (Perhaps it should have one, even if only a single space?)
These two test rigs are only maybe fifteen blocks apart. In one, ducts work fine. In the other, they apparently don't.
To say the least, this is peculiar. Any insights.....?
I can't seem to find anything linking to the cofh website, might not be looking hard enough.