Add hints for constant consumers and producers?
Darkhax opened this issue · 10 comments
The idea is to create a new capability which contains a getConstantType method. This method would return a value from EnumConstantType which would include CONSUMER, PRODUCER, BOTH, NEITHER. The purpose of this new capability would be to provide hints for other mods about how the capability user is handling power.
Arguments in favor
- It would allow for an optimized power cable network that only accepts constant providers and consumers.
Arguments against
- The system can easily be abused. Blocks that do constant block updates could be used to completely bring a server to its knees.
- Providing hints might make things harder for other power networks, or encourage a specific power network.
- This is only useful for a very fringe group of blocks and conceivably wouldn't help anyone.
This is not a bad idea, but I would move those methods to a separate optional capability. I assume that you'd want the essential interfaces to remain as simple as possible.
That is a good suggestion @rubensworks. I will add that to the main post as another alternative.
Edit: I am actually going to alter the entire thing to use that suggestion instead.
Perhaps create something like IConstantTransfer and have it extend ITeslaHandler
If only twitter supported polls lol. I will add both suggestions to the main post.
I believe a general consensus on this issue has been reached. A new capability will be added to support this.
I would consider this as being closed way too early in terms of the spec (but probably not regarding should there be something like constant producer/consumer).
If this is only a boolean it would be extremely limited. I would even say the effort to use it makes it nearly unusable for most cases it could optimize.
For example should it still be based on update via block updates, it would not be the fastest way of doing it.
And you potentially do not know how much you need to add or substract from the global constant without caching each and every part of the energy network before and compare it somehow.
In most cases without using a extremely sophisticated caching approach, this essentially means you have to rebuild the whole network with every block update.
Also it needs at least something to tell, if they are active as well as update this state at any time.
Sure you can use block updates, but imagine a larger server with a couple of hundreds solar panels or similar and all are simultaneously sending a block update every time the switch from day to night mode.
You could maybe argue that these are actually not constant producer, but then it would pretty much limit it to creative producers or void consumers.
A naive solution will most likely result in a situation in which a already ticking TileEntity due to having to burn fuel, update the progress etc replaces a few method calls to mutate an integer of a local or global buffer with potentially very frequent block updates resulting in complete network rebuilds. Worst case one rebuild per updated tile entity per block, so potentially a huge number per tick.
Using an observer pattern would be one option for a better solution. In this case a network could register itself as listener on any producer/consumer and they could simply notify them about the change. If it acutally post the change and not just notifies about an update, it is as simple as say sending -80 once a producer changes from being active and producing 80 energy to being inactive and 0 energy. Even with hundreds of machines updating, it could be very easily implemented with the same number of additions.
The problem with this approach is, that it moves the API from being a protocol about how 2 entities can exchange energy, which pretty much anyone can use and is simple to implement and essentially all other commonly used energy systems currently a, to a full blown network/grid solution, which could use a reactive approach for everything (similar to observer pattern) instead of the take/givePower approach. And some other interesting things.
But ultimately it would be more of a pipe mod without actual pipe blocks/item and anyone could use it to make their own ones, while multiple mods can still share the underlying network.
It is really a decision about what it should be.
- A simple protocol to let everyone exchange energy between two entities (and not more) and leave any higher layer to the mod devs themselves. Like creating a fast and efficient network with their custom approach internally, but still appear externaly as this API to ensure interoperability. Even if it might not be the fastest way.
- Or something like a full stack framework for an easy implementation of your own energy pipes/conduits/wires and leave the heavy lifting of managing the network, distributing the power etc to the framework. With all the advantages and disadvantages.
Trying to provide a compromise and at least give some hints to networks is in the long run a bad idea. Not all grid/networks are the same and some hints might even make it harder for a specific network to be use more efficient ways internally. Or it makes implementing a basic tile entity way harder because you have to implement dozens of hints for different networks
I am glad that you brought all of that up @yueh. The idea from the original suggester was to add this only for blocks that were truly constant. Like a creative power cell. The original concept included blocks similar to the water flower in botania that always produces a constant amount of mana until it is broken. As you mentioned in your post, such use cases are far and few between, and giving hints for a specific network is not a good idea in this situation.
@brandon3055 I just re-read my post earlier, I meant to say "if only github supported polls" lol. Too many things going on at once X)
I have probably forgotten a couple of edge cases.
Like it would be possible to have something inserting power over a small air gap, like the mana spreaders from botania while still producing a constant amount. Which would also make block updates or neighbor notifications impossible to use. Thus it might be tricky to solve chunk loading wihout having a situation, where the generation constantly increases or decreases with every reloaded chunk.
While a reactive energy system would certainly be nice and could provide a slightly better performance as only the network has to tick with some infrequent updates to change the the overall network generation/consumption. It could probably even use a dynamic tick rate and slow down, if the overall network capacity is high enough to skip a few ticks.
But it certainly would turn it into a real mod with some basic transport blocks and not a simple API.