Starstrider42

I'm referring to the files in GameData/UniversalStorage2/Vandist, which first appear in release 4.0.0.8 (and are also present in 4.0.1). As you say, they don't seem to have been merged from anywhere; they're added directly in commit 11ada53, "Updated version & changelog".

Can I ask what's the story behind the "Vandist" patches added in the final commit for version 4.0.0.8? There's no documentation of this change anywhere (neither the release notes nor this forum thread), so I ended up learning that all the US2 tanks had been nerfed the hard way. I won't deny that the original parts were OP, but can we please have some warning of changes like this? I use US2 parts extensively, and it's a bit frustrating to have my spacecraft specs changing out from under me.

The dropbox file is identical to the one in the install -- both have the bad reference on line 601. Since that particular block hasn't changed recently, I'm guessing the problem's a combination of this diff and the addition of ignition failures to more engine types. The most straightforward solution is to patch in &ignitionDynPresFailMultiplier = 1 in the defaults block, and modify the type-specific defaults to overwrite it; that should give the fewest surprises in the future. That said, I haven't tried testing the change myself, so I don't promise it will work, or unblock testing of other features.

Correct, this is from Generic_Engines. I do not have a Generic_Parts. I installed from CKAN, along with TestFlight 2.3.0.0, Module Manager 4.2.2, and Contract Configurator 2.2.2.0.

I finally got a chance to try 0.4.0 and... there are a few ModuleManager errors. [ERR 11:17:42.667] name specifier detected on insert node (not a patch): Starcatcher's Mods/TestFlight-Stock/BDB/PART[bluedog_NERVA_XE]:HAS[!MODULE[TestFlightInterop]]:BEFORE[zTestFlight] [ERR 11:17:42.667] :HAS detected on insert node (not a patch): Starcatcher's Mods/TestFlight-Stock/BDB/PART[bluedog_NERVA_XE]:HAS[!MODULE[TestFlightInterop]]:BEFORE[zTestFlight] [ERR 11:17:42.667] pass specifier detected on insert node (not a patch): Starcatcher's Mods/TestFlight-Stock/BDB/PART[bluedog_NERVA_XE]:HAS[!MODULE[TestFlightInterop]]:BEFORE[zTestFlight] [ERR 11:17:42.667] name specifier detected on insert node (not a patch): Starcatcher's Mods/TestFlight-Stock/BDB/PART[bluedog_smallNuclearEngine]:HAS[!MODULE[TestFlightInterop]]:BEFORE[zTestFlight] [ERR 11:17:42.667] :HAS detected on insert node (not a patch): Starcatcher's Mods/TestFlight-Stock/BDB/PART[bluedog_smallNuclearEngine]:HAS[!MODULE[TestFlightInterop]]:BEFORE[zTestFlight] [ERR 11:17:42.667] pass specifier detected on insert node (not a patch): Starcatcher's Mods/TestFlight-Stock/BDB/PART[bluedog_smallNuclearEngine]:HAS[!MODULE[TestFlightInterop]]:BEFORE[zTestFlight] [LOG 11:17:42.671] Deleting root node in file Starcatcher's Mods/TestFlight-Stock/Squad node: @PART[omsEngine]:HAS[!MODULE[TestFlightInterop]]:BEFORE[zTestFlight]:NEEDS[NearFutureSpacecraft] as it can't satisfy its NEEDS [WRN 11:17:43.375] Cannot find key ignitionDynPresFailMultiplier in TESTFLIGHT [ERR 11:17:43.375] Error - Cannot parse variable search when editing key key = #$/TESTFLIGHT,0/ignitionDynPresFailMultiplier$ (repeated 40 times) This is with a completely clean install of TF-Stock, no other mods except the mandatory ones. I'm guessing something changed between testing and upload.

