I thought it was my opinion, not yours. For me their colaborative work would be the best out there.
Do I really have to edit that post for you to be satisfied, that what I said wasn't a "general statement" nor an "annoucment" but merely my opinion?
Spacetoad is back to modding
- Thread starter xbony2
- Start date
- Status
Do I really have to edit that post for you to be satisfied, that what I said wasn't a "general statement" nor an "annoucment" but merely my opinion?
You don't have to do anything on my account.
I will say though that while everyone has the right to their opinion here, everyone else has the right to comment on those opinions, and point out ones that they disagree with. I, in my capacity as a humble minecraft player, disagree with your assertion that any mod, let alone one that doesn't exist, could be the "best mod out there" and I also find this notion of modder dream-teams (such as King Lemming and Spacetoad) a bit distasteful.
Dont take it to literal
Al he is saying is that BC has some great ideas and if spacetoad comes back with more great ideas, it would be realy awesome if said ideas have the efficiency of TE. It doesnt realy matter if Spacetoad and Kinglemming exchange idea's, work together or merely respect eachothers work.Oh geez, nevermind you.
Kind of, I'm very eager to see how SpaceToad will shape BC now, back in the days around the time he had to cease modding he said couple times he does see the need for either complete overhaul or rewrite for the mod, as he "fenced himself into corners" at some points. That's where from I take my slight hope for those 2 modders to colaborate.Dont take it to literal
I think SpaceToad will get all the help he needs from CovertJaguar, Player, Sengir and Krapth. I'd also like to point out that BuildCraft still is open source and anyone with a good idea can submit suggestions. You, King Lemming, even me (twice). If your suggestion is solid and fit with the rest of BuildCraft you will be a part of the team before you can say "BuildCraft".
I made the Filtered Buffer and the core logic of the Emzuli pipe.
https://github.com/BuildCraft/BuildCraft/issues/1396#issuecomment-31440096
Well SpaceToad is digging around. His poking has revealed a tidbit of planned stuff from CJ. There are "plans to do away with Item drops entirely" from pipes.
Well SpaceToad is digging around. His poking has revealed a tidbit of planned stuff from CJ. There are "plans to do away with Item drops entirely" from pipes.
Do you have any data to back up the claims in 1 and 2? As for lossless machines being completely denied by the system, there is absolutely nothing that stops you from taking the power coming in and storing it outside of the BC power framework and defining your own perdition calculator that would make the loss at the point it hands off the power to something very low like 0.000001 MJ/t (in other words, a loss of 1 MJ every 13.9 hours roughly)I actually had almost no influence on the BC API. It wouldn't look ANYTHING like it does if I did. The problem is that ultimately, the restricted design meant three things:
1) MJ-based Tile Entities use an additional 100+ bytes of memory that is flat out unnecessary. (Compared to RF)
2) MJ-based Tile Entities use roughly 5-10x the CPU during energy transactions. (Compared to RF)
3) Lossless machines are completely denied by the system, and any attempt to create one is met with silent failure by the API.
Yeah, no thanks.
EDIT: As far as the original post, I'm quite glad to see SpaceToad return to the scene. I loved BC - that's why I wrote TE to save it back in 1.2.5.
The Facts, in chronological order:
- Severe designs flaws are noticed in the old API that result in a constant slew of bugs.
- API is refactored and cleaned up, using the old API as the foundation so that users of the new API wouldn't be required to rewrite their machines completely. Legacy constraints prevent a ground up rewrite.
- KL was asked for input about the new API, he asked for a couple minor things, they were added, even though they made it slightly less efficient.
- KL gives the thumbs up without expressing any indication that he was displeased with the API.
- API is finalized and released, ie can no longer be changed.
- KL jumps ship and the entire community turns against BC.
And just to set the record straight for all of the "*whine* CovertJaguar added perdition" people: Perdition has always been in Buildcraft. This is the initial commit to GitHub after it was turned over to SirSengir, pointing at the function call for configuring the perdition calculator: https://github.com/BuildCraft/Build...aft/src/buildcraft/api/PowerProvider.java#L41
SpaceToad is new and there is a limit to how much information it's possible to absorb in a few days. No one is keeping any secrets from anyone else. The buildcraft development channel on irc is buzzing with life and ideas are being discussed constantly. Just now cpw payed us a visit to discuss changes for 1.7.
CovertJaguar have been the scapegoat for many design choices that everyone agreed upon. It's getting a little bit tiresome not only for CJ, but for everyone else involved as well. BuildCraft is not a one man show. (Although Covertjaguar has been very important for BuildCraft the last couple of months.)
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.
TE seemed to perform just fine considering point 1, but I'll concede that the variability meant that implementations were messed up at times.
Point 2...how legacy are we talking here? Changing a major version number - 3 to 4 in this case means that nobody should expect legacy anything to work. Should have done a clean reboot.
Point 3 is true. Although, my big request was the removal of "final." At the time I signed off on it, I was really attempting to prevent drama because of how my attention was brought to it. (A thread on here.)
The timeline does look about right though. I question the veracity of point 6, as the implication is that I hold tremendous sway over the community and/or actively pushed them away from BC. I do not and did not.
The only reason it has the SafeTimeTrackers is because Aidan and you insisted that it had to support tickless operation. Remove that requirement and you don't need the time trackers. They were not part of the original design.
Not really, you grab the tile's power handler, give it power, and say good day.
"Legacy" means I had neither the time nor motivation to completely rewrite the two dozen or so machines that use the API in both Buildcraft and Railcraft. And Sengir was opposed to it as well due to Forestry's machines. So we did a refactor and code cleanup instead, leaving the basic structure intact.
Last edited:
Alternatively, removing the final keyword - what was actually requested - would have done this just as well.
EDIT: This is getting off track from the real point of the topic, and I apologize for contributing to that. Welcome back, SpaceToad.
And it would have made the rewrite completely pointless, since the primary cause of all the bugs was inconsistent PowerProvider and IPowerReceptor implementations. Also, I have the IRC logs, you never actually asked that. Complained about miniscule cost validation checks and JVM Hotspot streamlined code, yes...but just a vague reference to how you use your own implementation...
Last edited:
On the interface level, I agree - but you actually grab the PowerReceiver, not the Handler. The assistant to the helper gremlin, as it were. And the under the hood code involves the various deputy and sub-gremlins - the safe time trackers, perdition calculation, the required doWork call, etc.
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.
The only mechanics "change" I made was removing the 20% powerloss per pipe. Everything else was minor tweaks to existing mechanics.
Exactly, a few versions ago the BC+RailCraft+Forestry trinity were the most important mods that me and everyone else on my server used to do almost everything and suddenly there was a just a non-stop series of bad design decisions across Forestry (which caused us to ignore it and use MFR instead) then The BC revamp and Railcraft started doing it and ran with it. Then basically we all said screw it and completely moved away from anything that anyone in the trinity had anything to do with because we figure it will go down the exact same path.
- Status