[WIP][v0.9.3] Less Real Test Flight: TestFlight for stock and stockalike parts (KSP 1.12.x)

Pehvbot · June 28, 2022

3 hours ago, Strych74 said:

So I don't know if this is an issue with TF, or LRTF, or both, or just me being a plain old imbecile. I can see the TF button in the KSC screen, and also the in-flight button and window. What I CAN'T see is anything while inside the VAB - no button, no R&D window, nothing TF related in the right-click part-window. I'm running TF v2.2.0.1 and LRTF v0.7.1.

As an aside, the mod itself does appear to be working properly - I launch a rocket with a new engine and I can see the UI for TF, the data accrual, failure reporting etc. I've also been able to confirm that the failures are persistent. Returning the vehicle to the VAB (using KCT here) and then returning it to the launchpad shows the parts are still malfunctioning. What I'm not clear on is whether there is a clean way of fixing these failures while in the VAB - can I see a list of the parts that are malfunctioning, can I repair/replace them from within a UI, or do I have to remember the malfunctioning part/s and manually replace them one by one? Apologies for the questions, I just haven't been able to find any screenshots / videos of people using the mod to give me an understanding of what to expect.

There isn't much to see in the VAB. If you center click on a placed part you should see things like the number of data units ('du') collected so far for that part and the failure chance but that's about it. This is how TF is designed. The latest versions of TF have removed the (apparently problematic) R&D options.

KCT will remember your parts so yeah, there's currently no method for 'clearing' the error simply by recovering it. What I do is reload the entire craft from the saved vessel. Interestingly, by doing this it tends to add some time back to the build process which is a pretty good approximation for the time it takes to fix the part. Ideally there should be an option to reset parts in the VAB but this may be a bit beyond my skill level. Maybe something for a future update?

Pehvbot · June 28, 2022

On 6/26/2022 at 7:20 AM, Pehvbot said:

Good catch! Yeah, that was a typo and your fix is correct. I'll roll it into the next update.

Let me know how it goes. Any feedback is super useful. This is still deep in the 'work in progress' phase.

Looking deeper into it, it looks like the original MM script is correct so there may be an issue somewhere else in the process. I'm not getting any error messages and the Bluedog SRBs I looked at seem to work. Do you know which part(s) were not working correctly?

I'm not sure if this is related, but one rare problem that's come up is the failure curve isn't calculated properly. LRTF creates a random failure curve for each part in each new save game and once in a while it fails to make a valid failure curve. The TestFlight window gives a 'NaN' (not a number) error for that part.

hermano · June 28, 2022

Hi Pehvbot, note that I also use Realfuels-Stock:

Spoiler

