[Feature request] Battery charge rate set in smaller increments than 10%

[sebbes333]

It would be extremely useful if the batteries wire pin: "SET_CHARGE_RATE" would actually set the charge rate to ANY numerical values, not just fixed increments of 10%.

Why?
I'm making a sub where all power from the reactor (20k kW) goes directly into a battery bank (40 batteries, full reactor utilization possible), where each battery is individually charge controlled by automation. The automation sends whole numbers (integers), but the battery charge only changes every 10% increment, which in my case makes the power JUMP up/down by 2100 kW each time it changes, which obviously burns out my electrical circuits.
The whole idea about making this system was to ELIMINATE power spikes, not CREATE super huge power spikes! But the current system makes this impossible & is really disappointing.

Ideally I would like 0.1% increment sensitivity.
There could be some checkbox or number field (in the editor? or accessible from in-game somehow?) that lets you decide how sensitive the charge_rate increment will be.

[mygamingaccount]

Weird, there's a float RechargeAdjustSpeed that is just a stub parameter that is never used. I thought it would give a solution to your problem, but it changes nothing

[Oukido]

The game has a round function that dictates the increments:

https://github.com/Regalis11/Barotrauma/blob/06e72bb636f47e736e9470ea978efaa09875f0f7/Barotrauma/BarotraumaShared/SharedSource/Items/Components/Power/PowerContainer.cs#L109

It would be nice if the device had a toggle in the settings and in the ingame interface that would allow to disable the round function:

[Editable, Serialize(10.0f, IsPropertySaveable.Yes, description: "The current recharge speed of the device.")]

        public float RechargeSpeed
        {
            get { return rechargeSpeed; }
            set
            {
                if (!MathUtils.IsValid(value)) return;              
                rechargeSpeed = MathHelper.Clamp(value, 0.0f, maxRechargeSpeed);
                if (isIncrementToggled)
                    {
                        rechargeSpeed = MathUtils.RoundTowardsClosest(rechargeSpeed, Math.Max(maxRechargeSpeed * 0.1f, 1.0f));
                    }
                if (isRunning)
                {
                    HasBeenTuned = true;
                }
            }
        }

isIncrementToggled would be the variable used for the checkbox

ontop of that is a Step variable that probably does also dictate the increment interface-wise.

https://github.com/Regalis11/Barotrauma/blob/06e72bb636f47e736e9470ea978efaa09875f0f7/Barotrauma/BarotraumaClient/ClientSource/Items/Components/Power/PowerContainer.cs#L70

but since this code creates an object there needs to be a way to interface the Step variable from outside.

[mygamingaccount]

Keep it simple. What good does an additional toggle do? Nothing.

Just taking any value would work great. What are the downsides?

[Oukido]

Personally, I agree. There is probably not much of a downside. But the Devs may have had the impression that it would be difficult to set the slider to a desired value if the screen is shaking when heavy fighting action is going on, and the demand arises to change the recharge speed. Going with this original intent, a toggle would keep both both benefits.
But the easiest solution would be to delete the line with the round function and setting the step to 0.0f.

Edit: It might even be possible to keep the step at 0.1f and only have the 10% increment on manual interactions with the slider. But that is just speculation.
Edit2: Just tested the theory in a test build and deleting the line worked just fine in a subeditor testrun. Was able to set the chargerate so it resulted in 1kw decrements in reactor load, while the slider of the interface still snapped on 10% increments when used manually.

[Ek-Videogames]

They added a smoothing effect to try to mitigate the effects of grid jumping up and down, however the electrical system is still very prone to overvoltage - ironically - when the power demand of the submarine is at its lowest!

• This is because if the grid is "strained" you actually have a larger margin of error because its +/-50% of the current voltage.
  When you have 4000kw load you can still easily handle 6000kw (a difference of 2000kw!)

• But when a junction is only under say 500kw load, then the power only has to increase - or load decrease - by 250kw to cause an overvolt event. When lowering grid load in these situations having an added degree of accuracy below 10% charge would certainly be beneficial.

[sebbes333]

