Mekanism: why BuildCraft support will not be included in 1.6
- Thread starter Aidan
- 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
- Status
I've yet to see any proof of such a claim (in fact the opposite generally).
And yes, I know the pains of changing an API. But change they do. Its only fair after all, since King_Lemming is rewriting the Liquid API. He can deal with a rewritten power API.
Hmmm... I think I see where you are coming from here...
Basically, you are consolidating all the different ways of handling power under a single user-friendly method. Unfortunately for this other mod, it doesn't fit his mod's playstyle.
I can see the advantage you are bringing to the table, however I can also see his perspective, if perhaps not in as demanding or inflammatory manner.
Basically, his power system is more like IC2, the power is sent from the Energy Block. It doesn't need an intermediary. By doing so, he is also able to set it up so that it will recognize which power API it is connected to, and simply output that power. From an end-user's perspective, I like that, particularly when I've got multiple power networks running around. It means I don't have to rely on a PowerConverters mod.
I think his problem can be 99% solved by taking the solution KL has... each section of his wiring can be manually configured to input or output mode. When configured in input mode, it acts as the intermediary event handler necessary. In output mode, it will provide power to any connected system which requests it.
However, he would need to re-write how his Energy Cubes handle the output of energy, because it wouldn't be able to handle the conversion as easily. Perhaps a hook for the BC Power API to be able to recognize that the connected interface runs on the BC Power API so that it can provide the requested power type?
It also doesn't help that you said this:
And then proceeded to bitch and moan about CJ and how horrible these changes are.
Ummm.. How do you get from "wonderful improvements" to "CJ sucks, BC is dead to me"?
If you were trying to be sarcastic.... Guess what, that doesn't work on the internet.
If you were actually quoting something someone else said, then you completely failed to actually indicate it was a quote.
If you were not trying to be sarcastic, and weren't quoting, then I just don't understand you at all.
Basically what I am saying is that your OP makes absolutely no sense at all and is confusing as hell. I don't know you, I don't know CJ, but I do know this.... Every post of his I have read on these forums has farking made sense. Your posts, in this thread at least, mostly just leave me going WTF????
I can see why CJ might not be too interested in working with you. He probably doesn't have a clue what you are trying to say half the time.
What's hard to understand? "Looking on GitHub, there are some wonderful improvements - <wonderful improvements>. One minor catch, however. This update also <bad things>. You can like things about an update while still considering something else a deal-breaker.
So much argument for the addition of "final" modifier. 
As I see it, things like Universal Wires which Aidan and I are working on are made very difficult to implement without the flexibility. The wire is meant to handle all types of energy and sure, BuildCraft might not be electrons passing through a conductor, but still, players liked that wire.
I do see CJ's point in trying to limit BuildCraft to be purely "mechanical", it's a design goal which is fine. But if this is where BuildCraft API is going, that's fine but note that it eliminates possibilities and features in other mods which shined.
As I see it, things like Universal Wires which Aidan and I are working on are made very difficult to implement without the flexibility. The wire is meant to handle all types of energy and sure, BuildCraft might not be electrons passing through a conductor, but still, players liked that wire.
I do see CJ's point in trying to limit BuildCraft to be purely "mechanical", it's a design goal which is fine. But if this is where BuildCraft API is going, that's fine but note that it eliminates possibilities and features in other mods which shined.
I'm going to stop posting here, as with each post I submit I get about 3 replies using what I say against me. I have made my point clear, and I am not backing down on anything I said in my original post.
CovertJaguar, I can see clearly what your goal is for BuildCraft, and I can also see how this change will help strengthen the mod itself. I hope you reconsider this, however, due to the hardships it would put upon me and many other developers to integrate properly. I understand that the wooden pipe does all these great things, but I don't think that you really understand EXACTLY why making PowerProvider one-size-fits-all would hurt Mekanism. Take a look at "TileEntityUniversalCable" and "EnergyNetwork," if you see a way to reproduce what I have working now without a custom PowerProvider.
For Krapht and CJ, your posts conflict a bit in what you are suggesting. Maybe both of you will come up with a solution to this issue together, communication is key.
I'm out for now.
CovertJaguar, I can see clearly what your goal is for BuildCraft, and I can also see how this change will help strengthen the mod itself. I hope you reconsider this, however, due to the hardships it would put upon me and many other developers to integrate properly. I understand that the wooden pipe does all these great things, but I don't think that you really understand EXACTLY why making PowerProvider one-size-fits-all would hurt Mekanism. Take a look at "TileEntityUniversalCable" and "EnergyNetwork," if you see a way to reproduce what I have working now without a custom PowerProvider.
For Krapht and CJ, your posts conflict a bit in what you are suggesting. Maybe both of you will come up with a solution to this issue together, communication is key.
I'm out for now.
See how you had to ADD things to make it make sense. That is exactly what I am talking about. He didn't say "one minor catch", he just proceeded to rail on the change without any explanation of how or why the change being implemented was suddenly going from wonderful to sucky in his opinion. Sorry, but that shows poor communication skills and when people can't communicate well they lose credibility. It's just how the real world works.
Again, does it look like the people in this topic give a crap about what you're saying. I don't see anyone caring with the exception of one response telling you the STFU. Stop being a drama queen
He does say 'one minor catch'! It's in the post fragment you quoted. Looks like someones so eager to be offended they forgot how to read all of a sentence.
Please note that Final is a keyword in Java, similar to (but not the same as) Sealed in C#.
Most issue is the interaction with other mods. Interfaces are /very/ easy to join into; as long as your method call looks the same, the actual internals can be anything. Protected methods like final-typed methods are a lot harder to deal with: you pretty much have to react to the existing designs, without replacing them. That's not always a /bad/ thing -- it's trivial to override a class in ways that act unpredictably -- but it makes more complicated variants on the thing harder.
I'm not familiar enough with the internals of Mekanism or ThermalExpansion to comment on how badly this would affect them. It's very, very hard to make something impossible to code, so I won't say that this prevents the goals that Mekanism or ThermalExpansion work toward, but it could conceivably make them more frustrating.
From what I can tell, this one.
Directly, it won't matter to players. Edge cases where they'd perform better, if anything, although I doubt it'd be perceivable..
Most issue is the interaction with other mods. Interfaces are /very/ easy to join into; as long as your method call looks the same, the actual internals can be anything. Protected methods like final-typed methods are a lot harder to deal with: you pretty much have to react to the existing designs, without replacing them. That's not always a /bad/ thing -- it's trivial to override a class in ways that act unpredictably -- but it makes more complicated variants on the thing harder.
I'm not familiar enough with the internals of Mekanism or ThermalExpansion to comment on how badly this would affect them. It's very, very hard to make something impossible to code, so I won't say that this prevents the goals that Mekanism or ThermalExpansion work toward, but it could conceivably make them more frustrating.
So, to be clear, are you saying that these changes literally make it impossible for your mod to work with BC, or that they will mean a TON of work for you to make it work again?
If it is the former, then you have a valid reason not to support BC, and to even be a bit upset (though perhaps not quite so justly upset as to have needed to post all this here). If the latter, I understand your frustration, but on the flip side, if it makes BC better and allows it to work better with future mods, then it might just be time to suck it up and work through the issues.
I looked at your code, I see what you are doing. And I'm telling you its exactly the same thing the Wooden Power Pipe does. Collects power in the PowerProvider and then transfers it to the power network. The Wooden Power Pipe is the only power pipe with a Power Provider, and its only used to collect power from Engines, etc... It is then fed into the pipe network. All you have to do is replace the BC pipe network, with your power network and your are done.
Okay, you got me on that one. Does seem weird to form a paragraph that way, but I am indeed in the wrong and willing to admit it. Sorry Aidan.
TY, that's the one.
Yeah, I'm with you. Too bad I'm at work otherwise I'd look it up.
TE and Meka aren't the only mods that'll... hm, "suffer" because of this change. MFR as well, from the top of my head.
This is difficult to do without pissing people off because any competent profiling would expose coding details that KL hasn't made public. He can't stop us from decompiling, but it has stayed my hand from publishing hotspots.
Still, the claim bears true in my testing. Aidan and KL's code in isolation tests, they both perform better than BC pipes over large runs (which is there just to force the issue, defined as a single length of unbranched pipe running 2048 blocks). BC pipes remain relatively unphased by lots of clients connecting to the network, which is where you see
I suspect that all three strategies are "good enough". The only power network I can get to reliably bork an instance without absurd scales (like runs of pipe 2048 long) is IC2. Even current UE's are relatively performant, although they do of course pay the price for their modeling decisions.
P.S., I'm waiting for someone in the modding scene to realize that LMAX Disruptor would be a pretty freakin' sweet library.
You could easily support tick threading with minimal overhead. I use it for distributed processing loops and it's amaing.The big question is, "Are you taking functionality away." Aidan seems to think you are, you say you aren't. It's too bad. Calclavia protested too, but it seems like you guys really don't like him, so I'm not sure how seriously to take any response directed that way.
This is really, really, really not true. Lots of mods have offered cheaper storage and they were passed by even though many were competent efforts. Applied Energistics is a great example: it is popular becuase it is interesting, and because it offers a very good set of design decisions and content. Mark's/Magical Crops? Not as popular as Pam's Crops (despite being better coded and better balanced) and that lets you have epic yields of metal from farms very quickly. The player base feels uncomfortable with it by-and-large.
And of course, lots of people love Greg precisely because his progression withholds results for awhile.
So please, don't underestimate the player base. Especially while talking in a forum dedicated to said player base?
Yes. Because as we all know Ars Magica killed magic mods. They're dead. Oh sorry I meant to say Equivalent Exchange 3. Oh man my typos are so bad today. I meant to say Thaumcraft 2. Whoops, really what I meant to say was Equivalent Exchange 2.
Is it worth trying to stop them, though? Someone is just going to reflect into your code and make a monitor block mod.
- Status