[...]
[LOG 23:02:38.558] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to
Bluedog_DB/Parts/Agena/bluedog_Agena_AInterstage.cfg/PART[bluedog_Agena_AInterstage]
[WRN 23:02:38.537] Cannot find key baseVolume in MODULE
[ERR 23:02:38.537] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.537] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Agena/bluedog_Agena_StraightInterstage.cfg/PART[bluedog_Agena_StraightInterstage]
[WRN 23:02:38.537] Cannot find key baseVolume in MODULE
[ERR 23:02:38.537] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.541] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Delta/bluedog_Delta_GEM40.cfg/PART[bluedog_Delta_GEM40]
[WRN 23:02:38.541] Cannot find key baseVolume in MODULE
[ERR 23:02:38.541] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[...]
[LOG 23:02:38.558] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to
Bluedog_DB/Parts/Titan/bluedog_1875_NoseSep.cfg/PART[bluedog_1875_NoseSep]
[WRN 23:02:38.559] Cannot find key baseVolume in MODULE
[ERR 23:02:38.559] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.560] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_SRMU_Full.cfg/PART[bluedog_SRMU_Full]
[WRN 23:02:38.560] Cannot find key baseVolume in MODULE
[ERR 23:02:38.560] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.560] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_SRMU_Half.cfg/PART[bluedog_SRMU_Half]
[WRN 23:02:38.560] Cannot find key baseVolume in MODULE
[ERR 23:02:38.560] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.561] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_SRMU_Single.cfg/PART[bluedog_SRMU_Single]
[WRN 23:02:38.561] Cannot find key baseVolume in MODULE
[ERR 23:02:38.561] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.561] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_SRMU_TwoSeg.cfg/PART[bluedog_SRMU_TwoSeg]
[WRN 23:02:38.561] Cannot find key baseVolume in MODULE
[ERR 23:02:38.561] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.561] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_SRMU_XL.cfg/PART[bluedog_SRMU_XL]
[WRN 23:02:38.562] Cannot find key baseVolume in MODULE
[ERR 23:02:38.562] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.562] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_Titan2_S2_VernierMotor.cfg/PART[bluedog_Titan2_S2_VernierMotor]
[WRN 23:02:38.562] Cannot find key baseVolume in MODULE
[ERR 23:02:38.562] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.563] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_UA1202.cfg/PART[bluedog_UA1202]
[WRN 23:02:38.563] Cannot find key baseVolume in MODULE
[ERR 23:02:38.563] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.563] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_UA1203.cfg/PART[bluedog_UA1203]
[WRN 23:02:38.563] Cannot find key baseVolume in MODULE
[ERR 23:02:38.563] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.564] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_UA1204.cfg/PART[bluedog_UA1204]
[WRN 23:02:38.564] Cannot find key baseVolume in MODULE
[ERR 23:02:38.564] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.564] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_UA1205.cfg/PART[bluedog_UA1205]
[WRN 23:02:38.565] Cannot find key baseVolume in MODULE
[ERR 23:02:38.565] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.565] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_UA1206.cfg/PART[bluedog_UA1206]
[WRN 23:02:38.565] Cannot find key baseVolume in MODULE
[ERR 23:02:38.565] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.565] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_UA1207.cfg/PART[bluedog_UA1207]
[WRN 23:02:38.565] Cannot find key baseVolume in MODULE
[ERR 23:02:38.565] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.566] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Titan/bluedog_UA1208.cfg/PART[bluedog_UA1208]
[WRN 23:02:38.566] Cannot find key baseVolume in MODULE
[ERR 23:02:38.566] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$
[LOG 23:02:38.566] Applying update LRTF/profiles/profiles_engine/@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]/baseVolume]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] to Bluedog_DB/Parts/Vanguard/bluedog_Vanguard_S2_RetroRocket.cfg/PART[bluedog_Vanguard_S2_RetroRocket]
[WRN 23:02:38.566] Cannot find key baseVolume in MODULE
[ERR 23:02:38.566] Error - Cannot parse variable search when inserting new key lrtfBurntime = #$MODULE[ModuleB9PartSwitch]/baseVolume$

Strych74 · June 29, 2022

7 hours ago, Pehvbot said:

KCT will remember your parts so yeah, there's currently no method for 'clearing' the error simply by recovering it. What I do is reload the entire craft from the saved vessel. Interestingly, by doing this it tends to add some time back to the build process which is a pretty good approximation for the time it takes to fix the part. Ideally there should be an option to reset parts in the VAB but this may be a bit beyond my skill level. Maybe something for a future update?

I really like the whole concept of TF/LRTF and how that affects my gameplay. I'm not sure what you have on your roadmap with regards to functionality, but Pay To Play is a mod you might want to have a look at. There's a couple of features there that I think would fit nicely with TF. When inside the VAB, right-clicking a part gives the user the option to service/repair a part that has experienced a malfunction/failure (for a fee). It also gives the user the option to replace the part completely. All of this is done via the part context menu, rather than having to manually select/replace parts individually (which is a PITA when they have parts attached to them which then needs to be redone all over again).

In my own little perfect universe, I could imagine entering the VAB with a vessel that's been recovered and seeing the TF UI window with the parts of my ship that are defective, where I can then choose to either repair the part or replace it entirely (with some sort of cost model factored into either of these options). I don't know whether that is something that is LRTF vs TF functionality (although I'm guessing it's probably more the latter ?). Also, not sure how much once can borrow from another mod's concept (personally I prefer the term "inspired by") without running into IP/license issues . I'm just a guy who loves the TF/LRTF concept, and Pay To Play, and ScrapYard, and wishes that some smart people like yourself were able to moosh them all together into a single glorious part testing/reliability/maintenance mod that does everything!

