Closed OhioBob closed 1 year ago
Gave a quick look at this, and pinging @R-T-B for awareness.
Indeed, the code does clamp the minAirPressureToOpen
field in the editor, but fails to do so in flight, this is an easy fix.
However, note that from a config perspective, minAirPressureToOpen
only define the default value of the field.
The minimum pressure is actually defined by setting the clampMinAirPressure
field.
Also, saw the convo on the Koperncius discord, you also talked about another issue, ie, chutes deploying when they reach the altitude threshold even if they haven't reached the min pressure threshold. This is fixable as well.
All this being said, there is a notable argument against doing any of those fixes. clampMinAirPressure
is a static pressure threshold, making it unreliable and pretty much meaningless. What should condition if a chute can or cannot deploy is the dynamic pressure (ie, air density combined with air speed).
In that context, I would advise against doing those changes. I can see how it can be somewhat exploited, but the reverse is also true, there are cases where chutes should deploy and taking advantage of those (weird) behaviors can help.
In my opinion, what is needed is a mod that revamp the chutes deployment behavior, using dynamic pressure thresholds instead of static, ideally with 3 user-facing configurable values :
I can see such a mod being part of KSPCF, however I think it should be optional (ideally activated from the in-game options), so maybe releasing it as a standalone mod will offer better visibility, and avoid bloating the KSPCF codebase with things that aren't strictly fixes.
For reference, here is an (untested) patch for the two "issues" :
internal class ChuteMinPressure : BasePatch
{
protected override Version VersionMin => new Version(1, 10, 0);
protected override void ApplyPatches(List<PatchInfo> patches)
{
patches.Add(new PatchInfo(
PatchMethodType.Prefix,
AccessTools.Method(typeof(ModuleParachute), nameof(ModuleParachute.OnStart)),
this));
patches.Add(new PatchInfo(
PatchMethodType.Prefix,
AccessTools.Method(typeof(ModuleParachute), nameof(ModuleParachute.ShouldDeploy)),
this));
}
// fix the "Min Pressure" field being allowed to be set lower than the clampMinAirPressure configured value in the flight PAW
private static void ModuleParachute_OnStart_Prefix(ModuleParachute __instance)
{
if (__instance.minAirPressureToOpen < __instance.clampMinAirPressure)
__instance.minAirPressureToOpen = __instance.clampMinAirPressure;
((UI_FloatRange)__instance.Fields[nameof(ModuleParachute.minAirPressureToOpen)].uiControlFlight).minValue = __instance.clampMinAirPressure;
}
// prevent deployment if static pressure is lower than clampMinAirPressure, even if the altitude threshold is reached
private static bool ModuleParachute_ShouldDeploy_Prefix(ModuleParachute __instance, ref bool __result)
{
if (FlightGlobals.getStaticPressure(__instance.part.transform.position, __instance.vessel.mainBody) * ModuleParachute.pressureRecip > __instance.minAirPressureToOpen)
{
__result = false;
return false;
}
return true;
}
}
Frankly, we already have realchutes, which is what I use, and it covers a lot (not all, but a lot) of these bases. It also adds increased complexity but that's kind of ok if you are concerned at this level.
Maybe we should just leave well enough alone then? I'm ok either way. It's certainly trivial to treat this from a static air pressure perspective but as you point out, that's fairly flawed as well.
I agree that deploying parachutes based on dynamic pressure rather than static pressure makes more sense. I assume that this is what the "deploy when safe" option is doing. The minimum static pressure must be reached for deployment, but it must also be safe to do so. Surely the later is based on dynamic pressure. That is, the vessel must slow to a speed where the dynamic pressure isn't so great that it will rip the parachute off.
Sigma created TweakChutes at my request because I wanted to force a particular behavior to create different game play scenarios. Yes, I thought the new behavior made more sense and was a bit more realistic, but realism wasn't really the ultimate goal. The goal was to create more varied situations within the game to makes things more interesting for players.
For example, Duna in JNSQ has a sea level pressure of 0.04 atm. With TweakChutes installed, this means that main parachutes will never open because we never reach the minimum pressure for their deployment. This is what I wanted because it makes landing on Duna more Mars-like. Drogue chutes can be used to slow down to a point, but propulsion is likely needed over the last short distance before touchdown. Without TweakChutes, main parachute open at 1000 m (or whatever the slider is set to) above the terrain, ruining the outcome I am trying to achieve.
So it's not really about producing a realistic system, it's about producing a system that allows players to experience things that they can't when using the stock system.
If you or R-T-B decide not to proceed with this, then that's your choice and I accept it. I just thought it important that you know my reasons for requesting it.
Parachute ripping is code I wrote for KSP (and helped Chris reimplement in RealChute, IIRC). It rips based on temperature and dynamic pressure with a correction factor for compressible flow IIRC. In particular, it's more temperature-focused than a straight dynamic pressure implementation. Deploy when safe just prevents chute deployment until that rip check can no longer possibly (it's slightly random) return true.
I agree that deploying parachutes based on dynamic pressure rather than static pressure makes more sense. I assume that this is what the "deploy when safe" option is doing. The minimum static pressure must be reached for deployment, but it must also be safe to do so. Surely the later is based on dynamic pressure. That is, the vessel must slow to a speed where the dynamic pressure isn't so great that it will rip the parachute off.
Sigma created TweakChutes at my request because I wanted to force a particular behavior to create different game play scenarios. Yes, I thought the new behavior made more sense and was a bit more realistic, but realism wasn't really the ultimate goal. The goal was to create more varied situations within the game to makes things more interesting for players.
For example, Duna in JNSQ has a sea level pressure of 0.04 atm. With TweakChutes installed, this means that main parachutes will never open because we never reach the minimum pressure for their deployment. This is what I wanted because it makes landing on Duna more Mars-like. Drogue chutes can be used to slow down to a point, but propulsion is likely needed over the last short distance before touchdown. Without TweakChutes, main parachute open at 1000 m (or whatever the slider is set to) above the terrain, ruining the outcome I am trying to achieve.
So it's not really about producing a realistic system, it's about producing a system that allows players to experience things that they can't when using the stock system.
If you or R-T-B decide not to proceed with this, then that's your choice and I accept it. I just thought it important that you know my reasons for requesting it.
Upon further thinking on this, I think it'd be ok to implement in Kopernicus (unless got wants to do it for some reason of course) but probably with a config option to restore the old behavior, if desired.
I see no issues with that approach. What convinced me primarily is that the "deploy when safe" setting more or less covers my initial concerns about the system being totally and completely flawed.
Well, I'm a bit reluctant to make this change in KSPCF as I feel people might be familiar to the current behavior and this has very little effect anyway due to being based on the static pressure instead of dynamic.
I understand the goal in the context of JNSQ, I would indeed suggest to integrate the harmony patches to Kopernicus (I would advise against doing what TweakChute is doing, this is spamming additional partmodules and update handlers for no good reason), and to condition the enabling of those patches by a per planet pack config setting, not by a a user defined setting.
Roger that. I would do it as a harmony patch and not a straight copy/paste of tweakchutes. I'll probably experiment with it some on the next RC.
The way I envision it is as an option a pack can turn on via MM, but not a "user-facing" GUI option, for the same reasons got is probably thinking (user confusion etc).
Nice. Let me know if you have any question. Closing this issue.
I have a request for a bug fix related to parachutes. Each parachute has a minAirPressureToOpen setting in its config. As the name implies, this is the minimum ambient air pressure required for a parachute to semi-deploy. It is generally set to 0.04 atm for main parachutes and 0.02 atm for drogue parachutes.
In game, the player can right-click on a parachute and set the minimum semi-deployment pressure via a slider. While in the editor (VAB or SPH), the slider will not go below the minAirPressureToOpen as defined in the part’s config. This is what we should expect. However, once a vehicle is sent to the launch pad, or while in flight, the slider we get when right-clicking on a parachute allows the pressure to be set all the way down to 0.01 atm. This shouldn’t be. At no time should we be able to set the pressure to less than the minAirPressureToOpen. I request this be corrected as it is clearly unintended behavior.
I have spoken with R-T-B about this issue and he is willing to add a fix for it in Kopernicus, but he would like to give you first opportunity should you think KSPCF is a better place to handle it. Either way, we need to keep R-T-B informed so he knows how to proceed. Thank you.