Power specification

[Caellian]

Hiya,

The idea I'd like to propose is separating out structure of a power API from the implementation details, which formalizes a very common behavior (~2/3rds of mods afaict) and allows different power APIs to talk to each other over a mod loader boundary while avoiding cycles in the dependency graph. It would requiring adding a set of interfaces to the mod loader which provide generic access to power systems. An isolated example of this is here.

So for instance, if we have BuildCraft, IndustrialCraft and Redstone Flux all using such interfaces, their power APIs don't need to depend on each-other to make their respective machinery work together. Each can define their own conversion rules which their machines use or prohibit conversion in case there's balancing issues.

There are mods which add converters, this isn't it. This is basically a foundation for power APIs which allows mods higher up the dependency graph to ignore all lower dependencies (relying only on a few common interfaces instead).
As mods that add "magic machines" also have their own power-like constructs (e.g. mana), this can also be used for those.

Adoption of such a rests on it being provided (expected) by a mod loader which is why this isn't a mod. It also makes no sense for it to slow down the loading process by registering a mod as it's just interfaces that do nothing and don't interact with the game. Bytecode trickery would be much more complicated than a mod loader just defining those things either way.

The result of a mod loader using such a system is:

• Converter mods don't need to depend on all APIs and can instead only use named properties (string->number KV pairs)
  • They can be separated into very thin (one-function) jars allowing end users to control behavior on a FS level
• Devs can write mods which support all power systems while knowing that something else already handled conversion and balancing for them (so testing on only one possible configuration).

The API I've linked also supports defining types/groups of energy (mechanical, electrical, magic, ...) and mandating conversion rules (e.g. explicitly stating that magic can't be converted into electricity). It'd be up to forge to define some common power groups.

The thing I've linked is not 100% fleshed out though I think it's very close to what I believe would be useful in mod dev scene - that's why I've made this a discussion instead of a PR. I'd be willing to help out in such efforts once a consensus has been reached.

[Technici4n]

Your API is at least 10x as complicated as IEnergyStorage, and it will never be able to support all possible usage patterns. (Such as IC2 energy packets or Create stress). It's better for a single power conversion mod to exist than to overcomplicate the API for everyone else, IMO. So I don't really see the point.

[pupnewfster]

Additionally... most of the mods who don't already support IEnergyStorage... intentionally don't support it as they don't want to be compatible out of the box, so like changing and adding a more complex API won't change that? They just will continue to not being compatible as they won't implement it.

[Caellian]

It also doesn't address the fact that IEnergyStorage makes every TE a storage component - a solar panel doesn't really store energy (assuming that energy storage besides potential was a thing IRL). A producer/consumer/transport model would make much more sense and make mods feel less like compromises have been made so they work with Forge and each other.

Reducing the choice to a config value doesn't diversify the ecosystem - it imposes a limitation that exists because the current API can't handle a different behavior. No amount of config fields makes it feel like less of a compromise. I don't care about bloat if it allows a large chunk of mods to operate nicely together - so not microblocks which were forced into mods to justify changing the mod loader for a single mod, it's not the same. I didn't really mind that, but I'm just saying that such a comparison is dishonest. The thing I'm proposing can be utilized by majority of mods that currently do exist, doesn't add any additional runtime overhead when unused and weighs ~22KB.

