Feature request: increase thrust accuracy per engine

[dcrockwell]

It seems baked in that the thrust limit accuracy is in increments of 5, which make it impossible to set the thrust on engines accurately for true vtol stabilization via propellers only, and not SAS-assisted (unless I'm missing another way of doing this?)

Perhaps kOS could introduce another way to set the engine thrust to a fine value so that thrusts of 0.01 are possible?

[TDW89]

just to check do you mean 0.5 or 5 because i am limited to 0.5 increments. The value stored in engine:thrustlimit isn't rounded but its effects can be observed by looking at the engine output while changing the limit. From the look of it though its a ksp thing not a kos thing since kos storing / reporting the un-rounded number.

[dcrockwell]

Right, I meant 0.5. It's not sensitive enough to do a pitch correct via thrust only. I have to fake everything via SAS at the moment.

[Dunbaratu]

kOS is mimicking what the user interface slider does. It may be possible to make it more accurate, but it was deliberately limited to 0.5 steps because we made it match the UI, not wanting to let people break the stock game's rules, not knowing why SQUAD did that.

[dcrockwell]

I've been in contact with the Toadicus and I'm begging him to enable this via tweakable everything. I think it's wise for kOS to continue supporting SQUAD standards.

https://github.com/toadicus/TweakableEverything/issues/6

[Dunbaratu]

I'm not 100% convinced this issue should be closed. Let me explain:

Well, kOS still has it hardcoded to 0.5, so I think you'll still have the same problems trying to model it from a kOS script regardless of what tweakable everything does, which will only affect the UI, not the script. This is the relevant line from the kOS C# code:

 AddSuffix("THRUSTLIMIT", new ClampSetSuffix<float>(() =>
      engine.ThrustPercentage, value =>
          engine.ThrustPercentage = value, 0, 100, 0.5f));

See that 0.5f ? That won't go away from our code just because tweakable everything made a change to their code.

An argument could be made that maybe what we should be doing is reading the user interface tweakable there, and obtaining its increment value (which is 0.5 in stock), and on the fly in our code we should be using that value in that line I quoted above. Thus if you do install a mod that changes the increment value in the slider, we would automatically pick up that new value instead of the stock one we've gone and hardcoded there.

[marianoapp]

It's worth noting that while this issue is analyzed the OP could PWM the thrust limit to achieve the same effect.

[dcrockwell]

PWM the thrust limit

Could you elaborate?

[dcrockwell]

@Dunbaratu You're right. This is still an issue even if tweakableEverything implements a feature.

Thus if you do install a mod that changes the increment value in the slider, we would automatically pick up that new value instead of the stock one we've gone and hardcoded there.

Sounds like a good solution.

Alternately, could kOS provide a way to set the increment?

SET ENGINE1:THRUSTINCREMENT TO 0.01.

[marianoapp]

PWM the thrust limit

Could you elaborate?

https://en.wikipedia.org/wiki/Pulse-width_modulation

In this case you could rapidly alternate between the minimum value (0.5) and zero, achieving an effective thrust limit that will depend on how much time you spend on each value. For example, switching between 0.5 and 0 every tick will have the same effect as setting the thrust limit to 0.25.

The problem with this approach, beside being more complicated, is that you are exchanging time resolution for thrust resolution. This means that you can't change the target thrust limit every tick because you need several ticks for the PWM averaging to work.

(You could also use an additional smaller engine to provide the required thrust resolution, but that's beside the point).

[pellinor0]

The steps on the stock sliders are so small that they barely sit in different pixels (at least on my screen). I don't see how that could be a deliberate restriction mechanic.

I ended up with a similar solution for the sliders of TweakScale. The problem is that a continuous slider produces odd numbers that are hard to memorize and reproduce, and just look ugly. So i sacrificed a bit if freedom for better usability.

So my interpretation is that this is clearly an interface limitation and should not be imported into KOS. Just like you don't round the throttle to steps that correspond to a pixel on the screen.

[dcrockwell]

@pellinor0 The interface that shows the thrust in the right click menu could be disabled for all I care if I could set the engine throttle accuracy to 0.001. I need the accuracy programmatically, and have no use for the right click UI when scripting kOS. Without accuracy of that degree, true VTOL in KSP with kOS is impossible without cheating by using SAS.

[Dunbaratu]

I agree that it should follow the way throttle works and just ditch the increment limit altogether. I'll have a look after Christmas when I'm back home