darthgently

Kerbin or RO/Earth? Kerbin is 600km I think. I dunno. I usually recover within double digit kilometers

.. I'm certainly not the one to solve that issue, but those recovery distances prior to the exception look a bit extreme for a recovery to occur. Are those distances accurate to where your craft was? Again, I'm just curious. I am in no position to solve the problem

Are people using KSP 1.10.x ,1.11.x using this mod without any worries? CKAN has it pegged at 1.8.1

Ok, figured it out. Under linux it is RShift-X. Keymappings differ across OSes "1" selects part selection mode; as opposed to offset ("2"), rotate part ("3"), and select root ("4"). I think these are the same across OSes. The RShift-X worked for me. RShift is the 'Alt' on linux generally Thanks for the feedback and help, ppl!

.

I couldn't find a single combination of modifier keys and X that reset symmetry to 1 in a single press. Shift-X decreases by 1, X increases, beyond that nada. This is on linux, so, who knows

Those increase/decrease by 1. I'm talking a hotkey that instantly drops symmetry to 1. Thanks though Oops, didn't see the 'alt'. I'll try that, thanks!

Wow, thanks. I can't believe that didn't cause an error in the logs. I'm fairly sure I'll never make that syntax error again though. Thanks leatherneck, much appreciated. On to the next bump in the road....

I don't see it as feeping creaturism as it is EE that allows the increase in symmetry in the first place; this would just put a governor on its performance impact. If you don't have time that is understandable, but I doubt I'm the only person who would find that it valuable nor has been bitten by the NxM selection explosion and subsequent frame rate implosion so hard to see it as a "feature". Unless having doors on a car is a feature, lol. How about a hotkey that simply drops symmetry to 1? That is all it would do. So on the next GUI Update() it all would return to normal? Actually a that hotkey would be nice if only to not have to press the cycle key repeatedly when dropping symmetry

There are times that I end up painted in a corner performance-wise in the editor when trying to use high numbers in symmetry and accidentally select a high part count subsection of the craft instead of the tiny single part I was trying to click on. And if I have symmetry set to something like 16 that can mean 30 minutes of trying to regain control of the editor as 16 copies of 400+ parts each flail spasmodically around the screen every 42 seconds. Sometimes it is because I forgot I had a high symmetry N set, other times I just click the wrong pixel because of GUI lag or fumbles. Maybe a check box (hotkey?) that will drop the symmetry back to 1 on select if the GUI slows down to < N FPS and symmetry*partcount of selection is > M then drop symmetry back to 1 with N and M being user configurable?

