Mekanism: why BuildCraft support will not be included in 1.6

Status
Not open for further replies.

CovertJaguar

New Member
Jul 29, 2019
159
0
0
Thermal Expansion conduits are (apparently) computationally superior to regular Buildcraft pipes. Moving inferior code into TE may very well remove the efficiency, and from what I've read, King Lemming loves his computational efficiency. There's also the fact that once you've coded something and works, having to recode it because the API had features completely removed is hardly constructive use of time.


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.
 

ShneekeyTheLost

Too Much Free Time
Dec 8, 2012
3,728
3,004
333
Lost as always
Still waiting for the explanation as to why you are rejecting alternative implementations. The Wooden Power Pipe does exactly, I repeat EXACTLY, what you are trying to do with your wires. You could practically copy/paste the Wooden Power Pipe code into your wire class and have it work first try. I've done nothing that will harm your mod, except force you to think outside the box.
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?
 

arentol

New Member
Jul 29, 2019
92
0
0
You're very right.

It also doesn't help that you said this:

Looking on GitHub, there are some wonderful improvements - PowerProviders can now be side-based, allowing for easier, more realistic MJ-based mechanisms, and receiveEnergy() can now return rejected energy in order to prevent power loss. One minor catch, however. This update also finalizes the "PowerProvider" class, and removes "IPowerProvider" which previously was used for managing a complete BuildCraft power framework......

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.
 

Stephen Baynham

New Member
Jul 29, 2019
23
0
0
If you were not trying to be sarcastic, and weren't quoting, then I just don't understand you at all.


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.
 

Julian Zhou

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

Nothing. Just a drama queen hanging around.
 
  • Like
Reactions: russjr08

Calclavia

New Member
Jul 29, 2019
8
0
0
So much argument for the addition of "final" modifier. :D

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

Aidan

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

arentol

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

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.
 

Julian Zhou

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

Hyperme

Popular Member
Apr 3, 2013
196
257
138
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.

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

gattsuru

Well-Known Member
May 25, 2013
364
103
68
Please note that Final is a keyword in Java, similar to (but not the same as) Sealed in C#.

Can someone point me out which commits are you guys talking about?
From what I can tell, this one.

Are these changes good for devs or good for players? Both? Why? That's all I really care about.
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.
 

arentol

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

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.
 

CovertJaguar

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


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.
 

arentol

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

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.
 

Poppycocks

New Member
Jul 29, 2019
1,914
0
0
From what I can tell, this one.

I'm not familiar enough with the internals of Mekanism or ThermalExpansion to comment on how badly this would affect them.
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.
 

KirinDave

New Member
Jul 29, 2019
3,086
0
0
I've yet to see any proof of such a claim (in fact the opposite generally).

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 TE and Mekanism fall down (EDIT: I was in mid thought as I moved here and wrote this incorrectly. I did get TE to break but not in the same way that Mekanism breaks and that's what's germane to this conversation. TE's conduits are very well behaved on networks with lots of clients). TE and Mekanism both have different strategies there that behave in different ways. Mekanism does not scale as well as TE, but Mekanism's power pipes do a lot more and I haven't taken the time to really profile in there (hasn't been relevant to my modpack efforts).

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.

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.

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

KirinDave

New Member
Jul 29, 2019
3,086
0
0
Don't get me started of mod "competition", there is no such thing as 'better'. 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.

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?

If multiple mods keeps 1-upping each other we will quickly see a tech mod scene that is basically creative mode. This journey has already started, but I don't want BC to participate in what is most likely the eventual fall of tech mods.

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.

I know that players do want to be able to count every single 'energy unit' and hates any type of waste, but that is not how we see buildcraft power.

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

Aidan

New Member
Jul 29, 2019
80
0
0
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!
 
  • Like
Reactions: RedBoss
Status
Not open for further replies.