KSPrynk

This will probably work (I'm assuming you know how to backup your save and re-install if it doesn't): Using a text editor, like Notepad, go into Restock.restockblacklist and delete the line for Squad/Parts/Engine/rapierEngine/ and save it. This should prevent ReStock from blocking the Stock model from being loaded. Then, go to ReStock\Patches\Engine and find restock-engines-jet.cfg. The Rapier appears to be the only engine in this .cfg file, so your options are: 1) Delete the file completely (or, if at some point, more engines are added, delete all the lines that fall under the Rapier section). 2) If you want to keep the ReStock special effects, you might be able to clip out all the lines relating to the mesh and model, between the author and EFFECTS, but this line may be problematic: @PART[RAPIER]:HAS[~RestockIgnore[*]]:FOR[ReStock] I think you can get by with just @PART[RAPIER], to tell it that everything after gets applied to the Rapier. There's a Wiki here... https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax ...but I've been learning syntax the same way Antonio Banderas learned how to speak to Vikings in The 13th Warrior.... Remedial action, in case this screws everything up, should be to close KSP, delete your ReStock folder, and then just re-install ReStock. Side effects may include harmless tech tree duplicates that won't go away unless you start a new game, so I would experiment with this in a new-start Career game. Or better yet, create a separate, bare bones, install of KSP under a different folder and experiment in that.

I'm using Stock Visual Enhancements with Spectra by pruning out redundant EVE, Scatterer, and Texture files or lines in combined .cfgs that cover the Stock planets, or anything that looks like a duplicate of what comes in Spectra (eclipses, shadows, ), leaving behind just the OPM ones. I probably haven't clipped it all out, but it works. I think Eeloo doesn't receive the Spectra changes when I do this (since it gets moved to Sarnus), but it's better than nothing. Poodmund's OPM Visual Overhaul may get re-worked eventually; he last commented on it in March....

I understand the frustration, but it all it really does is extend the mapping time (tidally locked moons will be a pain) and forces you to be more clever in how you choose an orbit. My initial gripe, when this capability first appeared, was that the sensor was still consuming full power, even when it couldn't map anything, which meant I still had to have plenty of batteries to get through orbital darkness. Regarding a new imager that doesn't require daylight, I'll leave this food for thought: 1) An illumination system - near-infrared, UV, or visible - that lights up the ground from orbit would likely be insanely large and powerful. Read up on proposals by Krafft A. Ehricke for what were essentially orbital heliostats (https://www.nytimes.com/1977/02/06/archives/huge-space-mirrors-proposed-to-light-the-night.html). 2) A more realistic approach is probably a space-based sensor that operates in the thermal infrared bands, longwave infrared being a good one if you want to go hyperspectral. Thermal infrared is emitted light, not reflected, so it can work in the dark. One drawback is your sensor pixels will be noticeably bigger than your average visible light pixel, and your optics size would scale up proportionately (and your mass even more so), assuming you want the same resolution and field of view in your image. The really sensitive thermal imagers are also cooled to cryogenic temperatures, which would translate to increased power consumption (some of the ones pointing outside the solar system are cooled with liquid Helium (ex., Spitzer), but no need to get crazy here). EDIT: Regarding extended mapping time, I haven't looked at a worst-case body rotation period, and how long the generated contracts run. Something to maybe look into....