Why not add a "STEP_SIZE" number variable (0.01 - 100 %, currently set to 10 %) that determines how big the increments is (I doubt anyone would need a smaller step size than 0.01, but maybe it can go even lower? Higher is unnecessary because it basically means either On or Off).

Or there can be 2 variables: "STEP_SIZE_INTERFACE" & "STEP_SIZE_AUTOMATION", accessible in the editor.
So you can set the "STEP_SIZE_INTERFACE" to 10 (so the slider only changes in 10 increments)
But the "STEP_SIZE_AUTOMATION" can be set to eg. 0.1 for fine control through automation.

With this, anyone using the editor can set the batteries (and capacitors) to accept whatever step-sizes they want, even if there are different needs for the interface & the automation.

[Oukido]

I'm still liking the idea with the toggle

recording.mp4

[sebbes333]

I like that it is accessible & changeable from inside the game.
(I still wonder if there is some nice way to make the step_size changeable too in the GUI?)

[mygamingaccount]

This is definitely the best way if you wanted to switch between 1% and 10% steps
But if you forget that there ever were 10% steps, why would you ever want to turn it on?

[Oukido]

I think the gui should have as few elements as possible to not overload it with too many items. That being said, if you add ingame changeable values you will end up with an additional gui box on the right side of the screen that will contain the input fields for the variables, similar to how it is with signal components. If you decide to make them not ingame editable you will only be able to change them in the sub-editor. But this leads to vanilla subs not being able to benefit from the changes, but those are still in high usage of the playerbase.

About the 10% steps. By default it would be ON so the vanilla behaviour would be the same. But you could also turn it off and install a battery-carge-circuit ingame on a vanilla sub. So the actual question is when do you want to turn it OFF.

[sebbes333]

When I want to turn it off: (under the "Why?" heading)
#9420 (comment)
The middle section in my original post, for example.
Basically, when 10% jumps are too big gaps, for example when using many batteries.
But i guess there are other situations too?

[Oukido]

Yes I see that I have wrote that in a misleading way. What I meant to say is in the context of the question "Why would you ever want to turn it on?"; You rather want to turn it off when you see the need to, for example when using control circuits.

[mygamingaccount]

I think the 10% steps should be deprecated.

Have a horizontal slider where you can set it in 1% increments by dragging however you want, move the slider with A and D (just like the nav terminal BTW), and optionally round to 10% when you use the mouse wheel.

It could take any floating point value from the set charge rate input without quantization.

[sebbes333]

Yes, mostly because that is what is expected from a slider interface, that you can set it to ANY value in the interface, not just some of the values.

[Oukido]

Update: Still working on it, there are a few bugs going on, mainly in network communication which also does rounding in the form of integer cutoff, and the problem that 1% increments lead to the problem of charge starvation at the last few % where 1% equals 0 charge rate in the case of capacitors with exponential charge rate.

[sebbes333]

Yeah, I think the reactor-solution is much better for the network (assuming a reasonable delay between updates).