Sorry to butt in, but it sounds like @Chris Bolland is mixing up rated burn time and MTTF. 40 minutes sounds reasonable (or, if anything, a bit low) for MTTF. Rated burn time is fixed in TF because it reflects the purpose of the engine -- a first-stage engine that burns out in a couple of minutes will only be designed, or tested, to run that long, plus margin of error. FWIW, in the original config pack I set the RBT for rocket engines like the LV-T30 to allow safe launches with the stock rockets plus a sizeable margin, since a lot of the fun of stock and stockalike KSP is trying weird designs. Though I'll admit 100 seconds wouldn't let you clear the atmosphere even in stock-sized KSP. That said, a patch like the following might help with 6.4× compatibility in general: @PART:HAS[@TESTFLIGHT,@MODULE[ModuleEngines*]]:BEFORE[zTestFlight]:NEEDS[TestFlight,???] { @TESTFLIGHT,* { @ratedBurnTime *= 2.5 # Approx. square root of 6.4, gives a round number for most inputs } } (substituting the correct code for 6.4× scale in the NEEDS block; I don't know what it is).

Understood, thanks for the update. I must have overlooked the RO nuclear engines.

I believe RSS ships with a Custom Asteroids config that works automatically if this mod is installed.

But isn't that sort of thing already represented by the initial failure rate spike (which you seem to have kept)? My understanding is that TestFlight intended the ignition failure mechanic to specifically represent igniters, and that that assumption is incorporated into other mod rules (e.g., sensitivity to dynamic pressure). Please do reconsider; I think having ignition failures apply to some engines, but not others, adds a lot of meaningful choice to spacecraft design.

First of all, many thanks for taking over this! It was a welcome surprise for my return to KSP, especially since I didn't have time to sit down and learn the differences between TF1 and TF2. However, I'm not sure I understand all your design decisions. In particular, can I ask why you added ignition failures to all the monopropellant, nuclear, and electric engines? It's a bit confusing, given that these engine types don't have igniters (and IRL one of the few advantages monopropellant rockets have over bipropellant is that they will burn so long as fuel is flowing). The change also has some significant gameplay consequences, since it's harder to perform precision maneuvers with an engine that has a flat chance of failure every time it's bumped up to nonzero throttle.

Sorry, I have documentation of the config options (which badly needs some reorganization), but nothing step-by-step. As for your specific question, it would be difficult. The current system doesn't support multi-part asteroids (it's been a feature request for a while now, but I have no idea where to even begin). If you wanted to create a specific asteroid swarm, you could create a group for it with very narrow tolerances on all six orbital elements (and no variation at all in semimajor axis, to keep them from drifting out of formation). If you want to create dense swarms with the orbit of each individual swarm being randomized, however, I don't see a way to do that.

Trojans and main belt asteroids are in the Basic Asteroids pack. It sounds like you downloaded Custom Asteroids as a zip file; Basic Asteroids is in the Standard Setup folder of the zip. Installation works the same way as for the OPM packs. As for too many comets, I'm not sure what to say. You should only see 4-5 comets a year, and only roughly 1 at a time if you leave them untracked. Can you send me the log as described in this post (I'm fine with you messaging a link instead of putting it here in the thread)? Hopefully it will reveal what's going on.

I'm not sure I follow. There is indeed no "download" button. The links in the OP go directly to the files; they can then be saved to disk using your browser's "Save Page As" (or similarly named) command. If instead you navigated to the Custom-Asteroids-Extras releases, the links under "Assets" should save to disk instead of opening the files in your browser. Please let me know if either option works for you.

Sorry for the slow reply. There are several asteroid packs for OPM, all of which are available from either GitHub (see the original post for links) or CKAN (search for mods with "Custom Asteroids" in their name). For the GitHub downloads, you get a single .cfg (text) file that needs to go somewhere within your <KSP install>/GameData directory. The traditional location is GameData/CustomAsteroids/config, but you can also create your own folder and put them there. For the CKAN downloads, CKAN will install them in GameData/CustomAsteroids/config. KSP will automatically load the files next time it starts (assuming you have Custom Asteroids already installed). As for which asteroid packs work with OPM: Stockalike and Basic Asteroids are included with the non-CKAN installs of Custom Asteroids (on CKAN, they can be requested separately), and work just fine with OPM. These cover the solar system at Jool's orbit and inward. Note that the Trans-Jool pack included with Custom Asteroids does not play well with OPM, and I recommend removing that file from GameData/CustomAsteroids/config if you have it. Trans-Neidon provides OPM-ified versions of the centaurs, the Kuiper Belt, and the scattered disk. It also tweaks comets (from Stockalike) a bit to better fit the expanded solar system. OPM-Reconfig is a Custom Asteroids remake of the Kopernicus asteroid config shipped with OPM, which adds moonlets around all four giant planets. Whether this is useful for you depends on your Kopernicus settings (search this page for "UseKopernicusAsteroidSystem"); if you're already getting these objects from Kopernicus, then I don't recommend getting more from Custom Asteroids. I hope that helps. If not, please let me know; I promise to respond faster next time.

Assuming you have ModuleManager installed (if you use any mods, you probably do), you can create a script like the following and put it somewhere in your KSP/GameData/ directory (e.g., GameData/Matteoksp/magicboulder.cfg): @PART[PotatoRoid]:FINAL { @MODULE[ModuleAsteroid] { %secondaryRate = 0.05 } } @PART[PotatoComet]:FINAL { @MODULE[ModuleComet] { %secondaryRate = 0.05 } } This will change both asteroids and comets to whatever probability you give.