@Avera9eJoe, I'm favoring this (unless the 1.10 textures don't live up to hype). Partly because I don't want the heartache of having to choose on a per planet basis, but, more pragmatically, anything that saves RAM by eliminating redundancy of (assumed) equally good results is a win. I think the value of Spectra is giving the extra ambiance and subtle details, which the base game doesn't provide, that can be enjoyed everywhere from ground level to high orbit. Alternatively, if there's still demand for the alternate terrain and textures, you may want to consider dividing up the Spectra folder structure to make it easy to prune redundant material out, or give instructions for quick and safe removal. Perhaps a MM patch or settings.cfg file could allow users to enable or disable loading of redundant material. This would please the terrain/texture fans, while helping out the RAM misers. I guess one thing to look into is which, if any, EVE or Scatterer effects are broken when using the Squad terrain. That might merit separate .cfg files.... I can also think of some new effects to look into for the future: - Infrequent rain, snow, and/or ground lightning, perhaps with dedicated cloud layers, separate from the planetary global fractals (or however they get derived) on Kerbin, Eve, and/or Laythe. - Infrequent large scale dust storms and/or fog (localized, ground level, "dirty" or white clouds). - I don't want to pre-judge the new 1.10 comets, but I'd be mildly shocked if Squad had atmospherics to go with them. If there aren't spectacular tails and geysers that come and go with distance to the Sun, then we may just get dirty textured asteroids on highly eccentric orbits.... I'd be curious if weather FX placement algorithms can be bounded by lat/long boxes or biomes to certain regions (ex., Kerbin's deserts for dust). Perhaps frequency of FX appearance can be tied to seasons derived from planetary distances from the sun or pulling the orbital LAN coordinates. There are so many factors that trigger weather, but I think some simplified, generic, rules could carry the day, if the appropriate situational data can be queried from the game. Perhaps to avoid continuous computation, the "weather" could be "refreshed" at relatively large intervals, and planetary or regional flags to enable FX could turn on and/off as appropriate daily rotation and/or annual orbital timing parameters dictate.

@micha, @SuppaTenko, going back to some discussion a while back about limiting experiments to Kerbin SOI, I was thinking about what experiments shouldn't have different results (and increasing science return) based on what body you're orbiting. Microgravity material and life science experiments that aren't particularly influenced by local space radiation or magnetic fields come to mind. Picking through the science defs from NEOS got me interested in how they're defined in the KSP wiki, and ways to constrain where a experiment can be performed. I use DMagic Orbital Science and SCANsat and some of those parts get clever in defining discrete altitude bands where they can be used (which I have to pick through to figure out how). One thing I haven't come across so far is a way of allotting science points without any multipliers for the body being orbited, and constraining it to only be performed once (or with diminishing returns) anywhere within the solar system. I think this would be appropriate for some of the really high payoff experiments, to prevent a tech tree sweeping situation similar to what SuppaTenko described, by running them across Mun and Minmus orbits.

@micha, the Kemini HGR fixes look great. At some point, you may want to update the OP instructions and/or KSPedia to explain the "move" function when the experiment storage location and lab are in separate parts (which I assume only applies to the HGR SoyJuice family). I got it on the second try. The first time, I think I did a sequence that led to a logical dead end that closed up behind me, but I haven't been able to replicate it since.

Thanks. I got a sense of how Kemini_module and StoreExperiments worked once I figured out why the SoyJuice descent and orbital part cfgs had only one or the other, but every other craft had both. Regarding game balance, I'm trying to reserve judgement until I start a new career (waiting for KSP 1.10 and Kopernicus) and try it out, but the 2nd level KEES and Life Science experiments have huge science defs, which, at first glance, look like they become tech tree sweepers when the multipliers from further planets come into play. Part of me says these types of experiments would, in reality, not be significantly different just by changing locales. I noted further upthread a discussion about limiting KEES (and maybe the rest?) to just Kerbin SOI use. OTOH, I do recognize that getting these unique experiments up, assembled, and more importantly, back down, adds a layer of complexity that would be incentivized by a high science payoff. Still, that's a lot of science....

@micha, I'm having an issue with Kemini on the SoyJuice suite of parts from HGR. From the .cfg file, it looks like the experiments are loaded and stored in the SoyJuice command pod, but the experiment is meant to be run from an attached orbital module, like the Onion, as long as there's a Kerbal in that module. I'm able to load and run an experiment (the PAW button shows up on the command module), and then end it (the PAW button, and lab time shows up in the orbital module), but I can't finalize it, nor start a new experiment. On the orbital module, it'll say "Kemini Lab: [experiment name]: Finished. Am I missing a step somewhere? Is the Finalize function meant to operate on the part running the experiment or the one storing it? I'm running KSP 1.8.1 and HGR Community Fixes version 1.7.0. I've tried this with both the green and white variants of both the command (SoyJuice) and round (Onion) orbital modules. EDIT: I understand the cleverness that's trying to be accomplished by running science in an orbital module, but if this is an unresolveable logical conflict, it may merit keeping the experiment-running function in the command module, like the other craft do.