Goal: avoid TweakScale under RealismOverhaul (known to be problematic) by using MM to selectively make 3 or 4 rescaled copies of a few select parts that I tend to want different sizes. To figure it out I started with the stock vernierEngine and am trying to MM copy it to 2x scale. I hand calculated the cubic mass increase (not sure I needed to but will circle back as req'd) and hand calculated the quadratic thrust increase. I think I have the general idea right but am not getting the patch into the correct order with regards to RealismOverhaul patches, or I'm totally missing a step that would actually make them available in the editor generally. The problem is they don't show up in the editor. So I'm open to any education on any aspect of my cfg file even if it doesn't directly solve this issue as I'm trying to learn as much as I can about MM. I've read through the wiki and have done what I can with that info given my current understanding of it at this point; and I'm clearly not understanding something... I'm not getting any related errors in KSP.log, mono.log, or Player.log so unless you really want them, I'll hold off for now. Here is the patch file: // based on RO entry for vernierEngine, a bit of a stab in the dark, placed AFTER RO in hopes it plays nice with RO that way +@PART[vernierEngine]:AFTER[RealismOverhaul] { @name = vernierEngine2x @title = Vernier 2x %rescaleFactor = 2.0 %RSSROConfig = True @mass = 0.08 %useRcsConfig = RCSBlock %useRcsMass = True %RcsNozzles = 1 @crashTolerance = 10 @maxTemp = 1473.15 %skinMaxTemp = 2473.15 @title = Attitude Jet 2x, Conformal (275/445 N class) @manufacturer = Generic @description = A generic conformal RCS thruster 2x. Use this for attitude control or translation/ullage for spaceplanes. LEO-rated heat shielding. @MODULE[ModuleRCS*] { @thrusterPower = 1.1 !resourceName = DELETE !PROPELLANT,*{} PROPELLANT { ratio = 1.0 name = Hydrazine } @atmosphereCurve { @key,0 = 0 254 @key,1 = 1 82.08 } } } // the following is a bit of a stab in the dark also reflecting another RO entry i found for vernierEngine @PART[vernierEngine2x]:AFTER[RealismOverhaul] { @MODULE[ModuleEngineConfigs] { @CONFIG[MMH+NTO] { @IspSL = 0.953 } @CONFIG[UDMH+NTO] { @IspSL = 0.95 } @CONFIG[Aerozine50+NTO] { @IspSL = 0.963 } } }

Is mining for ore or other resources a thing in RSS? Can it be added via an any mods? If so, which ones? Thanks for any info

This may be a bit out there, but how could I configure and/or trick Stage Recovery into allowing multiple Kerbin-side recovery locations? I want to be able to recover at multiple sites with regards to the distance calculation. Ideally, the sites would simply be synonymous with the additional CommNet sites on Kerbin or something like that. But if the only viable way is to go flat-rate I suppose I could do that also. On a related note, how well does SR play with RSS and a different location for launches and recoveries, like Florida's KennedySC? I seem to recall reading that SR alway calculates recovery distance from the stock KerbalSC location on the equator, even in RSS on earth. Is that the case? Does KSCSwitcher change the way SR functions in this regard?

Stage Recovery has completely stopped recovering for me. I tried completely uninstalling it and reinstalling; same result. It works the same as I'm used to in the editor, but in flight I get no success or failures to recover. I can't imagine why reinstalling is having no effect. Are there files I should look to manually for completely clearing out the previous instance? Thanks!

I haven't taken the time to define the issue enough to officially report it but just a heads-up: the required number chutes to get the green highlight in the editor varies greatly for me on the same craft in the same session. My guess is that it might be tweakscale related but not sure. There are times I'm in the editor and merely move the same chutes from one part of a stage to another and the SR final velocity will change almost by an order of magnitude. It can be like rolling dice. Sometimes exiting the editor and coming back in fixes it without changing anything on the craft. And the same behavior seems to affect flight mode but to a lesser degree. I'll have a pair of SRBs that have chutes enough in the editor to be recovered at 4.5m/s and they will fail recovery at a speed well over that predicted speed, more like 15 or 20m/s. Often the incorrect numbers in flight mode reflect the transient incorrect numbers I was seeing in the editor previously. I'm on 1.11.1 with BG but I've been seeing similar behavior since 1.10.x

Yes, it is like rolling dice. Sometimes it works, sometimes it doesn't. I have the lax crossfeed setting so it should just work no matter what. I put fuel lines across it for now and that works 100% and has an even more klassic kerbal look to it now with the external fuel lines to counter a bug. It fits right in

I should have been clearer. I edited the subject. Sometimes it won't *crossfeed* fuel, not transfer. And in the VAB, sometimes when using the 'show fuel delivery overlay' PAW option the tank above the battery from the engines is in the fuel loop, other times it is isolated. When launching, if it happens, I know it because I can't make orbit for lack of fuel. I moved it further up the stack for now, i just wondered if its a known thing and how broad the issue may be.

If this is a known issue, are there any other stock parts to be careful of in this regard? KSP 1.11.0.3045+BG Linux

Thanks, IgorZ, truly appreciated

The first; an API to be accessed from a kOS script. But maybe it isn't valuable enough to enough people to implement. I would understand

I've reached the point where I'm video recording kOS automated flights and the great kOS stock-camera addon is allowing me to control the mapview and flightview camera position, target, distance etc. The ability to read and change the Easy Vessel Switch 'F7' mode from kOS script would allow me to do a smooth switch between map and flight views (smooth transition targeting ship then smooth zoom to ship in map, then switch to zoomed out in flight view (without EVS changing my camera distance or position) followed by zoom in to normal flight view distance). I'm only posting to get feedback or maybe get some gears turning. I could put a sticky note on my screen to remind me to entirely disable EVS prior to recording video, or manually change its mode as required, or uninstall EVS, but I'm hoping to make this a one-click operation while still enjoying the nice functionality of EVS. There are times I want EVS functionality while recording video and being able to script its mode would remove a lot of "oops" in the process. Is this a bad idea?

This is probably not a huge programming problem but a fairly big game play problem. Currently about 1 in 5 times I have to have KIS installed and an engineer on board to EVA detach the ports because they won't decouple or undock the first time properly. But after the EVA detachment they function fine for all future dockings/undockings. By putting into "docked" status upon going to the runway or launch pad and erasing any trace of them being "attached" like any other part my gut tells me a lot of stuck docking port woes that people encounter will magically evaporate. Couldn't hurt to try, right?

Off the wall, but I've had similar things happen when my control point wasn't where I thought it was. Especially the sputtering engine. Verify your control point and that the it is set to the proper direction 'Up' or 'Forward'. A long shot probably

What is the ADDON name for stock camera? Having an issue accessing the MAPCAMERA object Nvrmnd, found the examples on git

Absolutely possible. I've found that the largest hurdle to solving install issues for KSP is that every one else's install is so completely different. Even among linux users there are several different ways Mono can be configured and how the graphics card is integrated in can be very different also; NVidia alone as at least 3 fairly different ways to "get it working" permuting across proprietary or open source drivers, etc. Thow in the permutations of mod combinations/versions, KSP versions, linux distros/kernels, and occasionally mangled GameData data files, sporadic module manager glitches, and the Kraken, and it becomes very unlikely any other player can relate much to what is going on in one's own install. As much as I love Environmental Visual Enhancements, I have to say that many of the slowness issues go away when I'm not running it. It is a shame though because my gut tells me there is plenty of horsepower here to handle it in theory given my graphics card performance, clock speed, etc I am very tempted to build a windows box solely for doing apples to apples comparisons of KSP installs. Same mods, same hardware, etc. Just windows vs linux, but these days, unless you buy the hardware at the same time and do some homework it is very likely the hardware won't really be identical for an off the shelf machine with apparently the same labeling. Dual boot would be the way to do it