BuildCraft|Core

BuildCraft|Core

7M Downloads

Review my BuildCraft 8.0 ideas

asiekierka opened this issue · 13 comments

commented
commented

Correct lags in the mod better.

commented

@TheAndrey If the issue is on the side of plugins, we're not going to fix them. And if removing a feature means players suffer, we're not going to do that. And if you're going to use terrible hacks to fast-forward events to Bukkit because you can't and won't try to get their bugs fixed, just add another terrible hack to remove BlockBreakEvents - it's BlockUtils.isBlockBreakCanceled(), or something.

Put pressure on the plugins which are lagigng your BlockBreakEvent handling, or KCauldron if its wrapper is too slow. On top of that, stop spamming other issues with an unrelated one.

commented

@TheAndrey this would automatically come with a rewrite of that size, especially because people are learning from faults.

commented

@XFactHD - He means one specific lag issue, one which only manifests itself with a highly specific combination of Bukkit plugins and one which "fixing" would negatively implact everyone not using Cauldron. See #3109

commented

I know but other lag issues are fixed through rewrites. And if I recall correctly, BC gave more than one good example of that kind.

commented

and many using it.

commented

Dynamic switching of this kind should not exist. Item and fluid pipes have iron pipes with controllable direction, and power never had one by explicit design.

I say that BC should not get radical changes, the mod should stay reliable but iteratively improved.

commented

"Remove the Valves. They’re a terrible hack."

ouch. ;)

Actually, I wrote that with the intention of nudging along the idea that pipes should be "dumb" objects and all "intelligent" functions like filtering, switching/valving, etc. would be moved to gates or some other attachment. Seems like that's part of what you're suggesting, so that's good.

commented

the limited flow rate of iron [fluid] pipes

I admit, we never found a good solution for that.

a single input/multiple output fluid pipe

You just attach the iron pipe (acting as a diode) to another fluid pipe. Woo!

I don't really understand what you mean by radical changes. Adding fluid flow control actions to gates hardly seems radical compared to, say, programmable robots.

It's not about the objective difference. It's primarily about how far-reaching the change is in terms of how long the previous behaviour was present for and how much it differs from previous BuildCraft design. I guess Lenses and Filters shouldn't have gone in either, but color-sorting in BC was absolutely terrible.

From that perspective, it would probably make more sense to just write a different mod.

Now you understand why I left.

commented

a single input/multiple output fluid pipe

You just attach the iron pipe (acting as a diode) to another fluid pipe. Woo!

That's exactly what I used to do, but it never really worked quite right (again due to flow mechanics and limited flow rate), and talk about a hack.

From that perspective, it would probably make more sense to just write a different mod.

Now you understand why I left.

Indeed, that seemed fairly evident. I do hope someone with your commitment takes up the BC reins.

commented

Wait, you mean dynamic switching just for kinesis pipes, right? I added valve actions for kinesis pipes at SpaceToad's request for "consistency's sake" and because it was often requested by players. For that matter, SpaceToad had already added the 'open' and 'close' actions to gates on all pipes (including kinesis). I just added the side parameter and input/output actions. Originally I thought valves should only be valid on fluid pipes (thus the name). Due to the mechanics of fluid pipes, the limited flow rate of iron pipes, and most importantly the lack of a single input/multiple output fluid pipe, a lot of fluid transport tasks were effectively impossible. Valve actions provided a mechanism to rectify that situation. And, like I said, most of the "intelligent" or dynamic functions were being moved out of the pipes themselves already. That process continued with things like lens and filters, and unless I misunderstood, you suggested the same in regards to lapis and daizuli pipes.

I don't really understand what you mean by radical changes. Adding fluid flow control actions to gates hardly seems radical compared to, say, programmable robots. If you mean that just in general, I'm kind of torn. On the one hand, I think there's a lot of aspects of BuildCraft that could be improved with a major design overhaul of both code and some game concepts. On the other, doing that would likely not only break compatibility, but perhaps more importantly it would break continuity within BuildCraft itself. From that perspective, it would probably make more sense to just write a different mod.

All that said, my contributions to BuildCraft have been minor, and since I've been away for nearly a year, I doubt my opinion would carry much weight (nor should it).

commented

There are two kinds of pipes that I really want.
The first is a paint version of the diamond pipe witch paints items different colors instead of routing them into different directions,
The second is a round robin version of the Lapis Pipe witch paint the first pile go through it red,the second green,ect.
These two can be achieved using currently available pipes in conjunction with gates but it will be very tricky and controling the speed is hard and it makes the overall transport speed very slow.

commented

are these idea's still up for review or planned for 8.0? if not should be closed