• It would be slower in practice due to an additional jumps and lookup of property values though, but marginally so (don't have benchmarks).

You are right, I wasn't up to date with capabilities, but IEnergyStorage does 5% of what the proposed spec would streamline while at the same time "forcing" a global default.

• Which also, makes no sense - converters are bad because they break progression, but forcing the same behavior through enforcing a global default isn't?
• A named property on the other hand tells me exactly what I have and I can switch on that value, is less likely to break over time, allows authors to say "nope" to mods which intentionally break balance (though I personally discourage that, choice should be up to players).

[Technici4n]

It also doesn't address the fact that IEnergyStorage makes every TE a storage component - a solar panel doesn't really store energy (assuming that energy storage besides potential was a thing IRL).

FE is push-based. The solar panels don't have to store energy - they can just try to push it to adjacent blocks and discard a leftover if that is the desired behavior.

* It would be slower in practice due to an additional jumps and lookup of property values though, but marginally so (don't have benchmarks).

That could matter a lot actually - energy transfer is performance critical in large bases, and should be as efficient as possible.

You are right, I wasn't up to date with capabilities, but IEnergyStorage does 5% of what the proposed spec would streamline while at the same time "forcing" a global default.

FE does what most mods that use energy as a resource care about, namely "please give me some energy" and "please accept this energy". This is why it is the standard API - it serves as the common denominator for mods that cannot meaningfully use additional context (such as some notion of amperes), and most mods are perfectly happy to only have "single dimensional" energy transfer.

* Which also, makes no sense - converters are bad because they break progression, but forcing the same behavior through enforcing a global default isn't?

The thing is that we do not force a global default. FE gives you 3 options:

• use FE directly and accept that balance may not be respected;
• bypass FE entirely and make your own little world where you have full control over the balance;
• some intermediate solution with some form of controlled conversion.

Most mods are happy to go with 1, and mods like Create and IC2 go with 2 and often some form of 3.

* A named property on the other hand tells me exactly what I have and I can switch on that value, is less likely to break over time, allows authors to say "nope" to mods which intentionally break balance (though I personally discourage that, choice should be up to players).

You are in fact proposing a worse system, where each power handling block needs to be aware of various kinds of energy it can accept. It is also likely that the API would not be idiomatic Java - forcing ugly object casts and other unnatural constructs.

I will also point out that your API cannot in fact handle power systems like Create's. Create's power system works by establishing a production >= consumption constraint on the whole network, and as long as that is respected everything runs. This means that methods like receive in https://github.com/Caellian/FlowAPI/blob/master/src/main/java/hr/caellian/flow/network/transfer/FluxReceiver.java do not make sense in such a system because there is not really a concept of "receiving" a certain quantity of power - just a boolean (whether the network is ok or not).

Additionally, methods like extends NetworkComponent for such key interfaces are pretty problematic because they ignore that not everything is part of a network. Most machines do not care about a network they would be part of, but only about receiving power "somehow".

Now, it is pretty clear that your API cannot and will not be accepted as such. So I will stop discussing the details here because the concept itself is problematic. Instead, I would like to recenter the discussion around use cases rather than a specific solution that you have in mind. It turns out most mods can currently talk with FE without sacrificing gameplay. For example:

IC2 Classic will automatically convert its EU to FE, but will not accept FE. This means that IC2C generators and cables can be used to power most power consumers in the ecosystem (such as Applied Energistics 2 networks). However, IC2C machines and tools will only accept energy produced with IC2C generators. This is a good solution because users cannot skip the challenge of generating EU, but once they have solved it they also get FE production with the same setup.

So in the current system, if you have a simple "power producer" or "power consumer" mod where the interesting gameplay is NOT the power production, but rather how it is being used (for example Applied Energistics 2 where building the network is the most interesting part, rather than how to power it); then you can use IEnergyStorage. Otherwise, you design your own power system with whatever gameplay you want.

In other words: most mods are perfectly happy to use a simple system like FE, and it wouldn't make sense to try to convert that to other energy units. There is no general conversion that can be expressed between a Powah! reactor and Create stress network, for example. Hence I do not see what you are trying to achieve here.

PS: I do not know what this "Tesla" mod that you are talking about is. Could you provide a link?

[KingLemming]

It also doesn't address the fact that IEnergyStorage makes every TE a storage component - a solar panel doesn't really store energy

You're correct that solar panels don't have to store energy. So they just don't implement the cap. They can still send to other things which do have the cap, which means you're actually incorrect about IEnergyStorage making every TE a storage component. Only TEs which need to receive energy have to return a capability when questioned. Also, note that the capability returned does not technically need to reside "inside" that tile entity, and that multiple tile entities can share the same IEnergyStorage.

[Caellian]

It can handle Create use case.

Put yourself into a position "I have to make this work" instead of "lets see how this is bad", you might be able to grasp the suggestion better that way. You're just pushing for bad design... like yeah, some things care only about receiving power, but it's useful for a system that manages those things to be able to access them through a uniform interface instead of having to do shotgun surgery, hardcoding stuff all over the place and having to familiarize yourself with 10 different APIs.

[KingLemming]

Let's just go ahead and close this down. This is a hard pass, thanks.

[Caellian]

Any concrete reasons you're not liking the idea? I see it benefiting more than half the mods that exist, and can't really see any reasons a spec describing shared properties is a worse of a solution than increasing target sizes of all mods that rely on power APIs which share large parts of their interface and having to run tests against multiple different APIs every release...

[KingLemming]

At this point it's already been said by other people who simply had the time/energy to say. I was pinged at 12:30 AM regarding this. It's an overengineered, unnecessary bit of bloat surrounding power given exactly how energy transfer actually works in Minecraft.

You acknowledge that it's "slower in practice" up front and frankly that's one of the biggest problems. The sheer number of tile entities that will exist in a world and interact with power systems in any way mean that power needs to be handled in a very optimized fashion, which this isn't.

There doesn't need to be a layer where magic mods have to define that they won't accept RF - they just don't accept it. Easy. Whereas your Grand Unified thing here...is more work for everyone up front with no real benefit for the modders or players.

[Caellian]

Sorry you were pinged at that time. I don't see this as a critical "needs to be done right away" thing.

I acknowledged it as perf was a possible issue with the example I suggested. It's not a large difference though as we're talking about a few jumps and string matching. JIT would very likely unwrap the loop anyway as the classes in question wouldn't be anonymous. The bigger perf hog is TE updates.

• No one can realistically say this would be a super slow solution without seeing how it performs in practice, though I know it won't be any faster it might not be much worse.
  • I have far less experience with MC though so I mentioned it because it would be dishonest not to do so.

In the proposed design the groups are just a convenient way of accessing a list of available power systems. They're not really a layer that stuff needs to be passed through, more of a separate thing that can be used to filter through power systems better.

You keep repeating it's over-engineered, but it's like 10x simpler than the process sources go through for dev env setup. On the other hand, I kinda expect the mod loader to do heavy lifting because when it doesn't all that weight falls on less experienced mod developers, maybe I'm wrong in that assumption but the way I see it - enforcing simplicity in a mod loader delegates that complexity to mods (also meaning it gets repeated).

[Caellian]

It seems to me like the system you're proposing is going to make that problem way worse, purely due to the sheer number of steps there would be for the modder wanting to add a simple device that consumes power from another mod.

Implementing an interface that describes a behavior they want anyway wouldn't add any steps and would make it more convenient because IDEs would suggest/generate methods. The linked example doesn't default interface methods where it should maybe, so that's something that could be addressed. A mod dev would be able to query adjacent networks (same as with IEnergyStorage) and then get access to vast amounts of information provided by a power API that owns that network. Most of the hurdle would fall on power API authors and it's mostly implementing/renaming methods they already use.

The only overhead they wouldn't usually do is having to implement FluxType and registering it with Forge which is 10 lines of code or so...

• And allows other devs to construct more complex power units without an extra dependency.

In fact, most of the proposed spec would add 5-10 dead simple lines of code to existing code bases which is why I don't get y'alls "it would complicate things" argument. A class could be provided for unit=int power types which would require only a constructor/method call.

This is, in some ways, where the benefit of the FE system lies. You can simply search for a capability adjacent to yours, and pull an integer power from it to process your resources.

Mods like Tesla and Create don't work with that, so IEnergyStorage is only useful if you're writing a power API which uses the bare minimum a power unit can be. This in turn promotes less interesting/complex mechanics because if you try doing anything else you can bet no one is going to familiarize themselves with a whole new API just to make their machine work with your API.

You don't need to juggle the many dozens of energy interfaces you'd end up with,

Flux is just a single KV set, so it's the same as IEnergyStorage in this regard except it doesn't tie "storing" behavior to the power unit.

and you don't need to deal with named energy which usually has completely different units and scales..

The conversion interfaces mean that if you're writing a mod that only adds machines (not a power API) need to handle only a select type of energy source and the modpack author or user gets to add convert-ee-to-rf.jar if they want all RF machines to work with EE (balancing always ends up on end-users, not mod authors). The only issue is implicit conversion which isn't a thing and that's why conversion system exists - to allow for more nuanced conversion rules at information level than being able to just plop 3 converter blocks next to each other (at which point all the info that exists in the global scope is reduced to a simple function that multiplies 2 numbers). I fail to see how that's better.

Your proposed system seems like it'd be more of a hindrance for modders than a benefit,

They don't need to implement any of the transfer interfaces if they don't want interoperability, but those interfaces define a minimal set of functions they'll need to specify on their classes anyway if they want to achieve behavior that's described by those interfaces (except properties which is extra for allowing info like resistance to be shared with impl erasure).

...as well as some disadvantages, such as basically making every mod the same

As I've mentioned before, IEnergyStorage enforces a pattern where all power APIs deal with a single int value units. So the opposite is true as no such interface is provided for mods like Tesla.

and destroying all semblance of progression in a mod by connecting their gadgets to another mod's overpowered energy generator..

I've said that conversion isn't implicit. It's far more likely that IEnergyStorage int can be confused for a wrong unit and mistreated than an ID'd power unit (you have to know what you're accessing to get to the value). This is really a strawman argument as it has nothing to do with power APIs following a spec and IEnergyStorage already exists without enforcing any of the rules the proposed system would allow so what you're saying is "we don't want mods to be able to tell their machines are connected to an overpowered generator so that they can deal with that better". Balancing is up to end-users and modpack authors, you can't prevent overpowered generator or "IC2 cell duplicator machine" as a mod dev - esp. so with an interface that only tells you "yup, I have an int in this TE?".

• That's why FluxReciever knows the source which produced the unit - this allows you to do magic like accepting units from "only machines from xyz.trusted.mod" without depending on the power API.

I don't see modders going for this system if it ends up being more work for them. Which it will. Because it's way overengineered.

It's marginally more work and provides benefits in terms of:

• mods taking up less space
• power systems being serializable out of the box
• mod interoperability
• eases creation of more unique power/magic/... mods
• modpack authors being able to control interactions better

Thank you for reading through the discussion and for your input.

[Commoble]

As a mod dev with their own power system that doesn't use FE, I will be using IEnergyStorage for cross-mod compat and not this

[Caellian]

That's cool. I'm not proposing anyone use the example I've provided as it's a) 6+ years old and unmaintained, b) not officially supported by the mod loader which means you gain nothing by implementing it on your own.

If you have any more specific requirements than those IEnergyStorage addresses feel free to share as that would help further the idea/discussion.

I personally see a lot of room for improvement of the currently provided API as I've previously shared which is why I started this thread.

[Commoble]

IEnergyStorage makes every TE a storage component - a solar panel doesn't really store energy (assuming that energy storage besides potential was a thing IRL). A producer/consumer/transport model would make much more sense and make mods feel less like compromises have been made so they work with Forge and each other.

Not true, I can easily make a power system where solar panels don't use FE at all and only the compat blocks or batteries use FE

As I've mentioned before, IEnergyStorage enforces a pattern where all power APIs deal with a single int value units. So the opposite is true as no such interface is provided for mods like Tesla.

Only at the interface between power APIs. You can still use doubles or whatever internally.

[Technici4n]

We're starting to run in circles.

Having a live system which isn't controlled by a single number makes the game challenging and fun.

If I made a mod that added realistic motors, that would mean that powering them through IEnergyStorage I'd have to make a limiting design decision.

The issue is that the current API is too restrictive to let anyone do anything unique and just provides means to do more of the similar/same.

Then don't use IEnergyStorage and make something unique with your own custom API... (see: Create, IC2 Classic, etc...)

[Technici4n]

You can't create a conductor which only conducts and doesn't store without depending on a specific power API, and then you're specializing them for precisely that one API.

This is incorrect too, see for example Powah which has cables that do not have an energy buffer. Another example is the Cryo-Stabilized Fluxduct from Thermal Dynamics.

[Caellian]

We're starting to run in circles.
make something unique with your own custom API

That's what I'm trying to address. We're shifting goalposts here left-to-right which is why I'm running in circles. Your lines of reasoning are:

• Everything is inter-operable and there's nothing current system doesn't work for.
  • I provide examples of that not being true.
    • "Write a custom API".
      • I say that wouldn't be compatible with anything else
        • You tell me to use IEnergyStorage which I can't without sacrificing the idea, so I again, return to the main point.
          • You say everything is inter-operable based on ~4 mods sharing a very similar design.

I'll instead link you to:

• Ad nauseam, and
• Straw man

You haven't really addressed any of the issues I've mentioned (none of you have), you just keep deflecting with singular counter examples, incorrect comparisons and saying that 4 interfaces with 4 methods each are "too-complex", saying it wouldn't be idiomatic java because (float) T_value is somehow different to (float) int_value. The only valid reason not to provide a better API was provided by me and it's an educated guess really...

• You're literally grasping at straws and saying nonsense at this point just to avoid addressing anything... There's at least 2/3 bad things with the way things are at the moment, but you can't seem to acknowledge any. Do I have to be your bestie for any of you to actually consider the thing I'm saying without making up fictitious excuses to keep things the way that suits you and everyone goes along with.

Would it be that bad to provide 3/4 interfaces instead of one? It's pretty clear what each does. They can be tweaked to support push-based model.
Even if it wasn't a property based system, adding a bit more structure to the API would only help the users of that API.

[Technici4n]

Let me give a summary of my points, perhaps that will be clearer:

• IEnergyStorage already does everything that's expected out of a basic power API.
• If you need something more then make a custom power API.
• There is no gameplay where arbitrary conversion between custom power APIs makes sense.

[Caellian]

• IEnergyStorage does everything you need it to do.
• A custom power API as a requirement unnecessarily complicates the dependency chain for downstream mods which is something this discussion aims to resolve
• Achieving better mod compatibility without having to branch out every implementation to cover all use cases improves DX, built mod size, load times and how much disk space mods dir occupies.
  • So you're right in saying it doesn't affect gameplay - it's not supposed to.

[Lanse505]

Okey so personal 2 cents:

• The current power api while not covering every single conceivable use-case, is purposefully made to work as a simple interoperable power api with the basic features a power api should have/feature as a bare minimum. It's not perfect but it is exactly what it should be and nothing more, which is exactly what I'd expect from a power api provided by a core framework such as Forge.
• While I see your points Caellian, I don't think what you're purposing is a good fit to be something like Forge. (Personal Opinion)

Personally I'd like to say thanks for contributing to the discussion about improving the power api, but this is just not a good fit of a solution in my opinion for use in an API such as Forge.

[TelepathicGrunt]

@Caellian I’m going to be a bit frank. You wanting to make a new system that overhauls power api and starting a discussion on that is totally fine. That’s what discussions are for.

However, it is also fine for discussions to not actually move to doing actions. Sometimes, the ideas proposed just flops or fails and that’s ok. Just means it is time to close the discussion.

Reason I wanted to make that clear is because this discussion had 3 big modders who uses power apis all not liking this proposed power api. If the very target audience this power api was for all do not want to use it and will refuse to use it, then the api failed before it was even made. An api needs to be actually solving a real problem and be desirable to the modders themselves. Making an api and no one using it is a waste of time and effort and solved nothing.

Again, it’s totally ok for ideas to fail. In this case, it’s extremely difficult to beat the current IEnergyStorage because of how flexible and useful it is for many modders and doesn’t cause too much issues. There’s probably a better power api that could be made but your proposed system isn’t it. Listen to the actual target audience of the very people that would be actually using power apis as they have the most experience of what works, what doesn’t, what pain points there are, and how it all works

[Caellian]

I'm fine with it not amounting to anything too, I see that this is a passion project for many and that implementing something along the lines of ActivityPub just for power is a tricky endeavor which could take a lot of trial and error to do properly.

The api didn't fail before it was even made because that's not possible - the proposal did. And to be clear the modders who said they wouldn't use it said so because the current API is sufficient for their power systems which is not to say that it is for something else which is apparent if you look at something like Create.

Regurgitating the point that IEnergyStorage is flexible and useful ad nauseam doesn't make it true:

• Having to round everything to an int is not flexible
• Forcing expression all power systems in terms of a single value is not flexible
• It is only useful if your power units can be expressed as a single int value

[KnightMiner]

If your power units cannot be expressed as a single int value, then do not use the forge capability, you are not compatible with the expectations of those using it.

If you want compat with other people who don't use int, then make an API for all you who don't use int to use. Personally that sounds terribly unintuitive to me though as why does the end user need to know about floating point precision to use power?

[Caellian]

I suggest IEnergyStorage is removed from NeoForge as it doesn't properly encompass behavior it's supposed to and can/should be separated into a library that people can opt-in to use - it's just bloat. If anyone needs to, they can, and already do, provide a power API so the capability in question only exposes a limited interpretation of power units which isn't context aware. It also negatively impacts performance which is critical for power systems because of calculations required for converting energy units back and forth and having all classes require a pointless heap lookup while gaining nothing from it in return.

It is clear that IEnergyStorage doesn't support all the edge cases properly, so the point of having it in code base that's supposed to deal exclusively with mod loading as it's been made clear, and not provide any compatibility between mods besides them knowing other mods also add blocks and items to the game is frankly mute.

IEnergyStorage also doesn't provide any benefit to players or help improve the gameplay in any way, so... that's a valid point worth considering.

I suggest the devs avoid dealing with APIs containing abstractions levels higher than a single isolated interface as it leads to some disadvantages, such as basically making every mod the same, and destroying all semblance of progression in a mod by connecting their gadgets to another mod's overpowered energy generator.

[KnightMiner]

I think there is a huge difference between a forge feature not supporting your usecase and it supporting no one.

You also directly contradict yourself when you say that Forge's API needs to support everyone's usecase, but it also should not allow people converting from one type of power to the other. If you don't want people converting other mods power to your power, just don't use the Forge API. By using the Forge API, you give other mods permission to give you power and accept whatever that does to balance. No one is forcing you to agree to that standard.

[Caellian]

No, I just repeated the same points made against my proposal and applied them to IEnergyStorage because they make more sense in that context.

Thanks for noticing at least auto-contradictory part in some of them. I assure you, there's at least 5+ more logically unsound or completely incorrect arguments in the discussion. The fact is that the first response I received was "let's close this", and none of the developers in this thread even tried understanding the proposal, so I'm just talking to a very dumb brick wall at this point. Had they given the proposal an honest consideration, 90% of the stuff they said they wouldn't because they'd know what they're saying is incorrect and besides the point.

As things stand currently, they're making the mod loader mostly for themselves, so unless one of them wants to do something along the lines of what's proposed here, this discussion won't move forward and I'll just get the same senseless responses I already did.

I don't feel like rewriting the initial post over and over again in the comments, this discussion is pointless, people are apparently too dumb to get what I'm saying or at least playing dumb. So... enjoy the "super clever" int abstraction and monotone mods.

[KnightMiner]

Had they given the proposal an honest consideration, 90% of the stuff they said they wouldn't because they'd know what they're saying is incorrect and besides the point.

Had you given what they said an honest consideration, 90% of the stuff you said you wouldn't because you'd know what you're saying is incorrect and besides the point. Your pronoun tongue twister applies just as much to your arguments.

The fact is, you keep both proposing that all mods that use energy need to share a unified API, and that the fact that mods can change the balance of other mods is a problem. I see zero point of an abstraction that says things are not compatible, if you want to be incompatible just don't use the same API. This is what everyone else is telling you, and what you are refusing to understand is being said to you.

As things stand currently, they're making the mod loader mostly for themselves

This is hilarious. I have zero involvement in the forge/neoforge team, and the modloader gets plenty of features for my mod. People telling you that they do not see the benefit of your idea does not mean that they only make things for themselves. It means your idea might just be bad.

I don't feel like rewriting the initial post over and over again in the comments, this discussion is pointless, people are apparently too dumb to get what I'm saying or at least playing dumb. So... enjoy the "super clever" int abstraction and monotone mods.

To be blunt, I think you are the one too dumb to get what everyone else is saying. If everyone is in agreement except one person, that one person is probably the one who is wrong or is poorly presenting their case; calling them all dumb does not make you more convincing.

Its not that everyone thinks mods should only ever do ints. Its that the mods that wish to be compatible do nothing more than ints, and the ones that do more complicated stuff do not wish to be compatible. You are absolutely free to use non-ints for your power, make it as complex as you want. But then asking that your power system is compatible with people who use ints is just nonsensical.

[TheCurle]

This discussion is getting nowhere. I have locked it to prevent a steady descent into name-calling and insults that have already begun.