before I put this this in a bug thread... BC lasers
- Thread starter DREVL
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Eh. The inefficiency isn't that big of a deal. Even with TE Redstone Energy Cells, folk let a massive amount of energy go to waste because boiler efficiency doesn't give a damn; and before Thermal Expansion it was pretty much a given that you'd send more energy into the aether than actually use. The real frustration is that it's implying a sort of design that BuildCraft itself doesn't really handle very well on its own -- you can work around these problems by decentralizing your engines and triggering them on demand, but you either need Forestry or ThermalExpansion for a high-density renewable fuel, RailCraft or Factorization for baseline power load, Applied Energistics or ThermalExpansion or EnderChests for bulk item mobility once you've quarried every chunk near your base, or some other mods.
((And I think whoever did the math on balancing the energy loss needs to look at it again. The loss on the consumers is something you can handle, but the powerProvider loss on wooden conductive pipes really adds up if you're using a lot of small engines... which BC is biased toward.))
It's possible, but the infrastructure necessary to do so is extreme (two iron AND gates, some red pipe wire, and for best results usually a powered engine).
Yeah. There are a few item management things that I'll still fall back on Gates to do, such as counting items where a full ComputerCraft or MFR PRC would be unnecessary (or not showy enough), but the greatest strength of BuildCraft has been its liquid support, and I'm increasingly doubtful it'll keep that forever (adding comparator support to tanks would alone negate most of the benefit).
ThermalExpansion and MineFactory Reloaded machines have a separate internal power buffer, which is not affected by powerPerdition. If you connect to them with conductive pipes, the wooden pipe will usually have some passive loss, however.
This can overflow because of transit time.
I wanna like it. I wanna be able to BUILD a logistics pipe system, not have magical supertech pipes.
Hence the necessity of the AND gate, which leaves enough spare conditions for a redstone latch/reset.
But that's ridiculously complicated and expensive for what it does (not to mention the several diamonds involved in the assembly table), so no one's going to bother with it.
Part of the problem is that the creator of buildcraft (spacetoad) has been gone for a while. The people keeping buildcraft up to date have their own mod.. (sirsengir - forestry, and covertjaguar - railcraft) so I doubt we are going to see someone revamp the mod like it needs. There isnt someone who thinks this is my baby and I need to make it good. Its a basis for other mods. TE, Railcraft, Forestry.. They all make buildcraft what it is.. Its never going to be more then a gateway into the mods they really care about...
I'm not sure how you can overcome this fundamental problem without making the system insanely low volume or using TE-style insertion pipes. The problem is as the final object to fill the internal buffer is sliding into place another approaches and is routed into the object's feed. Even the T-junction style of pipes can't solve this problem without insertion pipes.
Maybe I don't know what you're talking about. Is this something new?
It is up to every mod author's discretion whether or not they adopt this new model. So far, MFR and TE have not done it (though TE has gone ahead and made conduits 100% lossless too). However, TE is going through a major rework currently for 1.6, and nobody knows whether or not they plan to make the switch. As for what MFR plans to do in 1.6, I know even less.
Looks like we need a switching power conduit with built in "has work -> allow power to flow" gate condition to overcome this new way of wasting energy. Or just go for the boring "I don't care about loss because I just add a constantly on boiler setup everywhere", but I prefer smaller independent systems (that so far worked fine with a few gates).
Nothing newer than the Redstone Update to vanilla. The idea is to exploit the known rate engines or autarchic gates (one stack every 26 ticks for combustion engines at blue status, one item a little more often than twice a second for autarchic gates) extract items from the attached inventory, and then use carefully placed gates, or vanilla redstone circuitry, or a combination thereof, to trigger trigger the engines or autarchic gates. This way, you can prevent items from even entering the pipe system if there is no valid place for it.
There are a lot of different ways to solve this, depending on transfer distance and number of surrounding machines. The most generic is a RS-Latch based system. If you have a very long pipe run, it makes more sense to use the first item in the pipe as a timing mechanism, and if you want to transfer full stacks at a time, an edge detector or other triggered pulse solution is a better option.
But these are all terrible solutions for any problem other than a need to show off, when AE or Insertion Pipes exists.
Insertion Pipes are unnecessary, Buildcraft will bounce items back into the pipe if there is no room for them in the inventory. At least until it runs out of untraveled pipe outlets. The behavior you describe has not existed for over six months.
Oh cool. That's a great change! I had no idea. To be fair though... I do read your changelogs and unless this is worded very differently than you expect, you guys didn't announce this change as a major feature? I certainly think that's a game changer for BC pipes; it really does change how you can build BC systems.
I hope that it's clever about direction picking as it comes out of the T-junction post bounce, otherwise the items could fold back on themselves traversing a previous route and presumably hit the wooden pipe they came from? Does this mean there is a wee bit more intelligence for items traversing a junction now, like they bias for branches that contain more untested pipe outlets?
Personally, I wrote off your piping system shortly after our transition to 1.4.7 because I was so frustrated with my inability to make even simple systems work reliably due to limitations like that, and then Vanilla radically reduced the cost of reliable automation and AE started rising to dominance as the expensive variant of automation. I sorta only used it for very short vertically oriented jobs. But I've resolved to use primarily buildcraft and logistics pipes for this go-around on my map, so yay bonus functionality.
Related question: do you guys think that you're going to start re-costing more sophisticated automation tools like sorting pipes given that now sorting systems for stackables are easy to create with entirely vanilla parts? For example, wooden pipes don't have a base slow mode ala hoppers, nor can they do typed gating via comparators. Do you know if there are plans to upgrade them a bit to keep pace with Vanilla's standard?
They blacklist any output they have already visited. So its impossible for them to back feed. If all outputs are blacklisted the item will be ejected from the pipe.
I fail to see the need to "match" any such vanilla "standard". From my point of view pipes are still the more powerful (and much cheaper even with gates) of the two.
As for the lack of changelogs, Github is the final authority. The changelogs published by Sengir with public releases often suffer from a lack of the right hand knowing what the left is doing.
I fail to see the need to "match" any such vanilla "standard". From my point of view pipes are still the more powerful (and much cheaper even with gates) of the two.
As for the lack of changelogs, Github is the final authority. The changelogs published by Sengir with public releases often suffer from a lack of the right hand knowing what the left is doing.
CovertJaguar, I think the problem is that most people that use pipes don't have the room for overflow prevention loops, which with buildcraft pipes are seriously neccesary because items just don't bounce back like items in pneumatic tubes do/did.
Don't really see how that's a valid point, being that minecraft is virtually infinite. Plenty of room, just requires planning.
For example, if everything enters your "base" via an Ender Chest, put enderchests down as the final destination. No loopback needed.
One TE insertion pipe to ensure items go into the last valid inventory, then one pipe, then enderchest. Not much space really...
For example, if everything enters your "base" via an Ender Chest, put enderchests down as the final destination. No loopback needed.
One TE insertion pipe to ensure items go into the last valid inventory, then one pipe, then enderchest. Not much space really...
Is there any chance of getting insertion pipes in vanilla-BC for other situations where they are necessary?
Immibis you already know the answer to that. Don't ask loaded questions. Buildcraft has a policy of not incorporating key items from sub-mods. If Flow wanted to add the Insertion Pipe to BC, he could. Besides the Diamond Pipe can function identically for 90% of all situations.