Spacetoad is back to modding

  • 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
Status
Not open for further replies.

mohrad

New Member
Jul 29, 2019
96
0
0
The Facts, in chronological order:
  1. (<- this thing refuses to change to 6.)KL jumps ship and the entire community turns against BC.
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:
 

smbarbour

New Member
Jul 29, 2019
19
0
0
For point 1:

Okay, so to receive BC power, you must have a PowerReceiver. This is non-negotiable. End of story.

Awesome, so you just add one to your class, and store in another structure or another type of energy? Oh no wait, it's private to PowerHandler. Also non-negotiable, end of story.

The only option you have is to add a PowerHandler. Meh, fair enough, just override the PowerReceiver and change the behavior to point to your custom structure. Oh wait, it's FINAL. Once again, end of story. There is literally one way to accept BC power. Talk to AlgorithmX2 at some point - he has to do a rather ugly hack to change the power stored and is not fond of doing it.

PowerHandler is a very large class, containing multiple SafeTimeTrackers and assorted helper gremlins. It literally requires 100+ bytes of memory to be able to accept MJ. Kinesis pipes are a special case it seems, as they can send to each other under a slightly lighter weight framework, but the wooden ones still need this rather large class.

As far as point 2...

You know how to use github. Trace through a power request and power receive for MJ. Then trace through the same for RF.

I'll help you out, here's how RF works:
"Hello RF-receiving tile, have some power."
"Why thank you. Here's how much I accepted."
"That concludes our transaction. Have a nice tick."

With MJ, there's a bit more involved.
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)
 

Vauthil

New Member
Jul 29, 2019
1,491
-14
1
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.
 

SandGrainOne

New Member
Jul 29, 2019
129
0
1
The community going against BC has nothing to do with KL. You chose to change the mechanics in which the power works in a way that the majority of players do not like. Don't put blame elsewhere. It was your choice to change it to fit the vision you desired.
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:

CovertJaguar

New Member
Jul 29, 2019
159
0
0
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)

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:

Sarda

New Member
Jul 29, 2019
160
0
0
The only mechanics "change" I made was removing the 20% powerloss per pipe. Everything else was minor tweaks to existing mechanics.

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.
 

smbarbour

New Member
Jul 29, 2019
19
0
0
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.
 
  • Like
Reactions: Padfoote

SynfulChaot

New Member
Jul 29, 2019
599
0
0
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!
 

smbarbour

New Member
Jul 29, 2019
19
0
0
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!
I still have not heard of a single instance (other than Thermal Expansion itself) of any mod removing Buildcraft support.
 
  • Like
Reactions: Padfoote

SynfulChaot

New Member
Jul 29, 2019
599
0
0
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.
 

Sarda

New Member
Jul 29, 2019
160
0
0
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.

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.
 
  • Like
Reactions: jokermatt999

CovertJaguar

New Member
Jul 29, 2019
159
0
0
Did BC pipes intelligently split power to all connected devices?

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.

Did BC pipes store energy as a buffer?

I don't even know what that means, but my best guess tells me you've never seen a BC energy storage loop.

Could you disable connections with just a wrench?

I can disable them with my fist! The wrench is optional.
 
  • Like
Reactions: jokermatt999

King Lemming

New Member
Jul 29, 2019
664
0
0
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)

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.
 

SandGrainOne

New Member
Jul 29, 2019
129
0
1
I still have not heard of a single instance (other than Thermal Expansion itself) of any mod removing Buildcraft support.

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.
 

Sarda

New Member
Jul 29, 2019
160
0
0
I don't even know what that means, but my best guess tells me you've never seen a BC energy storage loop.

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.

I can disable them with my fist! The wrench is optional.

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]
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.

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.
 

SynfulChaot

New Member
Jul 29, 2019
599
0
0
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.

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.
 
  • Like
Reactions: jokermatt999

Hoff

Tech Support
Oct 30, 2012
2,901
1,502
218
The only mechanics "change" I made was removing the 20% powerloss per pipe. Everything else was minor tweaks to existing mechanics.

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.
 

smbarbour

New Member
Jul 29, 2019
19
0
0
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.
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
Not open for further replies.