Strych74 · June 29, 2022

Back again.

I've started a new save and am currently doing a bunch of sounding rocket launches using SRB's (USI Sounding Rockets) using a rescaled Kerbin. I'm finding I'm getting a LOT of 2nd stage ignitions due to the dynamic pressure penalty. I like the idea of this, but I am wondering how I can fine tune this.

I came across the following code in the "configure_engines.cfg" file. Would I be correct to say this looks like a hard-coded pressure curve (altitude, %ASL air pressure)?

@PART[*]:HAS[@LRTFCONF[Engine]:HAS[#pressureFailures[?rue]]]:FOR[zTestFlight]
{
	@MODULE[LRTFFailure_IgnitionFail]
	{	
		pressureCurve
		{
			key = 0 1 0 0
			key = 5000 1 0 0
			key = 15000 0.85 -2.25E-05 -2.25E-05
			key = 30000 0.4
			key = 50000 0.15 0 0
			@key,*[0, ] *= #$../../LRTFCONF[Engine]/qMult$
		}
	}
}

I'm wondering how to tackle this, and keen to get your thoughts. My thinking on this is:

Define my own pressure curve, or take a pressure curve from another source (e.g. Realistic Atmospheres)
"Tweak" the failure curve based on engine type, e.g. solids have a lower penalty than ASL liquid engines
Would there be a way to link the ignition failure chance to the DU of the engine as a further modifier? So as an engine increases its testing, it's probability of ignition at a given dynamic pressure also improves?

Pehvbot · June 29, 2022

20 hours ago, hermano said:

Hi Pehvbot, note that I also use Realfuels-Stock:

Got it! It was a bug in my code, but not what I first thought. Your fix pointed me in the right direction:

@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]:HAS[#baseVolume]]:NEEDS[LRTFConfig]:BEFORE[zTestFlight]

The script was supposed to look for the amount of fuel stored by ModuleB9PartSwitch using the baseVolume and using that to calculate expected burn times. The problem was it was only looking for the module itself. Because RealFuels sometimes no longer uses baseVolume, the script was trying to do math on something that doesn't exist.

Pehvbot · June 29, 2022

Spoiler

Yep, the pressure curve is hard coded and the same for all engines. The module looks for dynamic pressure (specifically the Part.dynamicPressurekPa attribute ). It uses this to modify the base ignition failure chance which is based on du. The curve values were lifted directly from StarStrider42's original code and I'm not entirely sure how well they match with real world engines.

I've actually removed the dynamic pressure failure from SRBs in the current dev version. I can't find any documentation on this being an issue and it I don't think it makes much sense in any case. Solids typically ignite form the top of the motor and once lit nothing will put it out. You can still get ignition failures, they just won't get worse based on dynamic pressure.

If you wanted to keep them you can add in the following script somewhere.

@PART[*]:HAS[@MODULE[LRTFFailure_IgnitionFail],#lrtfConfName[Solid]]:AFTER[zTestFlight]
{
	@MODULE[LRTFFailure_IgnitionFail]
	{	
		pressureCurve
		{
			key = 0 1 0 0
			key = 5000 1 0 0
			key = 15000 0.85 -2.25E-05 -2.25E-05
			key = 30000 0.4
			key = 50000 0.15 0 0
		}
	}
}

You can make simple adjustments by tweaking the second values in the keys (0.85, 0.4, 0.15). The higher the values the more reliable the engine. I use this super useful mod to help visualize these curves.

You may want to wait until the next version is published though, I've made a few changes in how it orders things.

Pehvbot · June 29, 2022

18 hours ago, Strych74 said:

I really like the whole concept of TF/LRTF and how that affects my gameplay. I'm not sure what you have on your roadmap with regards to functionality, but Pay To Play is a mod you might want to have a look at. There's a couple of features there that I think would fit nicely with TF. When inside the VAB, right-clicking a part gives the user the option to service/repair a part that has experienced a malfunction/failure (for a fee). It also gives the user the option to replace the part completely. All of this is done via the part context menu, rather than having to manually select/replace parts individually (which is a PITA when they have parts attached to them which then needs to be redone all over again).

In my own little perfect universe, I could imagine entering the VAB with a vessel that's been recovered and seeing the TF UI window with the parts of my ship that are defective, where I can then choose to either repair the part or replace it entirely (with some sort of cost model factored into either of these options). I don't know whether that is something that is LRTF vs TF functionality (although I'm guessing it's probably more the latter ?). Also, not sure how much once can borrow from another mod's concept (personally I prefer the term "inspired by") without running into IP/license issues . I'm just a guy who loves the TF/LRTF concept, and Pay To Play, and ScrapYard, and wishes that some smart people like yourself were able to moosh them all together into a single glorious part testing/reliability/maintenance mod that does everything!

Thanks! I've had a blast (pun maybe intended?) working on it. I'll take a look at Pay To Play when I get a chance.

Adding in a built in repair/replace feature is likely outside of my ability and/or time. TF does all the user interface work and doesn't have VAB tools. I do think it might be possible to create a simple button to open the PAWs (part action window) for all the failed parts. This would make it much easier to locate and fix any failed parts with something like PtP.

hermano · July 8, 2022

Hi @Pehvbot,

something seems off with a decoupler with LRTF.

I added this small radial decoupler:

Spoiler

+PART[radialDecoupler]:FINAL
{
    @name = radialDecoupler3
	@rescaleFactor = 0.4
	@cost = 100
	@entryCost = 2100
	@title = Small Hydraulic Detachment Manifold
	@description = After discovering the words "Small" and "Manifold", O.M.B. Engineers decided it would be best to use it in the name of at least ONE product.
	@mass = 0.01
	@TechRequired = start
	@MODULE[ModuleAnchoredDecoupler]
	{
		name = ModuleAnchoredDecoupler
		@ejectionForce = 55
	}
	
	@DRAG_CUBE
	{
		@cube = Default, 0.01754,0.7892,0.4314, 0.01754,0.7895,0.4314, 0.08403,1,0.1824, 0.08403,0.9759,0.1824, 0.01721,0.7962,0.4141, 0.01721,0.7956,0.4141, 0,0.02694,-9.636E-09, 0.35,0.1,0.35
	}
}

With 10k flight data it still has a 15% chance to fail deploying. I think this was supposed to be 1%. Is there a bug or something wrong with the part?

Pehvbot · July 11, 2022

On 7/8/2022 at 2:38 PM, hermano said:
Hi @Pehvbot,

something seems off with a decoupler with LRTF.

I added this small radial decoupler:
Reveal hidden contents
+PART[radialDecoupler]:FINAL
{
    @name = radialDecoupler3
	@rescaleFactor = 0.4
	@cost = 100
	@entryCost = 2100
	@title = Small Hydraulic Detachment Manifold
	@description = After discovering the words "Small" and "Manifold", O.M.B. Engineers decided it would be best to use it in the name of at least ONE product.
	@mass = 0.01
	@TechRequired = start
	@MODULE[ModuleAnchoredDecoupler]
	{
		name = ModuleAnchoredDecoupler
		@ejectionForce = 55
	}
	
	@DRAG_CUBE
	{
		@cube = Default, 0.01754,0.7892,0.4314, 0.01754,0.7895,0.4314, 0.08403,1,0.1824, 0.08403,0.9759,0.1824, 0.01721,0.7962,0.4141, 0.01721,0.7956,0.4141, 0,0.02694,-9.636E-09, 0.35,0.1,0.35
	}
}
With 10k flight data it still has a 15% chance to fail deploying. I think this was supposed to be 1%. Is there a bug or something wrong with the part?

My first guess is that this may be an ordering issue with the part you created. Since it's being created FINAL, after all the LRTF configs, it may be trying to use radialDecoupler for all the configs. It's probably safe to create the part much earlier. See if removing FINAL fixes things.

If that's not it, send me the ModuleManager.ConfigCache file and a saved game with an active vessel with this part. I'll see if I can figure out what's going on.

hermano · July 11, 2022

Removing the final tag fixed the issue, thank you!

Edited July 11, 2022 by hermano

Strych74 · July 18, 2022

I've been experiencing some exception errors which "look" like they're related to LRTF - although I can't be sure if there may be a mod conflict.

Quote

From what I can tell:

The error only triggers when there's a parachute attached to the vessel
Stock parts as well as the parachutes in USI Sounding Rockets trigger the error
Parts from Bluedog Design Bureau, KNES, RN US Rockets, and RealChutes do NOT trigger the error

I've tested them with FAR installed and then removing FAR, however the errors still generate.

**EDIT** : I've checked the ModuleManager.configcache, all of the parts have the LTRFFailure_ParachuteDeploy module, and as far as I can tell they all look correct (albeit the configuration= key is different for each part).

Please let me know if there's anything I can provide which might help lock this down.

Edited July 18, 2022 by Strych74
clarification of what I've tested

Pehvbot · July 18, 2022

13 hours ago, Strych74 said:

I've been experiencing some exception errors which "look" like they're related to LRTF - although I can't be sure if there may be a mod conflict.

From what I can tell:

The error only triggers when there's a parachute attached to the vessel

Stock parts as well as the parachutes in USI Sounding Rockets trigger the error

Parts from Bluedog Design Bureau, KNES, RN US Rockets, and RealChutes do NOT trigger the error

I've tested them with FAR installed and then removing FAR, however the errors still generate.

**EDIT** : I've checked the ModuleManager.configcache, all of the parts have the LTRFFailure_ParachuteDeploy module, and as far as I can tell they all look correct (albeit the configuration= key is different for each part).

Please let me know if there's anything I can provide which might help lock this down.

Thanks for the report! The error comes from the mod looking for the stock ModuleParachute MODULE but not finding it. My first guess is that there's a custom parachute mod such as RealChute installed. If this mod is being configured after LRTF then LRTF sees the stock MODULE, loads all the failure info, but the stock MODULE gets replaced by the new mod later. LRTF doesn't know it's been replaced so it just tries to run, can't find ModuleParachute and poops its pants. If you can send me a link to your ModuleManager.ConfigCache file I can check to see if that is what's happening.

If that is the issue then the immediate solution will be to disable parachutes in the Settings/TestFlight window. You won't get parachute failures but your game should work otherwise. Moving forward I'll add in some error checking so if something like this happens it will fail a bit more gracefully. In a perfect world I should add failure modules for things like RealChute but I just may not have the time.

Even if this isn't whats going on, I do need to add more error checking for issues like this.

Strych74 · July 19, 2022

7 hours ago, Pehvbot said:

Thanks for the report! The error comes from the mod looking for the stock ModuleParachute MODULE but not finding it. My first guess is that there's a custom parachute mod such as RealChute installed. If this mod is being configured after LRTF then LRTF sees the stock MODULE, loads all the failure info, but the stock MODULE gets replaced by the new mod later. LRTF doesn't know it's been replaced so it just tries to run, can't find ModuleParachute and poops its pants. If you can send me a link to your ModuleManager.ConfigCache file I can check to see if that is what's happening.

If that is the issue then the immediate solution will be to disable parachutes in the Settings/TestFlight window. You won't get parachute failures but your game should work otherwise. Moving forward I'll add in some error checking so if something like this happens it will fail a bit more gracefully. In a perfect world I should add failure modules for things like RealChute but I just may not have the time.

Even if this isn't whats going on, I do need to add more error checking for issues like this.

From the checking around I did, there's definitely something funky about FAR.

I've checked the logs, turns out FAR patches all of the parachute parts to replace ModuleParachute with it's own version RealChuteFAR. This is happening before LRTF occurs (I think). I added in my own patch file to add the lrtfConfName flag at the same time LRTF is patching all of the other parts, and I can see the parts are then correctly inheriting the LRTF test modules further down the config. I can't rule out the possibility that FAR does some funky stuff at the end of the process, however - I've written another config patch to run at :FINAL that should add two additional fields to the RealChuteFAR module, but for whatever reason they don't appear. I can't see anything in the cfg files to explain why this might be happening, so I'm guessing it might be in the .dll's somewhere, but that's well beyond my limited programming expertise!

It's worth noting that FAR has some logic in it's early patching to allow for RealChutes. Basically, if someone has both FAR and RealChute, then RealChute will run first and patch the parts it knows about, converting ModuleParachute to RealChuteModule. FAR then patches anything left over and converts ModuleParachute to the RealChuteFAR. Either way, if someone has one or the other (or both) then most (if not all) of the stock ModuleParachute MODULES will have been renamed/replaced.

Here's a link to the ModuleManager file and log, I've also included the patch file from FAR as well as my own LRTF patch intended to make FAR compatible with LRTF. Enjoy

https://www.dropbox.com/scl/fo/9rqxoxjplmmpwlmipxc6g/h?dl=0&rlkey=4ugkph0d6fdhljkoeq5hkufht

Pehvbot · July 19, 2022

13 hours ago, Strych74 said:

From the checking around I did, there's definitely something funky about FAR.

I've checked the logs, turns out FAR patches all of the parachute parts to replace ModuleParachute with it's own version RealChuteFAR. This is happening before LRTF occurs (I think). I added in my own patch file to add the lrtfConfName flag at the same time LRTF is patching all of the other parts, and I can see the parts are then correctly inheriting the LRTF test modules further down the config. I can't rule out the possibility that FAR does some funky stuff at the end of the process, however - I've written another config patch to run at :FINAL that should add two additional fields to the RealChuteFAR module, but for whatever reason they don't appear. I can't see anything in the cfg files to explain why this might be happening, so I'm guessing it might be in the .dll's somewhere, but that's well beyond my limited programming expertise!

It's worth noting that FAR has some logic in it's early patching to allow for RealChutes. Basically, if someone has both FAR and RealChute, then RealChute will run first and patch the parts it knows about, converting ModuleParachute to RealChuteModule. FAR then patches anything left over and converts ModuleParachute to the RealChuteFAR. Either way, if someone has one or the other (or both) then most (if not all) of the stock ModuleParachute MODULES will have been renamed/replaced.

Here's a link to the ModuleManager file and log, I've also included the patch file from FAR as well as my own LRTF patch intended to make FAR compatible with LRTF. Enjoy

https://www.dropbox.com/scl/fo/9rqxoxjplmmpwlmipxc6g/h?dl=0&rlkey=4ugkph0d6fdhljkoeq5hkufht

Yep, it's FAR replacing ModuleParachute with RealChuteFAR all right. LRTF configures itself for the stock parachutes but can't find ModuleParachute and can't use RealChuteFAR, so it fails. In this case it fails pretty badly. There's a lesson here about doing more error checking in my code that I'm sure I'll forget for my next project.

I've updated the LRTF dll so it fails a bit more gracefully (the update will be published in the next day or so) and I'll also see if I can change the MM patches to avoid this problem in the first place, but unless/until I add in support for RealChuteFAR modules, LRTF just won't have working parachute failures.

In the mean time this patch will at least clean things up so things will more or less work:

@PART[*]:HAS[@MODULE[RealChuteFAR]]:FINAL
{
	!MODULE[LRTFDataRecorder_Parachutes] {}
	!MODULE[LRTFFailure_ParachuPartial] {}
	!MODULE[LRTFFailure_ParachuteFail] {}
	!MODULE[LRTFFailure_ParachuteDeploy] {}
}

Pehvbot · July 20, 2022

v0.7.2 is available. It has a few adjustments to some parts failures, including wheels and aerodynamics. It also improves error handling when a MODULE is changed by ModuleManager after LRTF configs have been processed. It removes parachute failures when FAR is installed until FAR specific failures can be added.

https://github.com/pehvbot/LRTF/releases/tag/v0.7.2

Strych74 · July 24, 2022

On 7/20/2022 at 2:51 AM, Pehvbot said:

I've updated the LRTF dll so it fails a bit more gracefully (the update will be published in the next day or so) and I'll also see if I can change the MM patches to avoid this problem in the first place, but unless/until I add in support for RealChuteFAR modules, LRTF just won't have working parachute failures.

I'm (definitely!) not a programmer, so please forgive my naivety, but is it possible to "extend" the existing parachute failure code to cover the RealChuteFAR module? Something along the lines of "IF MODULE = [ModuleParachute] OR [RealChuteFAR] THEN DO LRTF_FAILURE_PARACHUTE"? (sorry about the clunky pseudo-code).

Pehvbot · July 26, 2022

On 7/23/2022 at 7:08 PM, Strych74 said:

I'm (definitely!) not a programmer, so please forgive my naivety, but is it possible to "extend" the existing parachute failure code to cover the RealChuteFAR module? Something along the lines of "IF MODULE = [ModuleParachute] OR [RealChuteFAR] THEN DO LRTF_FAILURE_PARACHUTE"? (sorry about the clunky pseudo-code).

Yes, it can be done that way but there are some problems. The issue with supporting third party mods is that your mod needs to 'understand' the third party mod. There are a couple of ways of doing this but the easiest and most efficient is to add the third party dll into the list of dlls your mod is using. However this creates a problem when you load your game if the dll isn't installed, so it's not good for optional mods.

One way to get around this is to create a second dll (called lrtffar.dll for example) containing the needed third party support and only use it if the third party dll exists. Another option is to use something called 'Reflection' which allows you to use a dll you haven't added to your list of dlls at the cost of less efficient and more brittle code. I'm still very much learning as I go forward and I've never used either of these options yet.

I would like to add FAR and RealChute support since it's a good way to learn how to do this stuff. I'm leaning towards the first option above which would mean creating a completely new set of modules that get used instead of the stock modules (so something like LRTF_Failure_RealChuteFAR for example). This is the programmatically 'proper' way to do it. Reflection is normally reserved for when you don't have a choice so it's my backup plan in case I can't figure out the first option. Reflection would use the stock MODULE with code more or less as you described (with a lot of fiddly bits in between).

Oh and I'm definitely not a programmer either, I just play one in Kerbal Space Program! This is all a learning experience for me.

Strych74 · July 27, 2022

<Yawn>... sorry, my eyes glazed over when you mentioned DLLs. MM patches are about the limit of my programming expertise. I'd love to learn how to do more of the complex stuff - I've got plenty of ideas rattling around in my brain, but but have no idea of where to start!

Strych74 · July 29, 2022

On 6/29/2022 at 1:53 AM, Pehvbot said:

I'm not sure if this is related, but one rare problem that's come up is the failure curve isn't calculated properly. LRTF creates a random failure curve for each part in each new save game and once in a while it fails to make a valid failure curve. The TestFlight window gives a 'NaN' (not a number) error for that part.

Hi Pehvbot, I was wondering if you have had any luck with the 'NaN' errors - I came across one for the first time yesterday with a battery part. I'm still accumulating data, and in the MM.ConfigCache file the part has a MTBF value, but I haven't had any failures with the part itself. You mentioned that LRTF fails to create the failure curve - is there a way to reset / regenerate the curve?

Pehvbot · July 30, 2022

14 hours ago, Strych74 said:

Hi Pehvbot, I was wondering if you have had any luck with the 'NaN' errors - I came across one for the first time yesterday with a battery part. I'm still accumulating data, and in the MM.ConfigCache file the part has a MTBF value, but I haven't had any failures with the part itself. You mentioned that LRTF fails to create the failure curve - is there a way to reset / regenerate the curve?

There are a couple of things you can try. The first one is to turn down the randomization by a notch. The setting slider is in the Game Settings->Test Flight. This should do it. You could also change the persistent.sfs 'Seed' value to something else. This will change all the failure curves. It doesn't matter what you change it to. I would just add 1 to the number.

Before you do that though, would it be possible for you lot load a craft with that part on it and do a quicksave? If you send me the quicksave.sfs file I can take a look to see why it might be failing.

Strych74 · July 31, 2022

On 7/30/2022 at 8:16 AM, Pehvbot said:

There are a couple of things you can try. The first one is to turn down the randomization by a notch. The setting slider is in the Game Settings->Test Flight. This should do it. You could also change the persistent.sfs 'Seed' value to something else. This will change all the failure curves. It doesn't matter what you change it to. I would just add 1 to the number.

Before you do that though, would it be possible for you lot load a craft with that part on it and do a quicksave? If you send me the quicksave.sfs file I can take a look to see why it might be failing.

I've popped the quicksave as well as my MM.configCache file in a DropBox folder. The part I'm having a problem with is the battery - if you search the .sfs file for "cid = 4286892222" it will jump you to the specific part on a vessel on the launchpad.

I'll give your suggestion a go and see if that makes a difference. I did have the randomization slider set all the way up so fingers crossed dropping that a notch will help.

hermano · August 2, 2022

Hi @Pehvbot, while my campaign is progressing slowly I'm halfway through the techtree and LRTF is doing really fine. I ran into a conflict with real fuels stock, though. Solid boosters have config like this in rfs:

Spoiler

MODULE
  {
    name = ModuleFuelTanks
    basemass = -1
    volume = 1824
    type = Solid
    // dedicated = false
    TANK
    {
     name = SolidFuel
     amount = full
     maxAmount = 100.000000%
    }

  }

This is not caught by LRTF, so max runtimes where just a few seconds.

I added thess lines in profiles_engine.cfg to fix the issue:

@PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleFuelTanks]:HAS[#volume]]:NEEDS[LRTFConfig]:BEFORE[zTestFlight]
{
	lrtfBurntime = #$MODULE[ModuleFuelTanks]/volume$
}

Things are way less explodey with it for me.

Strych74 · August 3, 2022

On 7/31/2022 at 12:30 PM, Strych74 said:

I'll give your suggestion a go and see if that makes a difference. I did have the randomization slider set all the way up so fingers crossed dropping that a notch will help.

Quick update. I did the seed change and reduced the randomise value to 4, but had another part come up with a NaN time. I've dropped the randomiser to 3 and so far (touch wood) not a problem.

On a separate note, since parts are persisted with KCT, anything failures that happen in flight are kept when the vessel is recovered to the VAB/SPH. Unfortunately there's nothing in the VAB/SPH that allows you to identify the broken part/s. There's two things I'd really like to be able to do in the VAB in relation to failed parts:

As a minimum, identify the failed part, either through a part's PAW or via the TestFlight UI.
The ability to 'fix' and/or replace the failed part. Again, using the PAW would be fine. Borrowing the idea from Pay to Play, perhaps have a cost related to the repair of the part?

Are either of these things something that's possible to add via LRTF, or is that functionality something that belongs to TestFlight core?

Pehvbot · August 3, 2022

1 hour ago, Strych74 said:

Quick update. I did the seed change and reduced the randomise value to 4, but had another part come up with a NaN time. I've dropped the randomiser to 3 and so far (touch wood) not a problem.

On a separate note, since parts are persisted with KCT, anything failures that happen in flight are kept when the vessel is recovered to the VAB/SPH. Unfortunately there's nothing in the VAB/SPH that allows you to identify the broken part/s. There's two things I'd really like to be able to do in the VAB in relation to failed parts:

As a minimum, identify the failed part, either through a part's PAW or via the TestFlight UI.

The ability to 'fix' and/or replace the failed part. Again, using the PAW would be fine. Borrowing the idea from Pay to Play, perhaps have a cost related to the repair of the part?

Are either of these things something that's possible to add via LRTF, or is that functionality something that belongs to TestFlight core?

I think that's a good idea. Implementing it is going to be a bit of a project though. TestFlight simply doesn't have the tools since it wasn't designed with this in mind so it means building it from scratch. It also means I need a better understanding of what KCT does when it recovers a vessel to the VAB. In some ways this is good timing though. I've been working on yet another mod. I'll need to dig into how the VAB/SPH works and how it might interact with KCT in any case. No timeline for this, but it's on my radar.

The save game info was very useful. Yes, there's something wrong with the randomizer. Having a good example will help figure it out.

[WIP][v0.9.3] Less Real Test Flight: TestFlight for stock and stockalike parts (KSP 1.12.x)

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation