Prototype Throttle

[warjort]

What:
Hopefully this prototype will make the discussions on #1632 and #1604 more concrete?
It at least gives something to test with to understand the consequences of the throttle in different generators.

It uses a cover for single blocks.
For multiblocks it just adds some generic code to FueledMultiblockController

There is one major bug which is due the way I am injecting the throttle into a single block generator.
On a reload of the generator/cover there is no natural hook to reinject the throttle into the generator.
So reloading the world means you have to disconnect and reconnect the cover for it to work.

The other major limitiation of this prototype is that the throttle is "trivial".
So it has pretty much no affect on the overall fuel consumption. e.g. 50% throttle means both the recipe and duration are halved.
It does change the minimum fuel required for a recipe to run and the power output in line with the throttle.

Finally I have made no attempt to reintegrate the LargeTurbine into FuelRecipeLogic with the canProduceEnergy(), etc.
So I think the throttle will have no effect since the LargeTurbine overrides the voltage calculation and that is the only thing really changed in this prototype.

Some things I found while trying to implement this:

• At least for the MB diesel engine, it is not as simple as just enabling the throttle. Its processing includes lubricant and oxygen that will need to be modified in line with any fuel consumption change. Gregicality has multiblocks with similar processing.
• I think there is a bug in the LargeBoiler where it doesn't mark the controller as dirty when you change the throttle in the GUI and so the change may not be saved
• Having the throttle in a cover makes the GUI awkward to use, see [Suggestion] Cover augmentation of machine UIs #1441, I added the recipeOutputVoltage to the cover's GUI so you at least have some feedback without having to switch displays.

And now you can rip on my implementation. :-) The main reason I wrote it (besides giving something to experiment with) is so we can pin down where the multipliers need to fit into the api.

[galyfray]

the throttle is a complex behavior giving it a default way of doing things for single block machine can be a good idea but not for multiblock as each of them as custom behavior that may interfere with the default throttle. A default behavior for something this complex might just ending up making things harder to get them clean when implementing it.

[galyfray]

by doing things this way I don't think the calculateXXMultiplier was need. One the new questions to debate is how to integrate the throttle policy if you do it this way all multiblock using the FueledMultiblockController will have a throttle even if it makes no sense for the machine. I think that throttle should be added individually on each multiblock. to avoid code duplication a method can exist to add the throttle text to the TextList allowing for easier disabling of the throttle in case you extend a throttlable multiblock.

[warjort]

"if you do it this way all multiblock using the FueledMultiblockController will have a throttle even if it makes no sense"

These are not intended to be the final implementations. They are quick and dirty implementations so we can tease out what the problems are with adding a throttle to each generator. This should better inform how the real implementation should be done.
Its an "enable it for everything and see what breaks" excercise. :-)

[galyfray]

These are not intended to be the final implementations. They are quick and dirty implementations so we can tease out what the problems are with adding a throttle to each generator. This should better inform how the real implementation should be done.
Its an "enable it for everything and see what breaks" excercise. :-)

okay still I'm pointing out problems I see to avoid them later

[warjort]

by doing things this way I don't think the calculateXXMultiplier was need.

Yes, I was also trying to see how to implement a generic throttle if those methods don't exist as requested by @Archengius.

[warjort]

On a reload of the generator/cover there is no natural hook to reinject the throttle into the generator.

I have done this in a first tick handler for the cover. This at least means you no longer have to break and replace the cover on reload.

But this is not a real fix because the FuelRecipeLogic (a MTETrait) will tick before the covers.
See MetaTileEntity.update()

[warjort]

My conclusion is that a cover is not that good of a fit for a throttle.

The pluses for a cover are:

• It does not require changing existing blocks
• Somebody can make an alternate throttle implementation by creating a different cover.

The issues with doing it this way are:

• The order of initialisation on block reload
• Having seperated guis for the generator and the throttle
• What happens if somebody attaches 2 throttle covers?
• Whether single blocks should even have a throttle - i.e. it should be an incentive to use the multiblocks

