Mekanism: why BuildCraft support will not be included in 1.6

[DoctorOr]

It is not exactly hard to make mods 'better' in the views of the player. All you have to do is give them more stuff for less.

I have no general comment on this thread, but would like this quote read at the opening of every conversation about balance.

 

[KirinDave]

In the meantime, seriously, try using my Universal Cable in a later Mekanism build. They're much more efficient than they were a few days ago!

I can give you raw data if you want later on. But the difference in your strategy as opposed to KL's seems pretty obvious to me. I don't think he does it this way. If he does, please do correct me because I don't have his code in front of me.

I actually suspect with work your strategy has better locality, and that's one of the quiet but critical aspects of Java optimization. But clearly your current implementation is O(n) on the number of consumers and providers in the network per operation. I don't know the modding scene well enough to say if this is true, but in my day job I'd say that you could decouple this and increase the parallelism in your code by inverting that workflow. There's still N ops to do, but they need not be done sequentially and it'd be easier to ignore quiescent nodes in the network.

Perhaps the APIs prevent you from doing this?

 

[Aidan]

I can give you raw data if you want later on. But the difference in your strategy as opposed to KL's seems pretty obvious to me. I don't think he does it this way. If he does, please do correct me because I don't have his code in front of me.

I actually suspect with work your strategy has better locality, and that's one of the quiet but critical aspects of Java optimization. But clearly your current implementation is O(n) on the number of consumers and providers in the network per operation. I don't know the modding scene well enough to say if this is true, but in my day job I'd say that you could decouple this and increase the parallelism in your code by inverting that workflow. There's still N ops to do, but they need not be done sequentially and it'd be easier to ignore quiescent nodes in the network.

Perhaps the APIs prevent you from doing this?

The approach is completely different than Thermal Expansion's, you're right. O(n) is because of, unlike TE's conduits, my cables evenly split up energy between all acceptors. There's no way to manage this without iterating through the acceptors in the network. Overall, from a user's perspective, there will actually be less client-side lag with these cables than TE's conduits. Yay!

Not to say that TE's system isn't incredibly efficient on the server-side. Because they go from closest to farthest in terms of transferring energy to acceptors, there's no iteration needed...at all. Sadly I can't do this and still divide energy evenly

If you could do some tests that would be much appreciated.
Thanks

 

[Krapht]

So please, don't underestimate the player base. Especially while talking in a forum dedicated to said player base?

I've seen way too many posts on forums where players think in their role as a player rather than a mindset of a game designer. Mocking someone for using mod X when using mod Y would be so much better because of less energy requirement/more output/whatever. What I mean is that when they consider mods they consider how the mod can make their game easier from a player perspective and not from a effort/reward perspective. It is simply not the same thing as claiming that a diamond sword is better than a wooden sword. The later is true from a player perspective, but selecting which mods to use requires more of a game designer mindset. Which mods should I use to get the most enjoyable playing experience for me.

There is also a problem of what you get used to as a player. Once you get a taste of something powerful it is not easy to go without it. You bring up AE, so let's look at that. I agree that it does add some interesting gameplay. But once you are used to have an AE system, do you think that you can ever go back to regular chests? Your expectations of the game has changed and a near infinite storage easily accessible will be the norm, anything less is not really worth looking at. Think about it. The norm of what is "baseline" has changed significantly since I started playing modded minecraft. Things that used to be exotic are now common. Other things are exotic now but will eventually become common. It is a circle of feature inflation that I do believe will bring the norm closer and closer to creative mode. Diamonds used to be valuable... with today's mods, not so much.

Is it worth trying to stop them, though? Someone is just going to reflect into your code and make a monitor block mod.

Yes, and some people will use that mod. Some will not. Some people prefer rewards requiring effort. Some people prefer creative mode. The rest are spread out in between. Not all mods can cater to every type of player.

 

[KirinDave]