I'm surprised I hadn't looked into this mod until just recently. It really gives some incentive to maintain space stations and gives small capsules something to do other than bring Kerbals up and down. That said, is there a reason that the Material Exposure Platform is a whopping 8 tons when the Kolumbus, nearly three times its size, is only 3 tons (comparable to Stock MPL)? Did a decimal point get lost, because 0.8 tons makes more sense. Also, what is the difference between the KEES POSA I and II, aside from the massive amount of science the POSA II can collect? Except for being a level higher in the tech tree, it has pretty much the same physical and monetary costs.

I can confirm the same on the basic OKTO. The irregularities are not the same on all eight sides, so be sure to verify a fix on each face.

Some of the nuclear thermal rockers are bi-modal (i.e., produce continuous power when not thrusting) and some are not. This is different from an alternator, which produces power only during thrusting. Unless you don't like surprises being ruined, I recommend starting a separate sandbox game and checking them all out. As far as I know, you don't have to turn on a generator in any of the bi-modal NTRs (although there are usually integrated radiators to turn on), like you would for the dedicated nuclear reactor powerplant parts (which come in the Near Future Electrical mod), but I haven't checked to see if I'm a version behind on KA and whether that requirement was recently added. On the NFE powerplant reactors, you have to start and set the power output level manually. Just don't set them higher than you need, because Uranium will get consumed and you'll burn it all up on long trips, whether you're using the power or not. I was reading upthread that the NTRs also consume Uranium at a relatively high rate, but it sounds like that's only during thrusting. EDIT: Just to follow up, I'm using KA v1.1.2 (current) in KSP v1.8.1, and the baseline LV-N does not have a generator, but does have an alternator. Conversely, the Eel (my favorite) and Neptune both have generators that run whether the integrated radiator is turned on or not. Build a craft with a partially charged battery and an Octo probe core as the only power consumer, and you'll see the battery start to refill. There's no indicator on the PAW though, other than "Generator: Nominal". What's interesting is they do have the alternator module, but they're set to a negative output vs the generator output, so thrusting doesn't produce extra power. I also didn't see anything about Uranium being consumed in the engines I looked at. So either it's certain engines (I cut out engines bigger than 1.25m to save RAM) or another mod that adds some more realism to consume it in NTRs. EDIT 2: Also keep in mind, LH2 boils off and CryoTanks adds a power consuming cooling capability (proportional to amount of propellant in the tank) to prevent that. I think cooling is set to "on" by default in the dedicated Hydrogen tanks, but set to "off" on all the other tanks. It can be switched on and off in all the tanks.

No, I'm not the module dev! I'm assuming that's @RoverDude. I was just expressing gratitude for you guys locating it for me. If you found a bug in MKS on this then, yes, put it on his GitHub. As far as a new part, I wasn't planning on publishing anything, as I don't have any modeling software. What I have developed is some rudimentary skill in recycling .cfg files to leverage existing part resources, which I change the parameters or modules on, and save as new part files for my own use. I figured the Micronode would be unobtrusive, but I don't know enough about the code physics of both the tether functionality and the root cause of Bug #24061 to do more than just try it and see if it works well enough to keep my little probes from dancing away....

@B-STRK, @Tokamak, I'm glad you unearthed the Ground Tether functionality. I was actually wondering a few months ago if the associated module would be a useful band-aid for Squad Bug #24061, where objects landing on planets with atmosphere seem to dance on the terrain. I haven't upgraded to 1.9.1 yet (Kopernicus-less), so I don't know if it eventually got sorted out. I added the USI_InertialDampener module to an Octo core (actually, into the patch for ReStock, since my test install of KSP 1.8.1 was running with it) and de-orbited it onto Duna, as part of a tiny lander. When I increase the physics warp, the dance on the ground becomes immediately noticeable. What's interesting is that, when Ground Tether is enabled, the lander still dances - even a bit more precariously - but stays in the same location, like it's been harpooned to the ground. When I turn off the ground tether, the lander will jitter its way along the terrain as it would without the patch. I've been thinking about creating a dedicated "harpoon" part (maybe recycling the Micronode model for now) that could be attached to other craft, rather than applying the patch to multiple parts. I'm trying to think of the disadvantages or limitations of this approach....