If the single block generators are to have a throttle, I would suggest doing it inside the block.
This would keep everything in one GUI (provided space can be found on that GUI to fit the throttle controls).

[galyfray]

If the single block generators are to have a throttle, I would suggest doing it inside the block.
This would keep everything in one GUI (provided space can be found on that GUI to fit the throttle controls).

in fact single block generator stop using fuel when they are not producing therefore I don't see any reason why you would be using a throttle with single block generator

[warjort]

in fact single block generator stop using fuel when they are not producing therefore I don't see any reason why you would be using a throttle with single block generator

The reason would be to reduce fuel consumption when you don't need the generator running at full power.
But like I said, maybe this should be considered an advanced feature reserved for multiblocks.

[galyfray]

The reason would be to reduce fuel consumption when you don't need the generator running at full power.
But like I said, maybe this should be considered an advanced feature reserved for multiblocks.

if the generator doesn't need to run full power it will full his internal buffer then stop reproducing a throttle behavior without a throttle.

[warjort]

if the generator doesn't need to run full power it will full his internal buffer then stop reproducing a throttle behavior without a throttle.

The idea is to let people that want to, play a game where they can monitor their batteries and turn the generators up or down to balance their energy output, gaining better fuel consumption as the reward.

[galyfray]

The idea is to let people that want to, play a game where they can monitor their batteries and turn the generators up or down to balance their energy output, gaining better fuel consumption as the reward.

better fuel consumption ? were ? inside the throttle efficiency ? so far it's always below or equal to 100%

[warjort]

so far it's always below or equal to 100%

100% is just the prototype value.
It shouldn't be linear it should follow some curve where reducing the throttle to match your energy usage increases your fuel efficiency. But if you go too far, your recipes will start failing because the machines aren't getting enough power.

I see it as feature for those players that like to micro-manage and optimise. It gives them one more knob to turn. :-)

[galyfray]

It shouldn't be linear it should follow some curve where reducing the throttle to match your energy usage increases your fuel efficiency. But if you go too far, your recipes will start failing because the machines aren't getting enough power.

this might just ending up in people making more machines reducing their throttle to have better efficiency and keep them running knowing they will stop when not needed

[warjort]

this might just ending up in people making more machines reducing their throttle to have better efficiency

If they want to invest the materials then fair enough.
And there is always the 16A per cable (and voltage loss over distance) that means there is a limit to that trick.
You can't replace 16 generators at full throttle with 32 x half throttle generators, because you will explode your cables trying to transfer 32A. :-)

[galyfray]

You can't replace 16 generators at full throttle with 32 x half throttle generators, because you will explode your cables trying to transfer 32A. :-)

use battery buffer they will easily accept the two generator at half power and return a constant 1A without any loss if you do things in a smart way

[serenibyss]

You can't replace 16 generators at full throttle with 32 x half throttle generators, because you will explode your cables trying to transfer 32A. :-)

You should test this, I think you may be surprised :) Its a separate issue I’ve been looking into for some time.

[warjort]

You should test this, I think you may be surprised :) Its a separate issue I’ve been looking into for some time.

I see what you mean. The cable burning only checks the current energy transfer request's amperage.
It doesn't take into account the perTick amperage of the EnergyNet.
You learn something every day. But like you say different topic.

[warjort]

if you do things in a smart way

Exactly. We don't want to develop one of those RPGs where you have 4 dialogue options but they all have the same outcome.
If every method just leads to the same result then what's the point?
Players will be more engaged if they are finding new ways to overcome perceived obstacles/limits, preferably with tradeoffs.
Anyway, lets not get off topic again.

[galyfray]

Players will be more engaged if they are finding new ways to overcome perceived obstacles/limits, preferably with tradeoffs.

what I am fearing with this is people using more and more machine leading to more and more tilentities leading to lag I don't think it is a good things to do to give bonus to use more machines to do the same things.