I've seen way too many posts on forums where players think in their role as a player rather than a mindset of a game designer.

Maybe, but if you look at the way the playerbase behaves in aggregate, mods that deviate too far from the meta tend to be discarded. To significantly push the meta, a mod needs to be of exceptional quality and generally engaging. Logistics Pipes was a good example of a mod that pushed the boundaries of what was considered "OP". To this day, nothing really does what LP did.

And it's pretty clear that EE2 did not do enough to break through that boundary (even though EE2 in isolation was a pretty well designed mod).

You bring up AE, so let's look at that. I agree that it does add some interesting gameplay. But once you are used to have an AE system, do you think that you can ever go back to regular chests?

Actually yes. And many people on Resonant Rise servers, which is a pretty aggressive environment (we've blown the doors off more than a few mods now), still use chests. Although, many people do hook up storage busses for search through inventories. But I do not use AE for everything (I actually find it ill-suited to many tasks) and the amount of time and work it takes to stand it up means most people delay it as long as they possibly can; modern AE is Freakin' Gregtastic to set up.

Your expectations of the game has changed and a near infinite storage easily accessible will be the norm, anything less is not really worth looking at. Think about it.

If anything I'm considering not using cells for everything even though it's convenient. The type restriction is onerous in the extreme compared to what Iron Chests provided historically. Underground Biomes (beloved by our group despite the profound performance implications) is rough on an AE system over time.

Perhaps I am unusual in this. But I think the kernel of truth is that people want Fabricators and Searchable Inventories in response to modders leaning on increasingly absurd recipes as a balancing and design rule. Try just adding AE and Buildcraft and AE feels nearly pointless. Toss in a few tiered crafting mods like Thermal Expansion, Gregtech (or AE itself) and you immediately love it because the mod authors introduced time-taxing and tedious steps.

The norm of what is "baseline" has changed significantly since I started playing modded minecraft. Things that used to be exotic are now common. Other things are exotic now but will eventually become common. It is a circle of feature inflation that I do believe will bring the norm closer and closer to creative mode. Diamonds used to be valuable... with today's mods, not so much.

The progression of Minecraft technology is due in no small part to the awesome work being done on Forge and the wonderful work of open source modders like yourself to show what's done. What is possible with an average modder's skill level has gone up over time, and I submit this is why exotic things become more common.

Some people prefer rewards requiring effort. Some people prefer creative mode. The rest are spread out in between. Not all mods can cater to every type of player.

I agree. Although I am not privy to your design plans that dictate un-measurable power as a balance concern. It just seems like you're making a concrete statement to devs about this, not players. But a dev who wants to implement that really isn't perturbed?

Again, I do not know how feasible CJ's workaround is for Aidan. I haven't read the diffs yet an I won't today. But the way you're talking, it sounds like you'd like to make this more difficult for developers.

 

[Aidan]

Again, I do not know how feasible CJ's workaround is for Aidan. I haven't read the diffs yet an I won't today. But the way you're talking, it sounds like you'd like to make this more difficult for developers.

KirinDave, it is possible to get my systems working with BuildCraft, but it would result in a loss of performance and no real reason to use my cables over regular pipes. CJ misunderstood exactly how my systems worked, I clarified this with him over IRC. There is no way to maintain an efficient tick-free energy network with this addition, which would result in a loss of performance in Universal Cable AND Redstone Energy Conduits if I or KL decide to integrate. This was admitted here: http://puu.sh/3ojF3.png

This is why I'm not integrating with BC if this addition is merged. Loss of performance for an API is not the right thing to do.

EDIT:
I also just want to put out for the record that a tick-free network is indeed better than a tick-based network, it's simple logic

 

[KirinDave]

The approach is completely different than Thermal Expansion's, you're right. O(n) is because of, unlike TE's conduits, my cables evenly split up energy between all acceptors. There's no way to manage this without iterating through the acceptors in the network. Overall, from a user's perspective, there will actually be less client-side lag with these cables than TE's conduits. Yay!

It'll always be O(n) even for KL, but how it's quantized can matter significantly. Like I said though, your locality is way better. What you need is a way to leverage that more. For example, if there was an efficient way to only consider entities that need power right now... My quick glance over the code suggests that you update that list when you merge the power networks.

My first instinct is to always reach for java.util.concurrent.* and be like, "Lol 4x time reduction is constant but it's also big enjoy my threadpool." My time in Clojure and Scala has scarred me. I also enjoy countering the prevailing wisdom that "java threads are slow and inappropriate for small tasks" with ruthlessly fast code. My naive feeling as I approach this is, "Even though MC is currently bound to single threaded ticks, that could change. And also, just because something starts on one tick that doesn't mean it needs to finish on that same tick if that is an improvement to the overall tickrate." I truly have no idea if that is a common sentiment in the community.

Not to say that TE's system isn't incredibly efficient on the server-side. Because they go from closest to farthest in terms of transferring energy to acceptors, there's no iteration needed...at all. Sadly I can't do this and still divide energy evenly

With all due respect to KL, I'm fascinated and I'ma gonna jump up in there when I am a bit less busy. I have every intention of entering modjam 2, so this stuff is very much in my "to learn" pile. [DOUBLEPOST=1372201043][/DOUBLEPOST]

EDIT:
I also just want to put out for the record that a tick-free network is indeed better than a tick-based network, it's simple logic

It's less computationally expensive if your network is defined by contiguous tile entities.

Xycraft's power stuff ticked but the size of the networks was so small it didn't matter. Ars as well, and it's power system never troubled RR in the slightest despite DoctorOr's unbelievably big Ars fabricator network. But the size of these networks scaled at a much slower rate than the physical area covered by the network so it was less of an issue.

 

[ShneekeyTheLost]

This is why I'm not integrating with BC if this addition is merged. Loss of performance for an API is not the right thing to do.

I can understand, even applaud your decision. However, realize that this is going to cause some individuals to avoid your mods because of the incompatibility with their current infrastructure.

I'm not saying you shouldn't make this decision, nor am I trying to imply that your decision was the wrong one. However, if your system doesn't incorporate with MJ, I know that I, for one, will likely not include them in my mod pack... in fact the primary reason I -was- going to include them was BECAUSE you were compatible with them. I don't know if KL will break compatibility with BC or not, that's his decision to make. If he doesn't, then you're pretty much an island to yourself on this matter, and mod pack compilers will have to take this into consideration when making them.

 

[King Lemming]

Alright, so here's the deal.

I'm on vacation this week. Any sort of TE update won't be out for a while. I suspect this won't change a whole lot for me, although I currently do extend the base PowerProvider class to provide missing cpu-efficient functionality - add and subtract mainly, as use/receive are inefficient when you know the state already.

However,

Overall, from a user's perspective, there will actually be less client-side lag with these cables than TE's conduits. Yay!

is just wrong. There is 0 client lag from conduits - they don't transmit ANY info to the client at all except for their connection state, and they are not TESRs. The only packets that are ever sent are description packets, and that only happens when a chunk has to be rendered.

Liquiducts are TESRs, which atm is a necessity owing to the fact that liquids can be on either sprite sheet - this changes with the new Fluid system.

Also,

which is where you see TE and Mekanism fall down

I would LOVE to see a profile of this, because there's no reason that multiple clients would cause any more stress over anything else, period. As explained above, please be sure you aren't confusing conduits and liquiducts please. Our stress test was a single conduit unifying 5 separate 50k networks into a single one at once, and it went without a hitch. So while I am partially skeptical of the extent of your claim, I'd actually like to see a hotspot report here.

 

[KirinDave]

I can understand, even applaud your decision. However, realize that this is going to cause some individuals to avoid your mods because of the incompatibility with their current infrastructure.

I'm not saying you shouldn't make this decision, nor am I trying to imply that your decision was the wrong one. However, if your system doesn't incorporate with MJ, I know that I, for one, will likely not include them in my mod pack... in fact the primary reason I -was- going to include them was BECAUSE you were compatible with them. I don't know if KL will break compatibility with BC or not, that's his decision to make. If he doesn't, then you're pretty much an island to yourself on this matter, and mod pack compilers will have to take this into consideration when making them.

It is absolutely the case that Mekanism & Atomic Science together make a very interesting experience. And it's one of the vey few that actually has some semblance of good game design and balance that can hold water in the face of cross-mod combinations. It'll be a real shame to see that fall away. CJ's argument for changing BC away from tickless support is, "We want physics modeling and this is the way we think we can do it."

Hopefully Aidan can find a work around. For example, creating a single unified fake entry point for all energy sources on the network that only has to tick once for EVERY buildcraft provider on the network. This is a small and perhaps irksome compromise, but seems very doable.

 

[Julian Zhou]

I would just like to add, that while Aidan may NOT be able to push this through, I suspect Lemming will. Mekanism will use TE's energy API henceforth. And there is 99% chance, Lemming will have BC support in TE. And since I doubt Lemming will like the changes CJ made, he may push this forward. If he finds a workaround, I applaud him. Lastly, if TE chooses to stray from BC and no longer use its energy system, then we can say good bye to buildcraft we know it. That is without a doubt.

 

[ShneekeyTheLost]

It is absolutely the case that Mekanism & Atomic Science together make a very interesting experience. And it's one of the vey few that actually has some semblance of good game design and balance that can hold water in the face of cross-mod combinations. It'll be a real shame to see that fall away. CJ's argument for changing BC away from tickless support is, "We want physics modeling and this is the way we think we can do it."

Oh, I agree totally, that was why I was wanting to include them in my mod pack. Actually interesting methods of power generation!

However, having to build a completely divorced power network which won't connect up with the rest of my system? Is a big downcheck for me.

Hopefully Aidan can find a work around. For example, creating a single unified fake entry point for all energy sources on the network that only has to tick once for EVERY buildcraft provider on the network. This is a small and perhaps irksome compromise, but seems very doable.

Agreed, but it seems doubtful at this point

 

[KirinDave]

I would LOVE to see a profile of this, because there's no reason that multiple clients would cause any more stress over anything else, period. As explained above, please be sure you aren't confusing conduits and liquiducts please. Our stress test was a single conduit unifying 5 separate 50k networks into a single one at once, and it went without a hitch. So while I am partially skeptical of the extent of your claim, I'd actually like to see a hotspot report here.

What I did was try to provide power to 8193 pulverizers by rapidly and sequentially worldediting them in. This broke my minecraft instance. I don't have the numbers in front of me on this box, sorry.

To be very clear on what I'm saying: if I add things slowly your cable DOES let me do this. I can only break it because of the way I can spam the network. I just can't add it via world edit instantly. Your code DOES let me add all the objects and doesn't totally kill my tickrate. Did I imply that it didn't? EDIT: I seem to have done so and I am sorry about that. If I am careful your code supports this use case. I'll fix.

Hence the conversation with Aidan about why his cables don't let me do this. Both your cables and Aidan's cables are MUCH more performant than BC pipes, IC2 cable, and UE cable. My numbers suggested that IC2 is the worst performer o the bunch, with new BC and current UE working somewhere behind there.

 

[gattsuru]

O(n) is because of, unlike TE's conduits, my cables evenly split up energy between all acceptors. There's no way to manage this without iterating through the acceptors in the network.

Well, you could have the network aware of requests by the power consumers (or pieces of wire attached to power consumers) and go to a complete modeling system instead of an active counting based one. That gets closer and closer to making power networks an actual network in the TCP-ish sense, though. By the time you're doing that, you probably want to move away from the ridiculous engine/generator activity on every tick, first.

To be very clear on what I'm saying: if I add things slowly your cable DOES let me do this. I can only break it because of the way I can spam the network. I just can't add it via world edit instantly.

That's... pretty much any state-based situation will break down under that test. Having to force multiple array or list resizes all at once is a worse-than-worst-case scenario.

 

[Krapht]

Maybe, but if you look at the way the playerbase behaves in aggregate, mods that deviate too far from the meta tend to be discarded. To significantly push the meta, a mod needs to be of exceptional quality and generally engaging. Logistics Pipes was a good example of a mod that pushed the boundaries of what was considered "OP". To this day, nothing really does what LP did.

It is not the major pushes towards OPness that is the problem. As you said players do generally identify and shun them. It is the small changes that pushes the boundary that slowly move the the meta. The pace increases if two mods are "competing", each doing a little bit better than the other one.

Perhaps I am unusual in this. But I think the kernel of truth is that people want Fabricators and Searchable Inventories in response to modders leaning on increasingly absurd recipes as a balancing and design rule. Try just adding AE and Buildcraft and AE feels nearly pointless. Toss in a few tiered crafting mods like Thermal Expansion, Gregtech (or AE itself) and you immediately love it because the mod authors introduced time-taxing and tedious steps.

Yes, I believe that this is true, but the opposite is also true. Because now-days there are in-game recipe viewing, auto-crafting and searchable inventories, modders feel more confident moving towards more complicated recipes. Partly because recipe space is limited if you want to avoid conflicts with other mods, but also require more effort for the reward. It is extremly hard to balance resource requirement with today's mod flora because nothing is really rare anymore. You used to be able to throw some diamonds in a recipe to make it a bit rarer/more difficult. Ofc mods did this which made diamonds rare. What happened is that mods started filling this gap by providing alternative ways to get diamonds / get more diamonds. Modders started making more complicated recipes which lead to other mods being made that simplified crafting. If there is something that requires effort, that is a target for a mod because it will make it easier for the player. In the real world I would call this evolution / supply-demand or something similar, and it is a good thing. But that is not really applicable on game elements (mods).

The progression of Minecraft technology is due in no small part to the awesome work being done on Forge and the wonderful work of open source modders like yourself to show what's done. What is possible with an average modder's skill level has gone up over time, and I submit this is why exotic things become more common.

Yes, this is very much true. Modding today is easy compared to a few years ago. This has also resulted in a lot more modders that want in. I'm not saying this is a bad thing, new dna is healthy, but it does pose a long-term problem when new mods try to "compete" by 1-upping established mods. Here is where the playerbase comes in. Now don't get me wrong there are exceptions, but a substantial part of the playerbase will go "oooooh shinie! more ore per thingie!" because that is how people in general behave. (I used to work ISP tech support, I know it all too well). If established mods return, the 1-upping the circle begins.

But to get back on topic (sorry)
Currently there isn't really a single BC power framework. There are as many frameworks as there are powerprovider implementations. The old interface was the only thing the bound them together. There was no standard of how it should behave and it has degraded to a IC2 power clone. That is not where we want BC power to be. We have a few ideas of how we want the buildcraft power framework to work, but in order to do that we must retake control over its behavior.

 

[King Lemming]

I would just like to add, that while Aidan may NOT be able to push this through, I suspect Lemming will. Mekanism will use TE's energy API henceforth. And there is 99% chance, Lemming will have BC support in TE. And since I doubt Lemming will like the changes CJ made, he may push this forward. If he finds a workaround, I applaud him. Lastly, if TE chooses to stray from BC and no longer use its energy system, then we can say good bye to buildcraft we know it. That is without a doubt.

Alright, I better nip this one quickly.

I looked over the code. It looks fine to me, I don't think anything will have to change on my end, truth be told, so let's check those thoughts at the door now. In fact, I think this can be leveraged to make conduits MORE efficient, something I'm definitely on board with. There's actually a tiny legacy change I'd like CJ to make, and I'll bring that up with him at some point, but the fact is this - CJ, Sengir, and Krapht are all damn competent coders, and regardless of what they think about TE or me personally, I have a ton respect for them (and legitimately like them, despite any perceived conflicts) and I'm going to work with them as much as possible to make a better mod environment.

Yes, CoFHLib has a skeleton of a power framework. It's something I've sort of juggled, and it may or may not be implemented at some point, but I see no reason that requires me to drop BC integration at this point, so long as using BC power does not directly require BC to be installed. I'll always play with it personally, but ehh, I respect those who don't - that's the point of mods.

 

[Virgoddess]

Alright, I better nip this one quickly.

I looked over the code. It looks fine to me, I don't think anything will have to change on my end, truth be told, so let's check those thoughts at the door now. In fact, I think this can be leveraged to make conduits MORE efficient, something I'm definitely on board with. There's actually a tiny legacy change I'd like CJ to make, and I'll bring that up with him at some point, but the fact is this - CJ, Sengir, and Krapht are all damn competent coders, and regardless of what they think about TE or me personally, I have a ton respect for them (and legitimately like them, despite any perceived conflicts) and I'm going to work with them as much as possible to make a better mod environment.

Yes, CoFHLib has a skeleton of a power framework. It's something I've sort of juggled, and it may or may not be implemented at some point, but I see no reason that requires me to drop BC integration at this point, so long as using BC power does not directly require BC to be installed. I'll always play with it personally, but ehh, I respect those who don't - that's the point of mods.

I'd like to say something about you in general, and your post, but I'd wind up embarrassing myself. So I'll just leave this here: <3

 

[Julian Zhou]

I'd like to say something about you in general, and your post, but I'd wind up embarrassing myself. So I'll just leave this here: <3

......

Alright, I better nip this one quickly.

I looked over the code. It looks fine to me, I don't think anything will have to change on my end, truth be told, so let's check those thoughts at the door now. In fact, I think this can be leveraged to make conduits MORE efficient, something I'm definitely on board with. There's actually a tiny legacy change I'd like CJ to make, and I'll bring that up with him at some point, but the fact is this - CJ, Sengir, and Krapht are all damn competent coders, and regardless of what they think about TE or me personally, I have a ton respect for them (and legitimately like them, despite any perceived conflicts) and I'm going to work with them as much as possible to make a better mod environment.

Yes, CoFHLib has a skeleton of a power framework. It's something I've sort of juggled, and it may or may not be implemented at some point, but I see no reason that requires me to drop BC integration at this point, so long as using BC power does not directly require BC to be installed. I'll always play with it personally, but ehh, I respect those who don't - that's the point of mods.

Good stuff. Looking forward to the next version of TE and Mekanism with TE's power API in. Hopefully, both will improve upon their current versions. DD

 

[MachineMuse]

I've seen way too many posts on forums where players think in their role as a player rather than a mindset of a game designer. Mocking someone for using mod X when using mod Y would be so much better because of less energy requirement/more output/whatever. What I mean is that when they consider mods they consider how the mod can make their game easier from a player perspective and not from a effort/reward perspective.

Yeah a lot of players are 12 but I mean, it's not like their game doesn't have creative mode. That's a builtin feature, not a mod. If that was the only thing that passed through their heads, then they would never play survival mode. I personally tend to see people complaining about something being too easy from their perspective rather than deriding others for using a more difficult mod. (Gregtech users excluded because that is its own issue).

It is simply not the same thing as claiming that a diamond sword is better than a wooden sword. The later is true from a player perspective, but selecting which mods to use requires more of a game designer mindset. Which mods should I use to get the most enjoyable playing experience for me.

There is also a problem of what you get used to as a player. Once you get a taste of something powerful it is not easy to go without it. You bring up AE, so let's look at that. I agree that it does add some interesting gameplay. But once you are used to have an AE system, do you think that you can ever go back to regular chests? Your expectations of the game has changed and a near infinite storage easily accessible will be the norm, anything less is not really worth looking at. Think about it. The norm of what is "baseline" has changed significantly since I started playing modded minecraft. Things that used to be exotic are now common. Other things are exotic now but will eventually become common. It is a circle of feature inflation that I do believe will bring the norm closer and closer to creative mode. Diamonds used to be valuable... with today's mods, not so much.

Let me preface this by saying: I definitely agree that BC's power system needed revamping, and I don't necessarily disagree with the changes that were made. But if you're acting out of fear of 'feature inflation', I take serious issue because this reasoning could lead to problems down the road.

So modded minecraft often looks more like creative mode than it used to. Is that necessarily a bad thing? Even creative mode leaves a lot to be desired. What even is the effective difference between survival and creative?
1) Unlimited health/stamina - With enchanted diamond armor and farms, you basically already mitigate this. Except now you have 90% of your skin covered up with turquoise cardboard.
2) Flight - And not even good flight at that, but it's nonetheless a prized ability. Let's come back to this.
3) Unlimited resources and inventory space - Resources in Minecraft (vanilla at least) are just a time sink and a slot machine. Optimal and near-optimal strategies are already known for revealing the maximum number of blocks with the minimum number of blocks mined, and farming is just a matter of planting crops or feeding animals and waiting.

