Jump to content

rmaine

Members
  • Posts

    222
  • Joined

  • Last visited

Everything posted by rmaine

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.)
  7. 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>
  8. "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. :-)
  9. 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". :-)
  10. 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.
  11. 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.
  12. 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.
  13. 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. :-)
  14. 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.
  15. 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.
  16. 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
  17. 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.
  18. 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.
  19. 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.)
  20. See 2 posts above yours. Not that my brief test guarantees much. Now I've been using 2.0.3.2 with 1.9.1 for longer enough to be more confident. All the money I was paid for this testing back if it breaks your game. :-)
  21. Did a quick glance at 2.0.4.0 in my KSP 1.9.1 game. A few trivial observations. 1. Not sure what's different in my setup, but the top two lines in the regular window (current vessel and vessel status) are all but unreadable because of the color. It's dark-colored text (black or dark blue, depending on which skin I select in settings) usually on a dark background. The font being small all around doesn't help either, though that's not new. The teaser samples above show nicely visible white or light green text (and larger, but that's probably because I bet they are with lower screen resolution than I have). 2. Oh, speaking of not new, I randomly find the toolbar icon (in the stock toolbar - I don't use Blitzy) missing. Jumping to some other scene and then back tends to bring it back. It seemingl;y being random, I can't easily reproduce it in a quick session just to provide a simple debug log. Usually I'm in the middle of something that I'd prefer not to interrupt to go save a log, and the jump elsewhere and back thing does work around it. I've had that before; just noticed it once also with 2.0.4.0. 3. I'm not seeing the request resources button when plugged in like the teaser samples show. I assume that's just not yet in the beta I tried. For now, I think I'll jump back to 2.0.3.2 lest the ptre-release break something in my game (though I didn't observe it doing so).
  22. Thanks much for the new version. I was running 1.9.1 on my Win10 box and was just about to build a mining rover using Simple Construction (and the Not So Simple Construction add-on) when I saw this notice. Did a quick update to it and I can verify that it works (still - as I noted before, the prior version was also working for me in 1.9.1). No more nagging message about incompatible versions on game launch.
  23. Ah. I hadn't thought about progress of prior worlds affecting later ones. That does explain what I was seeing. BTW, I don't find the scanning stuff to be too painful, even for multiple bodies at a planet. It's not too hard to put together one of the big scanners with 2 geologists, a mechanic, and enough snacks and rocket parts to do all the tiers in one mission. Then I send another vehicle for the next moon (or the planet) and have the crew transfer over to it. I had worked your tricks 1-3 above and that's what was being really painful. Though I wasn't using the LFOX RCS thrusters; didn't think of them. I almost always use the Meercats for bases, just because they fit so nicely. For Duna I was having to use quite a few of the meercats (8 of them if I recall correctly - 2 on each of the 4 sides). I've pretty much settled on trick 4 for now, though I use simple construction instead of the full-blown EPL.
  24. Yeah. To have VR as an option might have been sort of half plausible. Not very, but at least sort of. But VR exclusively? That's so implausible that my first thought was that someone didn't know what the word "exclusively" meant. :-)
  25. I'm a little confused (suppose I could stop at that - seems to be a problem that's increased ever since my teens when I knew everything, but I digress - back to my current confusion) about apparent skipping of tier 1 at times. For scanning, it seems consistent enough that I've gotten used to it. I recall that early on, I finished scanning at tier 0 and then sent up a tier 1 scanner only to discover that was pointless as tier 1 was also silently completed for whichever moon that was. For scanning of interplanetary destinations, I tend to just send a single one of the larger scanners and upgrade it on the spot. After doing the tier 0 scanning, I still have to upgrade twice to get to tie2 2, but I don't have to do any scanning at tier 1 between the upgrades. But today I was pleasantly surprised to find a similar thing in my surface research on Duna. After finishing the research for tier 1 production, I found that I was allowed to configure a tier 2 scrounger and corresponding tier 2 factories without ever having to specifically research tier 1 stuff on Duna. That was a pleasant contrast as getting a Duna base going has been a litany of pain for me, mostly not directly related to this mod. It was excruciatingly painful to try to land on Duna a base like the one in the tutorial. Easy enough on the airless moons, but required exquisite care in balancing to keep things under control while landing on Duna. I finally settled on landing just a minimal core with enough rocket parts to bootstrap building (using simple construction) a scrounger and rocket parts factory. That worked ...well, better... once I got past the fact that the stage separator was ripping off the adjustable base frame that I thought had fit nicely inside of it. (Prelighting the engines in the nest stage before separation seemed to help pull it out fast enough to solve that.) Then I hit some sort of input locking bug where I couldn't click on most things - even if I tested starting a brand new test career. Only solved that by installing a new copy of the game (and all the mods I'm using) and copying my save game over. Argh. Then I finally got my base core landed, but it was a bit too tall and it toppled over. Spent lots of time trying to rectify that, including an almost successful ploy of building add-ons to the side port that was now on top and using solar panel extension to lift enough to swing it all upright. That sort of worked... until I found that the gravity ease-in toppled it back over when I left and later returned focus there. Well, I could still sort of awkwardly build some basics even with the base toppled over. Sure was glad that it looks like I'll be able to skip adding tier 1 stuff to it before landing a more permanent base for tier 2 and up. Yeah. I know that was sort of a long and largely off-topic spiel. Feeling chatty from all the social isolation I guess. :-)
×
×
  • Create New...