KSPrynk

@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.

Is it the standard vs drogue parachutes? I've noticed the ReStock radial standard chute (Mk2-R) and the radial drogue chute (Mk12-R) are visually the same size when deployed, even though the effective area of the drogues are lower, and the drogue container is smaller than the standard. The Mk16-XL and Mk25 drogue make a little more sense, because they're multiple parachutes, though you're getting two chutes in the Mk25 from a container that spits out three chutes of the same size on the Mk16-XL. The chute area vs deployed visual size vs container size seems counter-intuitive.

@Nertea, another request on NFeX: the indicator line for the antenna feed-to-reflection defaults to "on". Even after turning it off, adding another antenna brings it back up again, adding clutter to the VAB. Can we get a global Toggle so the indicator stays in the last state (on or off) until that state is deliberately changed by the user? I've added a separate Issue on GitHub.

@Nertea, FYI, I added an Issue on the NFeX GitHub regarding PLTO core orientation and placement of labels relative to the orientation of the new probe cores. These are cosmetic issues, but I think they cause some confusion in trying to figure out, at a glance, which way a probe core is oriented, both in the VAB and in flight. Great job jumping on probe craft; they've needed some love for a while now.

@RJVB09, I just tried this out and it looks like a great. I'm very interested in real world red and brown dwarf systems and the visual impacts associated with shifted lighting spectra. Just FYI, I'm seeing a graphical glitch (I think) on both Brun and Tersa where there's a cloud of "glare" that's not centered on any particular celestial body. On Brun, it's just outside the orbit of Yurff, and on Tersa, it's slightly inside the orbit of Gren. I'm using Kopernicus 1.7.3-2, EVE 1.7.3, and Scatterer 0540. I did this on a separate test instance of KSP 173, with no other planet packs or planetary FX mods. But speaking of spectra.... I'm running my fully modded KSP 173 game with Spectra on the Stock system and SVE, more specifically, a pruned version that just keeps the configs for Outer Planets Mod. There's some kind of conflict with 3LR, which I haven't narrowed down yet, that seems to overlap cloud and lighting effects, with and without the BoulderCo and Improved System folder contents. If feasible, I would suggest supplying graphical FX configs, perhaps with new names, that don't refer to .cfg files that have content that may be re-used amongst other planets, either Stock or add-ons, like OPM, GPP/GEP, ES, etc.. I'm on the fence regarding system placement, relative to Kerbol. Given their distance, Warp Drive appears to be the *only* way to get to them. Are there any non-FTL drives that could make it without game-millennia of travel time? Lastly, can you talk more to your vision for the 3L series?

I thought they got new plumes in Zorg's RealPlumeStock, as of v1.5. Wasn't sure if that was his own implementation or in collaboration to update to new FX format. In any case, EngineLightRelit seems to have gone to a more elaborate parameter format, which I think I first noted in KA, when the LH2NTR issue resurfaced. Without going back and trying to put together older versions of NFE and EngineLight, I was wondering if the EngineLight glow effects were supposed to match the plumes, and whether !MODULE[tjs_EngineLight] was supposed to set the color. My suspicion was that this reference to the module was now pointing to a dead end when using EngineLightRelit.