...

Instead of focusing on how a mod brings us closer to creative mode, I'm more interested in seeing how it diverges from or enhances that continuum. One possible question is: Would this be useful in creative mode? EE2's Mercurial Eye, Redpower's microblocks and frames, and Mystcraft's world-writing are some examples of features which enhance even the creative mode experience. Another possible question is: Does this add some new and interesting mechanic to play around with and learn? IC2's crops, Foresty's genetics, and TerraFirmaCraft's cooking system are some examples of mechanics which, while not especially useful to the Creative mode player, are interesting enough to explore on their own rather than as a means to an end.

Yes, and some people will use that mod. Some will not. Some people prefer rewards requiring effort. Some people prefer creative mode. The rest are spread out in between. Not all mods can cater to every type of player.

So, my question is: does Buildcraft want to be just another point on that line between vanilla survival and creative? For the most part, Buildcraft addresses the issue of resource acquisition and management, through quarries, sorting, and auto-crafting. And fillers & builders & template tables were a very interesting approach to automatic building, which might even be useful in creative mode. But a lot of the mod is just feeding back in on itself as a system for other mods to expand on; oil is just fuel for engines which power your quarries and fillers and builders.

Now, how this all works within Buildcraft is one (very narrow) thing. The range of possibilities is huge. Forestry, Railcraft, Thermal Expansion, and more recently, some of the UE mods each have their own take on how power works, and while compromises are often made, these ideas come from different perspectives and therefore have their own reasoning and priorities. I've already run into issues with how MPS's energy values scale up exponentially along with UE and IC2, making it difficult for BC-oriented players to charge up their suits in a reasonable time once they reach the late-game 'HV capacitor' level. So however indirectly, buildcraft's energy system affects me as well, because it is the standard from which Forestry, Railcraft, ThermEx, and others are derived. And that's fine, if the possibility exists for it to meet my mod's needs in a general way. If the focus is turned from creating a standard to allow a wide variety of mods to interface with each other, to preventing modders from taking it in a direction that the authors don't want it to go, then we're back at square one, with a bunch of mods that can't interact because one modder (or team) doesn't like the cut of another mod's jib.

Anyway, I'm not sure how relevant that turns out to be, but I hope I've at least identified clearly what's important to me and I hope you can relate on some level.

 

[Virgoddess]

......

?

I think he's a class act, and I like his brain. I don't want to have his babies or anything.