Other alternatives I can think of is:
Maybe the battery can send an update when you exit the interface?
(and/or an update like every 0.1 - 1 second when the interface is opened, just so it's possible to still see what effect the changes have)
(or it sends an update when you release the slider (works bad with scroll-wheel changes?))

Or, it kind of keeps its current behavior, it only sends a "correction package" when the battery have made a big enough (10%) change?

(A tangent. I assume the Host have priority over the packages? so no client can use eg. CheatEngine & change the variables & suddenly the ship has infinite battery (it wouldn't prevent the host from doing this, but there is only 1 host, but many clients, so the risk is lower)).

[Oukido]

I've thrown the idea of changing manual interaction overboard and focused on the automation part, since that is what really needs the higher resolution.
I've started a new approach that ended up with way less changes, and did quite well in the testing. Opened a PR for it.

[Chrysaloid]

It's sad that your PR (#9480) is still open, after almost 2 years :(

[NaturalBornCamper]

Could it be made into a mod?

[Chrysaloid]

I'm not a moder unfortunately so I don't know.

[G-M-twostay]

Is this request still active? I would also like one such feature. I think having a step size variable in the parameter tab in sub editor would be good. The ability to adjust battery slider more precise is especially more important if I purchased the improved charging speed upgrade. Not being able to do so will cause weird feedback loop and also load spike in battery buffer.

[DuckY-Y]

Bump,

It would maybe make sense if the player could only increase it by 10% increments by hand but a component connected to SET_CHARGE_RATE would be able to more finely control it by 1% increments.

[kobango]

I have symilar problem with my electrical grid retrofit using eq mod. But you can use Subtract Component and memo to fluid switch battery. For example. If you have 10 battery make memo at 101,102 etc and substract actural charge of battery. You can also make another way using subtract between power and load and symilar mechanism.

[Daniel-Chin]

You hvae 40 batteries? Then you can effectively achieve 10%/40=0.25% increments.

Have a global shared float-valued MEM to store the desired recharge rate R. The i-th battery should then subscribe to R + i * (10% / 40) thresholds.

Example

Suppose: the desired recharge rate R go smoothly from 50% to 52%.

• At the beginning, all 40 batteries are on 50%.
• When R becomes 50.25%, the 0th battery switches to 60%.
• When R becomes 50.50%, the 1th battery switches to 60%.
• etc.

Effectively, the summed load required by the batteries also changes smoothly. @kobango mentioned this strategy earlier.

[Chrysaloid]

Is this still the only working solution in 2024?

[Chrysaloid]

After thinking about it for a while, it's funny to me that this basically achieves what the devs tried to prevent - many network request happening in short amount of time. (Using your example) But instead of 8 requests (50.25%, 50.50%, 50.75%, 51.00%, 51.25%, 51.50%, 51.75%, 52.00%), each updating 40 batteries, we have 8 requests each updating 1 battery at a time, in the same time span. I don't know how the electrical system works internally but I think that update to 1 battery isn't different from update to 40 batteries because in both cases the network configuration has to be recalculated.

Besides that, uneven recharge rate on batteries will make their charge_% uneven as well so each battery would have to have a dedicated controller and there would have to also be a master controller. Master controller would read all charge_%'s and calculate the mean value and then send this mean to battery controllers that would try to keep charge_% of their respective battery equal to the mean.

It's so much more processing to make things right than to just have the charge_% be a floating point value.

[mygamingaccount]

Just wondering what this issue might be that the "devs tried to prevent" (any source on that?)
The navigation terminal sends floating point values without rounding on every tick to control the engine and ballasts, yet this does not appear to cause any problems.

[Chrysaloid]

I was extrapolating from this comment @Oukido made. Limiting network load is a good guess in my opinion. There are many things sending network updates in the game. So maybe the devs thought that batteries were not so important and made their sliders stepped? I'm just guessing.

[NaturalBornCamper]

Is there at least a mod doing this? I didn't find anything on the workshop but I got to say that making a charge controller is a real pain because of the 10% increments, especially at low grid wattage. System detects an overvoltage, starts battery charging at 10% when it only needed 3%, which boost the grid load, overvoltage disappears, batteries stop charging the excess, grid load goes back down, system detects overvoltage again.. rinse & repeat.

[mygamingaccount]

Your controller oscillating is not going to be solved by having smooth control of the recharge rate. It is due to the loop (power -> signal -> power), and the fact there is a delay in processing and applying the result. Barotrauma alone can not solve such differential equations, you have to change how your controller works.

[Chrysaloid]

If you don't mind "small cheating" you can edit submarine of your choice in the sub editor and only change reactor's max power output to 100 GW or 1000 GW and leave it on built in automatic control. No wiring required. It makes reactor react to changes in load much faster thus making the overvoltage time smaller. But it does break balance because with higher reactor max power the Fission Rate for the same load is smaller so the Deterioration Rate is slower so the rods last longer. (I think. I haven't tested it. I'm only relying on the equations from the Wiki.)

[NaturalBornCamper]

@mygamingaccount Yes I figured as much ;) and I'm already working on a solution I think will work.
However incremental charging would have made everything much easier!