Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up generic engine configs #1

Closed

Conversation

Starstrider42
Copy link

This PR removes some references in the generic config that don't correspond to real fields in the TestFlight 2 PartModules. I haven't investigated whether any of the remaining fields have changed meaning between TestFlight 1 and 2, and I did only a basic check to make sure a demo flight behaved the same with both configs.

I haven't done anything about the transition from cycle to continuousCycle and ratedBurnTime to ratedContinuousBurnTime, as @Starcatcher2009 mentioned he already had a better fix for that.

Since all blocks are now TESTFLIGHT, the references were
breaking ModuleManager.
Idle decay was a TestFlight 1 feature that does not have an equivalent in
TestFlight 2. It has been superseded by the distinction between continuous and
cumulative burn time.
The engineID in this module appears to always have been spurious, and current
RealismOverhaul configs don't have it.
This is a copy-and-paste error inherited from the TestFlight 1 config.
@Starcatcher2009
Copy link
Owner

@Starstrider42 Seems like you posted an issue in 2017 saying that you can’t seem to get gimbal failures to work. Is the issue still there, because I suspect that you somehow can’t assign TestFlight modules directly to a part likePART[*]:HAS[@TESTFLIGHT,@MODULE[xxx]…. An example of this is the RO TestFlight Generic file, which first uses PART:HAS[@MODULE[ModuleEngineConfigs]:HAS[#EngineType[SolidBooster]] { @TESTFLIGHT { %isSolid = True } } and finally after that configured TF failure modules via @part:HAS[@TestFlight[~isSolid[?rue]]] {…}

@Starcatcher2009
Copy link
Owner

@Starstrider42 Also please tell me how to use TestFlightReliability_TestFail

@Starstrider42
Copy link
Author

I assume you mean KSP-RO/TestFlight#164? Yes, TestFlightFailure_LockGimbal still has no effect when triggered; the code for it hasn't been touched in years. Perhaps we should just use TestFlightFailure_GimbalCenter instead.

However, I don't understand the rest of your post. As far as I know, PartModules must always be attached to a Part (were you thinking of attaching them to ModuleGimbal?), and while RO doesn't use gimbal failures, it still assigns other failures directly to parts (most visible here). I don't see any reason not to replace the current config with a hasGimbal flag, but I also don't see any benefit.

I just tried out TestFlightReliability_TestFail, and it seems to be a drop-in replacement for TestFlightReliability (example here, though a bit old). I think the only difference is the button labeled "Force Failure" (unlocalized) in the part's right-click menu; clicking it causes instant failure even if the engine (or other part) is off.

@Starcatcher2009
Copy link
Owner

Starcatcher2009 commented Sep 6, 2022

@Starstrider42 Also could you please fix this file out for me? I'm trying to figure out a new approach to the TestFlight Generic Settings but seems like it does not work for some reason.
test.zip
I was desperate to think of a solution so I might be speaking gibberish hypothesises sometimes

@Starstrider42
Copy link
Author

Closing as out of date; most of these changes have been separately incorporated into master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants