rmaine

Thanks for the suggestion. Yes #957 seems to work fine based on a quick check. Think I'll stick with that for a while, as it doesn't look like the revs since then much matter to me. (I had to google to find what KSP principia even was). Also, I hadn't previously realized that CKAN supports reverting to older versions like that. Made it easier for me to decide to test it. After all, as I noted, the workaround isn't hard and I was thinking it would be a fuss to revert by uninstalling McJeb from CKAN and replacing it with a manual install. I was about to do it anyway just to provide the extra data point, but then I discovered CKAN would do it for me. P.S. Hope this doesn't double-post. On my first attempt, I didn't realize I wasn't logged in, so trying again.

"Execute all nodes" appears to have stopped doing so; only does the next node. This used to work for me, but changed recently. I doubt that posting a log file would be worth the bother, as it isn't crashing or anything that I'd expect to show up in the log. It also isn't a real big deal. I just thought there might be a chance that you might pretty quickly have an idea what change might have had an effect like that. I most commonly use this when I'm doing something like maneuvering to a specific orbit for a mission requirement. I click on the point where I want a maneuver and create a maneuver there. I then tell McJeb to create a new maneuver at a fixed time of 0 after the previous one. That's my "real" maneuver; the first one has no delta-v and serves just to easily set the time when I want the next one. Then doing "execute all nodes" used to work fine. Now it just warps to the first node an just sits there doing nothing else. Easy enough for me to deal with. I just need to pay attention instead of getting distracted by doing something else (like peruse the forum :-)) on my other computer while waiting for McJeb to do its thing. Hmm. Another possible workaround just occurred to me. Maybe I could just delete the first maneuver after creating the second one. I'll have to try that next time it comes up.

Oh, I also see the same thing. From Zer0Kerbal's description above, I infer this is a bug.

GitHub one downloaded and unzipped fine for me. And I think I forgot to mention thanks much for this.

Hmm. Hadn't occurred to me it would be sensitive to that, but ok. 64-bit Windows 10, USA, 7zip 19.0 (which I just now checked is the latest version) for Windows x64. System fairly overpowered for the task. i7-7820 CPU, 32 GB ram, NVidia RTX 2080 8 GB video, 2 TB SSD with 1.3 TB of it free. Now that you ask, I also tried unzipping it on my iMac using the unzip program. Also gets an error for the same files. Note that it does unzip most of the files ok. Just "poodles" (as the forum bowdlerizer likes to put it) about those two.

Well, maybe it is just you and me. But that seems unlikely. :-)

Thanks taniwha. That's useful data. I had figured out about avoiding springy suspensions. For supply ships to my Gilly base, I avoid landing gear as they aren't needed for landing there and Gilly is really bad about launching things high into the air on scene load; I just stick a few horizontal beams out from the base of my lander part to help with stability on the ground there. On the root part in particular sagging. Hmm. I already have gotten into making my root pretty minimal - just enough to conveniently be able to expand from (using simple construction). But you give me the idea of trying to set it on a local high spot or maybe something to jack it up just a tiny bit; I'll have to think further on that.

No, I'm not using Blitzy. I have the toolbar controller because several mods that I use require it, but it is basically sort of pointless because without Blitzy there's nothing for it to actually control.

You'd have to ask zer0Kerbal to be 100% sure, but I'm 90% sure that K&K cupola is from planetary base systems. It fits the form factor of the other parts from that mod. I don't want to delete that mod from my save just to check because that would trash everything. I also noticed that the ordinary cupola didn't work; see my post just a few above here. I couldn't tell you about years ago. I've had KSP a few years, but only started using this mod a few months ago.

Do you have the Kerbal Planetary Base Systems mod installed? I'm almost certain that cupola is in that mod. I don't see (though maybe my old eyes overlooked it) that mod listed in CKAN as a dependency for NSSC, but it probably ought to be. The cupola is unlocked by "command modules" in the tech tree. For me, it shows up in the VAB build menu under the Planetary Surface Structures tab,, though that might be a function of the "Group all Parts in Function filter" setting option for Planetary Base Systems.

Pretty minor as "bugs" go, but the OP of this thread mentions the current version as 3.8 and then has a link to what is "new and noteworthy". That link appears to point to a page that has no information after version 3.4. Yes, I find the actual info about 2 posts above this one.

Far be it for me to say that you shouldn't be able to have such an option, which I can then ignore. But it sure seems unlikely to be viable to me. For a start, there's that caveat about the game being bug free. Might as well wish for a free pony to be included while hoping for other things that ain't gonna happen. It's frustrating enough as it is now to have to go back to some save after hitting some bug. Like the ones where my orbit just starts changing as though I'm thrusting even though I'm not. Or I have a base that is perfectly fine, but then self-destructs because of physics phase-in when I go elsewhere and then back to that scene. Or other things. Those sorts of things are frustrating enough as is, but would be beyond frustrating in an ironman mode. And then, as someone else mentioned, there would be the need to add "simulation" capability. Somewhat amusingly redundant in that the whole game is a simulation in the first place. I ought to be able to test whether a design is capable of doing the job before committing to fly it in ironman. Hey, NASA never simulates things before flying, right? :-) (Actually they simulate the um... nether regions out of things before flying.) Of course, NASA also heavily uses autopilots, which some people here seem to consider "cheating." I recall seeing a KSP 1 mod for something like a simulation mode inside of KSP. And there's always the option of starting a separate test game in a sandbox non-career mode to try out something, but that's a lot of fuss. For a decent ironman mode, you'd want that built in. Anyway, all in all, no I would not use an ironman mode. That doesn't mean I'd object to you having one available, but it does imply that I'd hate to see significant development resources spent on such a thing to the exclusion of something I'd consider more useful. (And development resources *ALWAYS* involve tradeoffs.)

Aha. Likely useful data. I just hit it again. Have a screenshot of input locks, but it is incredibly boring and not worth the bandwidth. Just says current input locks: AmpYear_KeyBinder and bitmask 0. I wasn't even using ampYear when I previously hit this, so that's presumably not a useful hint. But you asked about the config.xml file and deleting the PluginData folder (which has literally nothing but that file). Copied that file and deleted the folder. Voila! (Or as I'm prone to mistype it, viola). Deleting that folder made the problem go away. The folder was automatically recreated when I restarted the game and I compared the old and newly created config.xml files. Only difference was in the MainGUIWindowPos. The old (bad) file has NaN for both x and y. That looks highly suspicious to me. File shown below, but I'm betting that was the important bit. BTW, I run with a KSP UI Scale of 170% (otherwise, my old eyes can't read anything unless I drastically lower the resolution). That might be related and might be why this isn't hitting darn near everyone who uses the mod. ?xml version="1.0" encoding="utf-8"?> <config> <bool name="DisplayTargetGUI">0</bool> <bool name="DisplayDescentProfileGUI">0</bool> <bool name="DisplaySettingsGUI">0</bool> <bool name="UseBlizzyToolbar">1</bool> <bool name="DisplayTrajectories">0</bool> <bool name="DisplayTrajectoriesInFlight">0</bool> <bool name="AlwaysUpdate">0</bool> <bool name="DisplayCompleteTrajectory">0</bool> <bool name="BodyFixedMode">0</bool> <bool name="AutoUpdateAerodynamicModel">1</bool> <rect name="MapGUIWindowPos"> <xmin>0</xmin> <xmax>1</xmax> <ymin>0</ymin> <ymax>0</ymax> </rect> <bool name="MainGUIEnabled">1</bool> <vector2 name="MainGUIWindowPos"> <x>NaN</x> <y>NaN</y> </vector2> <int name="MainGUICurrentPage">0</int> <bool name="GUIEnabled">0</bool> <bool name="NewGui">1</bool> <double name="IntegrationStepSize">2</double> <int name="MaxPatchCount">4</int> <int name="MaxFramesPerPatch">15</int> <bool name="UseCache">0</bool> <bool name="DefaultDescentIsRetro">1</bool> </config>

"One fish, two fish, red fish, blue fish..." If you haven't had young kids, you might not recognize the Dr. Seuss allusion. If you have had kids, you might have been making such an allusion. :-)

Ah. Good point about "EL" vs "EPL". The grammatical distinction between "extra planetary" and "extraplanetary" is probably a bit subtle for many people. Probably about as difficult to get people to understand that one as it is to get them to understand that the plural of "craft" is "craft" (a pet peeve of mine, as I find it downright jarring to read :crafts". :-)

I once tried wordstabilizer. A brief test seemed to help with 2 of my bases that were a bit prone to problems. So I started playing using it. Before long I was at a base that had previously been fine, so I hadn't tested it. Broke the base right in two. :-( That was the end of my trying it out. I can't tell what's in USI-Core without installing it. I don't know an easy way to tell what parts a mod adds if it isn't documented separately somewhere, Guess I could try installing it to see.

That (having some way to afix bases to the ground) would be great.It's one of the bigger annoyances that I've run into that bases don't stay put. Some crawl around (and sometimes even crawl into each other if you have multiple ones close together). Others do a whiplash thing on scene load. Some go flying into the air, possibly with fatal results. Gilly is particularly prone to bases flying into the air. I've fiddled with lots of things, but haven't yet gotten anything that really solves it consistently. None of this seems particularly realistic.

JohnAC, CKAN catches so many problems that I sure recommend using it. For example, I don't see "zero miniAVC" in your mod list above. CKAN would have installed that as a dependency. It's a sort of odd "mod" in that all it does is delete the broken miniAVC that's otherwise in a lot of other mods. I couldn't testify as to what effect that might have, but it likely isn't good. Who knows what other problems it might help you with. I just finished making the same explanation in another thread, but you can tell CKAN to accept mods listed as compatible with other versions of KSP than the one you are running. That of course has the potential problem of allowing you to install mods that actually are not compatible, but it also allows you to install ones that work fine but just don't have their compatibility data updated. In the CKAN settings menu there is a "compatable KSP versions" tab. Go there and select both 1.8 and 1.9. Then it should allow you to install precise maneuver. P.S. I'm fighting with a bug that sure appears to relate to Trajectories, but no solid conclusion yet.

If you are getting a message about incompatibility when you install manually, I wonder where that message is coming from - seems likely to be from miniAVC, which is installed by *LOTS* of mods, but is known to have problems with recent KSP versions. I know that some people feel otherwise, but I personally recommend using CKAN, which would have taken care of that in the process of installing required dependencies (notably toolbar controller and clickthrough blocker, both of which in turn depend on zero miniavc, which nukes all the broken miniavc copies). Yes, CKAN complains about several mods not being compatible, even though they actually work fine but just have not had their compatibility data updated. That's a minor annoyance, but a solvable one, and the solution is simpler than all the problems you run into when trying to install without CKAN. In CKAN settings there is a tab fpr "compatible KSP versions". Go there and add 1.9 and 1.8 as compatible. You'll need 1.9 because some mods just list 1.9.0 and you'll need 1.8 because that's what gravity turn continued lists. I've used gravity turn continued with 1.9.1 for a while. Though not strictly required, I find it helps a lot with the drudgery of manually launching the same or similar vehicles for the zillionth time. Edited to substitute "complains" in place of a word for female dogs. The forum bowdlerizer doesn't like that word, even when used in a manner not normally considered impolite. I don't think the "poodles" that the forum auto-substitutes quite catches the same meaning. :-)

Just a few comments to pand1024. I personally find "orbital greenhouses" to be almost worthless. I assume you mean the hydroponic labs; if there's actually some sort of different orbital greenhouse in EL or something, then ignore my comment on this. When you look at the mass of a hydro lab compared to the mass of just hauling snacks you have to be out something on the order of 1000 days to break even, even for the high tier hydro labs. Maybe for missions to the outer planets or perhaps for stations that are staying up indefinitely, but I don't see them as helping much for missions to dres or inside that. Gilly. Yes, it is trivial to land on Gilly. Heck, you can literally land a kerbal from Gilly orbit using just his/her suit's RCS. Do *NOT* however, try to use MechJeb's autoland; it can't seem to deal with the low gravity sensibly, particularly on final landing below 500 meters. My biggest prob;em on Gilly has always been staying landed. :-) Physics phase-in tends to make many vehicles bounce wildly off the surface - sometimes fatally - on scene load. A trick I've used is to avoid putting landing gear on anything landing on Gilly. The springiness of the gear tends to make the problem of bouncing on scene load really bad. If you need something to help stabilize things, I just stick some structural beams out horizontally from the bottom of my landing craft; works much better than gear on Gilly.

I don't think it has much to do with strength. Just mass... or more specifically probably moment of inertia. I also see the behavior with my ships that are big and lumbering in the first place - they are even more so if I let MechJeb turn them. Looks to me like MechJeb only uses some percentage of the available torque. If the vessel is fairly nimble, that's still plenty. Minorly annoying to have to take over myself, but it isn't at the top of my list of annoyances. I have a long list, but most of them aren't worth posting because they are minor enough that I'd rather the maintainers not be distracted by them so they have more time for the bigger things.

I was "lucky" enough to run into it again just now only a few days after last time. Clock was all green. Have been doing a lot of stuff, but now I'm flying "ike base 2" in low orbit around ike. Do a quicksave in preparation for landing (ok, call me a wimp. :-)). Warp to intended point to start descent and then remember that I'm in a retrograde orbit, so this is the wrong point. Restore my quicksave. Warp to a more appropriate starting point and start a retro burn. Try to bring up the trajectories window to help judge my aim point. Doesn't come up. Heck, none of the toolbar buttons do anything; this is familiar. Glad for that quicksave. Escape key to quit to main menu and then exit program. That's ksp-bad1.log and player-bad1.log linked below from my dropbox (assuming I manage to get the links inserted correctly). Restart the KSP program. New career game. Make and launch a 2-part rocket (capsule and flea). Sitting on the launch pad and none of the toolbar buttons work. Escape quit to main menu and quit program. That's ksp-bad1.log and player-bad2.log linked below. Use CKAN to delete the trajectories mod. Restart the KSP program. All looks normal (and I land "ike base 2" fine.) https://www.dropbox.com/s/oim34hi4lnoryyg/KSP-bad1.log?dl=0 https://www.dropbox.com/s/zpfwyq6takkm8c3/Player-bad1.log?dl=0 https://www.dropbox.com/s/h497i5vy7a50dni/KSP-bad2.log?dl=0 https://www.dropbox.com/s/y7q2hxfyj4tbso1/Player-bad2.log?dl=0

I think I recall it looking normal (green), but I'll be sure to check if it happens again. Doesn't seem like a likely cause to me though because of the way it persists. In particular, still there when starting a brand new career with absolutely nothing flying except a 2-part rocket (capsule and flea - not even a chute) sitting on the pad? That doesn't seem like a place the system should have much trouble keeping up (and I have a moderately fast system - I7-7820 CPU, 32 GB ram, 8gb RX 2800 video, Samsung 970 EVO SSD). Once it triggers, it persists in all games until I delete and reinstall the mod. I'll grant that my thoughts about what seems likely are not proof. I can't open the trajectory window (or any others) at all once it happens and I can't really see leaving it open and in the way all the time while waiting for something that takes as long as this seems to to hit me.

Dang, I'm running into a really annoying bug that I think might be from this mod. Unfortunately, I can't provide useful logs because it is (temporarily) gone now and I can't reproduce it at will, but it has happened 4 or 5 times before I deduced it is likely this mod. With that sorry introduction... The bug is that the program stops responding to many (but not all) keyboard and mouse inputs. During flight, I suddenly find that I can click on many things, but not, for example, any of the toolbar icons (stock - not Blitzy) on the right. Also can't bring up the button to return to the space center. I can still get back there using the escape key. Once this happens, it hits all saves in that copy of KSP. I can even start a brand new career and it is bugged in my very first trivial rocket. I googled around and found mention of clearing input locks using the debug menu. That didn't solve it though. Before today, the only way I managed to solve it was to make a fresh copy of KSP, reinstall in it all the 37 mods I'm currently using (thanks to CKAN for the help there), copy over my save game and vehicle files, and then reconfigure some of the mods that need configuring to my taste (notably font size). That works, but is really painful - enough so that I was about ready to give up playing KSP for a while (even though it has been a nice distraction during the lockdown). I didn't see anything that struck me as obvious in th elog files, though they are painful enough I could have missed much. Happened to me again today and I decided to play the game of deleting mods to see if and when it went away. Couldn't do that with my real career game, as deleting mods would pretty quickly trash that. But since the problem persists in a newly started career, I could work with that. Deleted most of the "bigger" mods I use with no effect. But when I deleted Trajectories, the problem went away. Added Trajectories back in and things are still good, but I'm thinking it must have been something in the deleted copy of Trajectories. Of course, now that I'm not seeing the problem, I don't have any useful logs. Sorry for what I know is a miserable job of bug reporting, giving you little to work with. Oh, BTW I'm on KSP 1.9.1 on iIndows 10. Time to go reinstall all my mods now. I suppose now that my suspicions are pointed at this mod, I can try deleting just it next time. I'm guessing there will be a next time, though it has tended to be a week or more between times it has happened so far.

I've been using it all along in 1.9 and 1.9.1. No observed problems (other than the forum flaking out on my first attempt to post this; sorry if it double posts.)