@Nertea, I love that you've revamped SCANsat's parts. Were you planning to collaborate on something similar for DMagic's Orbital Science parts?

I was wondering how many vis-mods were going to encounter this same dilemma as well. I was thinking of experimenting with selective pruning myself, once Kopernicus and everyone else caught up to 1.9.X. I'm still mashing Spectra for the Inner Planets with SVE for OPM. And now there's MPE (drool). I'm not opposed to a friendly Vis-Mod competition, but I'll just say I'll be heartbroken if I can't give Laythe its bioluminescent clouds. That view makes it the most desirable piece of real estate in the entire Kerbol System.

I tried out the low res mapping radar on Edas a while back. Seemed to work fine. I've been meaning to check to see if there was more than one surface biome per planetoid. Had some wackiness with Persistent Rotation with my spacecraft flipping over in a polar orbit while trying to keep the solar panel side facing the sun. I haven't pulled the thread to see if that's unique to this mod. Unfortunately, I've held off getting invested in a new Career, while I'm waiting for Kopernicus to upgrade to KSP 1.9.....

That's too bad. I applied the same rules to the Neptune and Stubber for large, life support enabled, outer-planets exploration craft, and they look great. I would love to be able to change the engine plumes for Methane/Methalox coloration but I need to learn more about how that works. If at some point you do feel interested again in realistic NTRs that have detailed analysis and design models already done, check out the Scorpion Nuclear Thermal-Electric Rocket. It's a JBIS design (behind their paywall, unfortunately, but previewed here: http://www.projectrho.com/public_html/rocket/realdesigns4.php#scorpion) that effectively leverages the heat exchanger system of the Skylon SABRE (KSP RAPIER) engine to drive an electric booster for the NTR exhaust. This bypasses the chronic solid-core NTR limitation of reactor temperature on exhaust velocity, eliminates the need for post-burn propellant purging/cool down cycles, and has a side benefit of minimizing radiator requirements because the propellant doubles as powerplant coolant. More physics details on the basic premise, and how the variations in design impact performance are found here: http://toughsf.blogspot.com/2019/09/nter-nuclear-thermal-electric-rocket.html

@Nertea and KSP community, with the upcoming move of Methalox patches for LF engines to CryoEngines, I thought this may be a good opportunity to float the idea of something similar for KerbalAtomics. The advantages of liquid CH4 over LH2 in combustion engines are equally applicable to NTRs: greater propellant tank density, reduced boil-off problems, and respectable Isp between LH2 systems and more complex, higher density fuels. I took a stab at modifying an Eel into an “NV-10M” configuration. Referencing Atomic Rockets’ (http://www.projectrho.com/) values of molecular weight of various propellants versus exhaust velocity in a solid core NTR, I scaled the Eel’s Vac Isp down from 935 to 730, and inverse proportionately scaled the Vac thrust up from 12kN to 15.37kN. I also edited the Atmosphere curves proportionally, so key = 0 730, key = 1 140, key 4 62. I’m assuming this is primarily dictated by nozzle aspect ratio; I’m not sure how much propellant molecular weight vs surrounding pressure factors in. I jacked up the price from 12,000 to 15,000 to nerf it a bit for “complexity reasons”, which I’ll go into at the end. I then created a comparative test craft: a Mk1-3 Cmd Pod, a single H375-72 tank, and either a standard LH2 Eel or the Methane variant. The results were… NV-10 Craft: 7.661t wet mass (54,000 units LH2), 3.835t dry mass, has 6,345m/s of dv NV-10M Craft: 20.307t wet mass (36,000 units CH4), 4.985t dry mass, has 10,055 m/s of dv Obviously, the Methane craft has a ~4:1 mass ratio, whereas the LH2 is only ~2:1. If I triple the number of LH2 tanks, I get 10,489 m/s dv for a 16.84t wet mass (3.14:1 mass ratio). But now the LH2 craft is over twice as long, which means more launches, assuming my constraint is now the fairing size of the lift rocket, not its payload mass capacity. Note, I haven’t factored in additional power generation capability required for tank refrigeration to prevent boil-off, which will be significant on the LH2 propelled craft. I think this makes the case for a Methane NTR, the same way it does for a combustion engine. It’s a happy middle ground for performance vs economics. Methane NTRs have one potential engineering problem to deal with, and that’s decomposition of CH4 into separate Carbon and Hydrogen molecules at high temps. The free Carbon may start “coking” on the fuel elements and/or engine interior, constraining the propellant mass flow. I’ve found a little bit of real hardware research on how this effects electric engines, like resistojets/arcjets, but nothing on NTRs. With the flow masses involved, there may be a lot of free Carbon liberated, but the flow path of the wide variety of NTR configurations likely dictates the percentage that blows through vs getting stuck. I haven’t found much literature on *demonstrated* techniques to mitigate this, but I’ve seen everything from assumptions about coatings that don’t give free Carbon a place to bond, to running “power wash” cycles periodically (maybe squirting a little free Hydrogen, or even water, through at the end of a burn). The Eel seems like one potential way of getting ahead of the problem. It’s a pebble-bed NTR, so even if the fuel elements start getting a coating of soot, they’ll just naturally space themselves out more. Also, the rotating bed of fuel, particularly as it gets filled and emptied between operating cycles, may end up being a natural mechanical agitator to just shake off Carbon build up. I think the proposed NV-10M would be a good entry point for Methane NTRs, and it should be fairly easy to introduce on multiple NTR parts, now that fuel switch functionality comes with the LH2NTRModSupport extra. Some nerfing of different NTRs, like the plain LV-N solid core, could maybe have a small, arbitrary, Isp reduction to account for Carbon build up over the craft’s realistic mission life, or overhead resources associated with a cleaning cycle. Thoughts?

This looks fantastic, and really fills in a niche that should've been covered a long time ago. Any pointers on how to get a transfer when the SOIs are small, orbits are eccentric, and also fairly inclined? I spent two hours trying to get to 433 Edas, and MJ and Astrogator didn't give much in the way of positive feedback. I think they make an honest attempt, but, yikes - SO many correction burns....

Ignore this

These look beautiful. What's the current gameplan for Methalox engines? I thought I read a while back that you were moving the supporting patches to CryoTanks? Are there going to be Methalox variants in all sizes or still just the two 1.25m and two 2.5m from the legacy conversion patch?

FYI, this appears to work just fine in KSP 1.8.1. Still can't believe it isn't Stock yet....

@Nertea, yeah, I'm guessing cut-out rings/holes and intended operating speed dictate the design-to drag goals which KSP has to approximate an effective drag and area value to. So, after attempting to infer the mathematical reasons for the Stock chute scaling, I gave up and resorted to visual measurements, i.e., taking some screenshots and doing scaling measurements in Powerpoint. This may have no bearing on real parachute physics, but at least it's somewhat more intuitive, and approximately scaled for whatever Stock was going for. Assuming the Mk16 inline chute canopy is the baseline model (8-10 meter deployed visual diameter?), my suggested scaling values are: Mk12-R Radial Drogue --> 40% of Mk16 canopy Mk16 Inline Chute --> No change Mk2-R Radial Chute --> 80% of Mk16 canopy Mk25 Inline Drogue --> 25% of Mk16 canopy (assumes ReStock 2-chute cluster) Mk16XL Inline Chute --> No change (assumes ReStock 3-chute cluster) I don't know if the semi-deployed canopy scaling will automatically scale proportionally if the fully deployed value is changed. If other forum members can point me to a way to re-scale the canopies in certain .cfg files, I'd double check this myself to see if this passes a sanity check.

I've seen this in Win10 KSP x64 as well, after dropping a lander onto Duna. At first it looks like the terrain is shaking. After popping in and out of the map view, the terrain stopped, but the lander was still shaking. I've also upvoted the relevant bug on the tracker.

Follow up to above: I've been picking through the ReStock .cfg file for the parachutes. At first glance, I don't see a way to separately re-scale the drogue canopies, to correspond to their effective areas as they do in Stock, without re-scaling the size of the container model. Tweaking this shouldn't be a craft-breaking edit, as I believe the canopies themselves don't interact with anything, other than what their specified drag-cubes state.