Currently only terciary can be used for entities that can switch between consumer and producer, like accumulators and electric energy interface.
https://wiki.factorio.com/Types/ElectricUsagePriority
Having secondary and primary priorities not lock down entities as either drain or source allows for more versatile entities.
When designing and testing power setups an electric interface set to primary for example could simulate both solar source and laser turret drain.
During normal gameplay it would allow for transformators that can drain AND charge accumulators without resorting to hacking together multiple entities.
simplify primary and secondary electric usage priority
-
bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: simplify primary and secondary electric usage priority
I actually gave a change to this system a lot of though, what would happen if you allowed a primary (in and out) or secondary as a priority, how would adding quaternary effect the system...
After spending an hour on it, I deleted it, because I came to the conclusion that it just wouldn't work.
I also had the benefit of looking at the game's source code to figure out how what exists currently works, and tertiary actually has a few exceptions to how it functions.
as an output, how does primary, secondary and tertiary work?
Primary (Solar) gets consumed first, giving power to all entities with a demand.
Secondary (Steam) then gets consumed if there's anything left over with demand after primary has been consumed.
Tertiary then gets consumed if there's still a primary or secondary demand on the grid. it cannot supply power to Tertiary.
as an input, how do the 3 work?
Primary input has highest priority, it will consume anything from all sources.
Secondary input has second priority, once Primary is satisfied, it will consume anything from all sources.
Tertiary input has third priority, and it will draw energy from any Primary or Secondary output if power is available. Again, Conditional, it can't be powered by a tertiary source.
The interesting thing to note is that a primary or secondary source or drain will provide to, or drain from any drain or source, but tertiary (Because it's an input and output) can only supply/drain from primary or secondary, it can't power/drain itself, because if it could, accumulators would try and charge from each other.
If you were to try and add an input/output as primary or secondary, how do you account for the conditions already laid out with the existing system? it can't power it's own level, so should be allowed to power a lower level? if you made a "secondary", you'd end up with a system that can only be powered by primary output (solar) and can only power primary input (laser turrets basically, nearly everything else is secondary), otherwise you run the issue of it being able to power itself.
what about trying to write in a Quaternary? can it draw from tertiary's accumulators? can it supply to them? if you follow tertiary's rules about secondary, yes, it should be able to both supply to, and drain from tertiary, so by having a quaternary accumulator on the same grid as a tertiary accumulator, then it should charge and drain the other accumulator at the same time. Look back at adding "secondary" and you end up with the same issue between secondary and tertiary.
So, what do you do? Like I said, After thinking about it for an hour, I decided... you really can't do anything to change the current system that makes sense with the rules laid out.
As for what is a source, and what is a drain... that is determined by the entity itself. Assembling machine is a drain, Steam engine is a source. the only two special ones is Accumulator is Both and the electric energy interface is either.
After spending an hour on it, I deleted it, because I came to the conclusion that it just wouldn't work.
I also had the benefit of looking at the game's source code to figure out how what exists currently works, and tertiary actually has a few exceptions to how it functions.
as an output, how does primary, secondary and tertiary work?
Primary (Solar) gets consumed first, giving power to all entities with a demand.
Secondary (Steam) then gets consumed if there's anything left over with demand after primary has been consumed.
Tertiary then gets consumed if there's still a primary or secondary demand on the grid. it cannot supply power to Tertiary.
as an input, how do the 3 work?
Primary input has highest priority, it will consume anything from all sources.
Secondary input has second priority, once Primary is satisfied, it will consume anything from all sources.
Tertiary input has third priority, and it will draw energy from any Primary or Secondary output if power is available. Again, Conditional, it can't be powered by a tertiary source.
The interesting thing to note is that a primary or secondary source or drain will provide to, or drain from any drain or source, but tertiary (Because it's an input and output) can only supply/drain from primary or secondary, it can't power/drain itself, because if it could, accumulators would try and charge from each other.
If you were to try and add an input/output as primary or secondary, how do you account for the conditions already laid out with the existing system? it can't power it's own level, so should be allowed to power a lower level? if you made a "secondary", you'd end up with a system that can only be powered by primary output (solar) and can only power primary input (laser turrets basically, nearly everything else is secondary), otherwise you run the issue of it being able to power itself.
what about trying to write in a Quaternary? can it draw from tertiary's accumulators? can it supply to them? if you follow tertiary's rules about secondary, yes, it should be able to both supply to, and drain from tertiary, so by having a quaternary accumulator on the same grid as a tertiary accumulator, then it should charge and drain the other accumulator at the same time. Look back at adding "secondary" and you end up with the same issue between secondary and tertiary.
So, what do you do? Like I said, After thinking about it for an hour, I decided... you really can't do anything to change the current system that makes sense with the rules laid out.
As for what is a source, and what is a drain... that is determined by the entity itself. Assembling machine is a drain, Steam engine is a source. the only two special ones is Accumulator is Both and the electric energy interface is either.
Re: simplify primary and secondary electric usage priority
Moved to won't implement for the reasons that bob explained.
An entity can't produce power and consume power from the same energy priority or it ends up charging/draining itself. The electric energy interface can end up doing exactly that and will do that if you set it to produce and consume power - effectively disabling itself.
An entity can't produce power and consume power from the same energy priority or it ends up charging/draining itself. The electric energy interface can end up doing exactly that and will do that if you set it to produce and consume power - effectively disabling itself.
If you want to get ahold of me I'm almost always on Discord.
Re: simplify primary and secondary electric usage priority
I'd like you guys to reconsider this request, at least in some form. I'd love to see accumulators open for any of the other four modes that I see elsewhere (primary-input, secondary-input, primary-output, secondary-output). I realize that, at that point, they effectively cease to become "accumulators" since they will not be able to both charge and discharge, but I am working on a mod which wants to handle half of that electric interface itself (see my help request here for a better problem definition).
To be specific, I'd like to have an accumulator which is only able to charge (even from other accumulators), and one which is only able to discharge (even to other accumulators). The charge-only accumulators will be charged by the electric network they are attached to and discharged by scripting, and vice versa.
I'm currently looking at alternate ways to model this, and nothing quite works well. For example, modeling an input only source seems like it should be done with an assembler, but I lose the easy access to animation cooldown and (as far as I know) have to deal with the fact that the entity is now clickable and presents a GUI (which I don't want/need). I could also model it as some multi-entity structure (probably a visible accumulator which I manipulate and a hidden assembler which does the actual work mechanically), but the devs have repeatedly said (and I happen to agree) that such structures are bad form in general since they introduce issues with keeping the various parts of the structure in sync with each other (eg, one part is deleted/destroyed and the other part has to do the same, which can be difficult).
If for some reason this doesn't work within the game, can you at least have the game perform checks of the prototypes and throw errors if an invalid value is used for usage_priority? It took way too long for me to realize that the value has literally no meaning in the context of an accumulator, and seeing errors about not being allowed to use non-tertiary values would have been much more helpful than silently ignoring the incorrect values and substituting the "correct" ones.
rainboy wrote: The basic issue is that I would like my long range power solution to play nice with solar powered bases. This means that my input tesseracts need to be able to be charged by accumulators within the same network. Secondarily, I would like to allow my output tesseracts to support charging other accumulators on their networks, since they are rate limited and somewhat expensive. I was thinking that both of these problems would be solved setting the usage_priority to "primary-input" or "secondary-input" and "primary-output" or "secondary-output" respectively. However, even with these settings, I still don't see any transfer of power between any accumulators and tesseracts.
To be specific, I'd like to have an accumulator which is only able to charge (even from other accumulators), and one which is only able to discharge (even to other accumulators). The charge-only accumulators will be charged by the electric network they are attached to and discharged by scripting, and vice versa.
I'm currently looking at alternate ways to model this, and nothing quite works well. For example, modeling an input only source seems like it should be done with an assembler, but I lose the easy access to animation cooldown and (as far as I know) have to deal with the fact that the entity is now clickable and presents a GUI (which I don't want/need). I could also model it as some multi-entity structure (probably a visible accumulator which I manipulate and a hidden assembler which does the actual work mechanically), but the devs have repeatedly said (and I happen to agree) that such structures are bad form in general since they introduce issues with keeping the various parts of the structure in sync with each other (eg, one part is deleted/destroyed and the other part has to do the same, which can be difficult).
If for some reason this doesn't work within the game, can you at least have the game perform checks of the prototypes and throw errors if an invalid value is used for usage_priority? It took way too long for me to realize that the value has literally no meaning in the context of an accumulator, and seeing errors about not being allowed to use non-tertiary values would have been much more helpful than silently ignoring the incorrect values and substituting the "correct" ones.
Re: simplify primary and secondary electric usage priority
Now that I've discovered that the tertiary limitation is not present in the electric-energy-interface, I can mechanically achieve my desired effect... however, I don't see a good way to conditionally animate electric-energy-interface like I can for an accumulator. It doesn't seem to support any of the special animations that accumulators do, nor do I see any way to display a static picture when the machine is not working or conditionally change its working state (for accumulators, I just have to make sure that this tick's energy is not equal to last tick's energy to ensure one of the two animations will play).
I still think I really just want my original request (eg, accumulators support all usage priorities), but I could also implement things if electric-energy-interface supported accumulator-like charge/discharge animations (which I suspect is much more difficult under the hood, since you'd have to figure out when to use that over the standard "working" animation when both conditions held true).
I still think I really just want my original request (eg, accumulators support all usage priorities), but I could also implement things if electric-energy-interface supported accumulator-like charge/discharge animations (which I suspect is much more difficult under the hood, since you'd have to figure out when to use that over the standard "working" animation when both conditions held true).