Wait, what? I am not following whole backscene of modding (no interest into that) but from what I can gather people still love BC D:
Spacetoad is back to modding
- Thread starter xbony2
- Start date
- Status
A big thing here is the difference in design. BC power is push-based, while RF is pull-based. So with Buildcraft, your TileEntity receives a doWork call saying here's some energy, while with RF you tell the power network you want energy. Nothing too special here. You want to store the energy? You get a float from PowerHandler.useEnergy telling you how much power you received. That power is now outside the control of Buildcraft. This is what you store (which you already knew since that's literally how you had to store the power in your machines when you were using the BC API). You want to accept multiple energy types? No problem... You have an internal energy variable, and when you receive power from any of the power frameworks you use, you store it there. PowerHandler is final. It makes it so that Buildcraft power is handled in a certain way. There's no issue there. PowerHandler has a setPerdition function for setting the PerditionCalculator to calculate how much power is lost over time. PerditionCalculator is NOT final, and the only restriction on the PerditionCalculator used is that the new energy after having perdition applied is less than the old energy, as stored in a float.
I have traced through the power API in Buildcraft. I haven't for Thermal Expansion since the actual code for that is not public, only the interface and a reference implementation are. Buildcraft uses 3 SafeTimeTrackers. For all I know, Thermal Expansion could be using 30 TimeTrackers (which is virtually identical to the Buildcraft SafeTimeTracker)
I've been following SpaceToad's stuff on the git with some interest. He is doing a good job of making a polish run on stuff, it seems, which is a commendable goal with a project like BuildCraft (where there are a lot of moving parts and they've been moving for a long time). I'm looking forward to seeing where and how it all goes.
The discussion otherwise in this thread is a great example of how differing viewpoints, priorities, and entire teams of folks end up interacting "under the hood" to make all the parts (the mods) in a mod pack function. Sometimes there are accommodations and sometimes what has worked in the past changes based on the priorities and goals of the people who work on this stuff. There's nothing wrong in that, I think, although it can sometimes be a jarring experience. When familiar mechanics change, an evaluation is sometimes made that weighs the new mechanics versus just switching to an entirely different platform. Sometimes that sticks. Sometimes it doesn't. For what it's worth, personally I mix and match almost arbitrarily each time I start a new world, so I've been all over the place on a lot of this. =)
Now, moderator voice: I appreciate continued civility and an elevated tone of discussion. We can agree to disagree on some things but let's keep our noses clean here and not get personal about this, folks. Thank you.
The discussion otherwise in this thread is a great example of how differing viewpoints, priorities, and entire teams of folks end up interacting "under the hood" to make all the parts (the mods) in a mod pack function. Sometimes there are accommodations and sometimes what has worked in the past changes based on the priorities and goals of the people who work on this stuff. There's nothing wrong in that, I think, although it can sometimes be a jarring experience. When familiar mechanics change, an evaluation is sometimes made that weighs the new mechanics versus just switching to an entirely different platform. Sometimes that sticks. Sometimes it doesn't. For what it's worth, personally I mix and match almost arbitrarily each time I start a new world, so I've been all over the place on a lot of this. =)
Now, moderator voice: I appreciate continued civility and an elevated tone of discussion. We can agree to disagree on some things but let's keep our noses clean here and not get personal about this, folks. Thank you.
BuildCraft didn't really change. The change was the addition of an alternative that a lot of players found more intuitive and easier to use. We don't really mind that players run off to Thermal Expansion. The players that switch to Thermal Expansion never really used BuildCraft power anyway. They used a simplified version of MJ power as defined by Thermal Expansion.
What we do find a little bit unfair is the negativity that follows when players switch sides. It reminds me of the, "I'm quitting" posts on the wow forums. For some reason they dump all their shit in the laps of the people that choose to stay. "What, you still use BuildCraft, but that sucks!"
Last edited:
Which I repeat the SafeTimeTrackers are only there because it was practically forced on us to support tickless operation in order to keep the peace.
The old API didn't support tickless operation either, but it was kind of possible via a bastardization of the PowerFramework API. A modification which utterly broke the PowerFramework's ability to do its job I might add. The new API removed PowerFramework completely because we no longer saw the need to allow you to switch to redstone pulses to power machines.
Last edited:
Considering almost everyone used TE conduits at that point, that was a pretty meaningless change, it was the passive power drain that was nothing but a annoyance that irritated alot of people myself included. After the change the TE conduits were still superior in every possible way, so most people got nothing but a nerf and zero benefit.
What nerf? There was no nerf. The power loss was already there, the change to lossless pipes reduced the total loss. Sure... the conduits were superior prior to the change. After the change, conduits were just more expensive to make.
Reduced it by like 99% in fact. I don't know about you, but I call that a buff.
This seems to be a problem caused by having a vision and sticking to it. And there is nothing wrong with that.
BC has a vision for how power should run. KL politely disagreed with said vision and made his own. The larger community looked at both and many/most chose RF. That's no indictment of MJ. It's just that people preferred what they found to be a better system for their needs.
As I see it there is no reason to look down on either vision or system. Both have their strengths and their flaws.
As for SpaceToad returning? I can't wait to see what he'll bring to BC. I want a reason to re-add it to my private modpack again!
BC has a vision for how power should run. KL politely disagreed with said vision and made his own. The larger community looked at both and many/most chose RF. That's no indictment of MJ. It's just that people preferred what they found to be a better system for their needs.
As I see it there is no reason to look down on either vision or system. Both have their strengths and their flaws.
As for SpaceToad returning? I can't wait to see what he'll bring to BC. I want a reason to re-add it to my private modpack again!
I still have not heard of a single instance (other than Thermal Expansion itself) of any mod removing Buildcraft support.
I wasn't claiming that mods moved from MJ support. Just saying that many players did.
As for KL removing BC support? That, I believe, was a move for operational efficiency.
As to power loss being already there, I sure as hell never noticed it prior. I had refineries/factories suddenly going from pulling 0 MJ when not in use to suddenly pulling nearly 50MJ from my batteries to do nothing but sit there.
Conduits were plenty superior after the change. Did BC pipes intelligently split power to all connected devices? No. Did BC pipes store energy as a buffer? No. Could you disable connections with just a wrench? No. As for price, both of them are so cheap that cost is irrellevent.
Kind of funny how this thread from " O hai, welcome back SpaceToad" went into "The Hand Written History of BuildCraft Changes during SpaceToad's absence".
Wish Toady himself would peek in here and speak his mind on the matter c:
Wish Toady himself would peek in here and speak his mind on the matter c:
Yes, KingLemming himself implemented this change into Buildcraft. Unfortunately it had to be implemented in every mod that used the Power API as well. This was one of the reasons we needed a new API.
I don't even know what that means, but my best guess tells me you've never seen a BC energy storage loop.
I can disable them with my fist! The wrench is optional.
Swing and a miss. RF is push-based. The difference being that it doesn't force a doWork call on you upon reception, or a required loss. It's a freeform API. Having to call useEnergy to convert from MJ internally is a kludge - it means that the received MJ has already been stored, passed through the PowerHandler bureaucracy, and been inspected, validated, and taxed.
I also never had to call useEnergy with the old implementation. The lack of IPowerReceptor's finality in BC 3.x meant that I could do what I wanted with the power upon reception - store the quantity directly in a variable. I had to implement some functions that were never called (doWork) to jive with the interface, but meh, fair enough. Was this playing with fire? Possibly, if you don't know what you're doing. Worked fine for me.
PerditionCalculator is not final, yes. However, the restriction is that it can't be lossless, or it's a silent fail.
Anyways, despite whatever people might think about BC, MJ, and RF, the fact is this: BuildCraft has improved by leaps and bounds since CJ effectively took it over (and don't downplay that CJ, you pretty much wrote a lot of the new stuff single-handedly). Don't let the recent disagreement in modder vision - which is what this is - tarnish that accomplishment.
TL,DR: Stop yelling at CJ. He done good.
The irony is that Thermal Expansion actually still have support for BuildCraft power. The conduits can directly power any machine based on BC power.
I honestly wish the support was dropped completely. There are many players here that I'm sure would miss the ability to use Forestry, RailCraft and systems from other mods. Maybe some would have returned to BuildCraft to see what all this new stuff is about. Instead Thermal Expansion is holding BuildCraft hostage.
If i'm thinking of what your thinking is that when you looped the pipe in a circle and it blew up in your face? It was amusing the first time I did it and I never really though of a way to make it a buffer. The TE Conduits held 1000MJ in each segment before the change now they hold 10000 RF, this gives you a buffer of energy so you can swap engines/batteries around without interupting something.
But what if you only want to connect a single device and it touches 2 different devices (tight spaces, ect). Mah fist can't just turn off one of the connections. :O[DOUBLEPOST=1389053920][/DOUBLEPOST]
Then you'd just see someone add a Quarry and Filler to Thermal Expansion and BC would be truely up shit creak. Forestry and Railcraft don't have anything special that another mod doesn't do easier atm.
It's a simple method of mod intercompatibility. I, personally, prefer when I can use one mod's power systems to power another. Having a power system all off to itself like a private walled garden makes me want to avoid using it as I then need to double up on everything.
TE isn't holding BC hostage. Having no unique use for BC is holding BC hostage.
Then the only reason they ever used MJ was because KL covered up the part of the power system they didn't like which happens to be the crux of the power system you wish to achieve. In the end those that turned away never wanted MJ; they wanted the best of MJ and EU combined. RF does this and more.
If your refineries sat there doing nothing, they would pull 1MJ/t as that is the loss programmed into them. This is the value that was set at the same time the Power API was redone. Prior to the Power API change, it was programmed for a 2MJ/t loss.
As for if you want to disconnect a device in tight quarters, that's what pipe plugs are for.
- Status