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.

I generally support this change. Does the "no distributions in CRP" policy apply only to planetary resources, or will the asteroid resource config also be removed? Custom Asteroids is currently "stompy" with that one, and this seems like a good opportunity to clean it up. On the other hand, because of the way PartModules are handled during save game loading, ModuleAsteroidResource and ModuleCometResource are nowhere near as conflict-friendly as resource nodes, so a centralized config may be the lesser evil.

Not at all. Custom Asteroids offers more features than Kopernicus's asteroid system (the latter tries to be fairly stockalike), so it's quite possible to use Kopernicus for planets but Custom Asteroids for asteroids. I play that way myself (with OPM). Kopernicus now has a flag that lets you use Custom Asteroids exclusively; there was a discussion on this thread about it in January/February. Actually, I should mention the flag in the disclaimer, so thank you for bringing it to my attention.

In the VAB, once you've placed an engine, you can (IIRC) get a brief summary by mousing over it, and more detail by middle-clicking.

It sounds like you're trying to run Custom Asteroids 1.9, which (like anything comet-related) is only compatible with KSP 1.10 and later. If you install Custom Asteroids 1.8 (links available in original post) you should not have any problems.

Custom Asteroids itself should work with any Kopernicus-based solar system, but I don't know of any asteroid packs for Beyond Home . If a planet mod doesn't include Custom Asteroids support, you'll have to write your own (see the discussion with @Wolves_Hero last page).

Sorry, I couldn't understand that. If you're asking how to control the sizes of asteroids, you want something like, for example: ASTEROIDGROUP { // Other properties go here sizes { key = 1.5 C key = 3 D key = 2 E } } to give a 3:6:4 ratio of C, D, and E asteroids, but no A or B. If you're saying that size A asteroids look huge when they shouldn't, that sounds like a bug. If so, can you provide more information, following the "How to get support" guidelines? The log file and a list of other mods installed are the most important parts.

Not quite. Comets are provided by Stockalike.cfg, and from your description above it sounds like you want that instead of Basic Asteroids.cfg (Basic Asteroids creates an asteroid belt between Duna and Jool, something stock does not do). If you substitute Stockalike in your description above then yes, that should be the behavior you get.

That's a complicated question because there's multiple options on either side, so bear with me. Though you're at least in little danger of getting "stray" objects no matter what you do. I should start by pointing out that there are actually two stock asteroid systems: the basic one that produces Kerbin intercept asteroids, Drestroids, and most comets, and the one associated with the Sentinel telescope. Depending on how you set the new Kopernicus switch: if UseKopernicusAsteroidSystem = true, you will have neither the basic nor the Sentinel spawner. If you also have Custom Asteroids installed, both the Kopernicus and CA spawners would run. Whether they overlap would depend on which asteroids each is configured with (see below). if UseKopernicusAsteroidSystem = false, you will also have neither stock spawner. If you have Custom Asteroids installed, it will work alone. if UseKopernicusAsteroidSystem = stock but Custom Asteroids is installed, you will not have the basic spawner (which CA turns off), but will still have the Sentinel spawner. Sentinel will behave exactly like it does in stock, without using Custom Asteroids configs. None of these options let you use the basic spawner for some asteroids and Custom Asteroids for others, but both Kopernicus and Custom Asteroids can emulate stock behavior with their own systems. In the case of Custom Asteroids + OPM, there are five asteroid packs involved: Stockalike.cfg ("stockalike config" in CKAN) -- this one produces Kerbin intercept asteroids, Drestroids, and comets. To be more (but not perfectly) stock-like, it avoids some Custom Asteroids features, such as composition classes. It's installed by default if you download Custom Asteroids as a zip, and automatically recommended if you install from CKAN. Basic Asteroids.cfg ("inner stock system") -- this one produces asteroids at Jool's orbit and inward, including Jool Trojans and an asteroid belt. It's included in a separate directory in the zip file, but it sounds like you don't want it. Trans-Jool.cfg ("outer stock system") -- this one produces a Kuiper belt just outside Jool's orbit. It is not compatible with OPM, and CKAN won't let you install them together. If you're downloading Custom Asteroids directly, it's in the same place as Basic Asteroids. OPM-Reconfig.cfg ("alternative OPM config") -- this one adds moonlets to Jool through Neidon, emulating OPM's Kopernicus config. It turns off the Kopernicus configs it duplicates, so there should be no conflict. This one's not included in the zip file, but you can download it from a link in the OP, or through CKAN. Trans-Neidon.cfg ("Kuiper belt analog for OPM") -- this one produces Kentaurs and a Kuiper belt outside Neidon's orbit, and also rescales the Stockalike.cfg comet orbits to fit the larger solar system. It's available from the same places as OPM-Reconfig. So the main danger of overlap is between my Stockalike.cfg and the corresponding Kopernicus asteroids, if you've set UseKopernicusAsteroidSystem = true. You can avoid it either by setting UseKopernicusAsteroidSystem = false, or by not installing Stockalike.cfg. In the latter case, I assume OPM will rescale the stock comets itself once it officially supports KSP 1.10, but I don't think it does yet. Sorry if that's a bit long-winded, but hopefully you see a combination that does what you want.

Honestly I have mixed feelings about Kopernicus turning comet control over to Custom Asteroids entirely; I said a few words about why on the Kopernicus Unified branch. I'm all in favor of the asteroid generator flag you propose, though, since previously avoiding conflicts between the two mods has involved some awkward MM deletions, and having a sanctioned solution would be much better. Custom Asteroids defines its asteroids/comets in text files in the KSP directory. The default files in GameData/CustomAsteroids/config are all designed for the stock system, so for a total conversion mod like Beyond Home I'd expect them to produce nothing but error messages. You'll probably want to delete them (or move them somewhere outside the KSP directory if you want to keep them as examples). I've provided some instructions for what the asteroid config files should look like, so I suggest starting there. I realize the instructions are a bit poorly organized; rewriting them to be clearer and easier to navigate is getting close to the top of my to-do list. I hope they help in the meantime.

Since @Black-Two- was kind enough to mention me I suppose I should chime in, though I am biased (in multiple directions ). Kopernicus and Custom Asteroids have been competitors/rivals since 2015, in part because the two mods have taken different approaches to asteroid handling: Kopernicus was, when last I checked, fairly close to stock asteroids, while Custom Asteroids tried to overrule the stock behavior wherever it could. Some players preferred one approach, some the other. But there's also been some synergy: @Thomas P. wrote a much better asteroid spawner than my original design, and Custom Asteroids became much more efficient when I incorporated his algorithm into my own code. Custom Asteroids has fluctuated in quality depending on personal distractions, while Kopernicus has had much more stable support. For all these reasons, I'd be sad to see Kopernicus drop out of the asteroid field, and am glad @R-T-B's proposal at least keeps any existing features. I'm a bit surprised to hear that Kopernicus is having trouble with comets. I tried using Release 61 (without CA installed) while testing some things for RSS, and was able to create my own comets (using the stock "orbit definition" configs) with no apparent problems. I would think that supporting that in the Kopernicus spawner would be well within the spirit of how Kopernicus has handled asteroids historically. Did @R-T-B mean something else when they talked about support for custom comets?