• Content Count

  • Joined

  • Last visited

Community Reputation

148 Excellent

About Srpadget

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

1,090 profile views
  1. Srpadget

    Why are probe cores so heavy?

    Stock KSP's tech is based more on EARLY (1960s-1970s) human space flight than current/future. The Space Shuttle's original (1970's era) primary computer massed ~50 lb. For reliability/redundancy reasons, there were 5 of them. That's 0.114 metric tons--a near exact match for most of the probe cores. The Saturn V's instrument ring (which was, granted, more than just a computer, and was roughly equivalent in KSP terms to a 6.5-m inline part--it could be considered an upsized RGU?) was ~2 t. And even today, space-rated computing equipment is slower and heavier than what you have at home--they have to use custom radiation-hardened chips (not just shielded cases) with larger feature sizes so that bits don't flip whenever a cosmic ray hits a transistor. I just don't see a problem with the stock probe core masses. (Especially considering Kerbal hardware is LUDICROUSLY reliable/dependable--nothing EVER malfunctions until it's physically destroyed....)
  2. Yes, I got out of the habit. I stayed with 1.2.2 for ... well, however long that's been ... until sometime after 1.5.1 dropped. And there was LOTS of advance notice re 1.6, so I was ready for that. But 1.6 seemed mostly stable--few bugs discussed, and the only one that was moderately serious had a simple-enough workaround, and ZERO discussion by staff of any kind of follow-on. So I figured there wasn't going to be anything for a few months until 1.7...and I got complacent. Silly me.
  3. I of course checked for this thread immediately AFTER Steam auto-updated me to 1.6.1. And more fool me, I had seen zero evidence that there was even going to BE a 1.6.1, so I never created a 1.6.0 backup copy. And now I do not see an option in Steam to roll back to 1.6.0--I have to either stay with the new version (can't do that with my current save until the version-locked mod Kopernicus updates) or roll back to 1.5.1 or earlier (can't do that with my current save due to use of the new parts). Is Steam going to be allowing a rollback to 1.6, or do I have to go cold turkey until Kopernicus updates?
  4. Following up: I went with the AGM option as the smallest/simplest one that would meet my needs. So I reinstalled Kopernicus (because why not?), installed AGM and its dependencies. Then I did a quick test case with the sandbox save I use to test stuff out on, fixed one craft in orbit, saved, quit, removed AGM & dependencies, restarted, and the AG that I modified worked just fine even after AGM was removed. HUZZAH! I don't have to bother with persistent.sfs forensic followed by one-part-at-a-time manual editing of dozens of solar arrays! My space program is SAVED! (Okay, perhaps that last is a wee bit of exaggeration...) Dunno yet if I'll be keeping AGM around after everything is cleaned up. But I'll certainly make note of the fact that it's a spiffy utility if/when this happens again!
  5. Hmm... I wonder if there's ANY chance I could install that, ONLY edit the existing action groups and leave them numbered-not-named, if I could then uninstall after doing so? Despite this problem being caused by a rather frivolous use of a mod, I do try to keep my "necessary" mods to a bare minimum (KAC and KAS are really the entirety of my "can't live without 'em" mods); the rest of my mods are aesthetic-only. Rationale being that if there's a glitch in a 'cosmetic' mod, I just delete it and continue on my merry way; if there's a glitch in a part/functionality mod, I'm hosed at least until it gets fixed. (This issue, of course, is a rather flagrant exception to that rationale...!)
  6. It seems the 1.6 update to Kopernicus somehow removed solar arrays from my action groups. It was quite thorough about it, too: if I focused on an existing ship with deployable solar arrays in an action group, it closed them and deleted the arrays from the action group; if I opened a ship file in the VAB, it stripped out any solar arrays from action groups. The only thing I was using Kopernicus for was to give Jool a set of rings, so the obvious first step was to delete Kopernicus. Which seems to have prevented the problem from getting WORSE, at least--ship files that I did NOT open (and re-save) in the VAB still have their action groups intact, and ships that I did NOT focus on with Kopernicus installed still have their solar arrays in their action groups. So, yay for that. But--the existing ships in flight which got corrupted appear to have had their solar arrays permanently removed from their action groups (okay, that's not surprising--the persistent file got rewritten with the ships in their new state, after all). And I'd like to fix that. My playstyle involves building a permanent infrastructure with reusable landers, space stations, ground bases, deep-space tugs, etc. So some of the corrupted vessels are assets I'd intended to keep around "forever"--and I really don't want to have to manually retract/deploy each and every array one at a time when I'm docking/aerobraking/etc. So, I expect I'll have to go in and manually re-jigger the action groups for the affected ships in the persistent file. But I have no idea what to look for or how to fix it. Anybody have any advice/pointers? ====== Edited to add: I may have spoken too soon and been overoptimistic in my summary above. It appears that the corruption occurred specifically for all instances of the shielded 1x6 arrays (but not the unshielded arrays, or the 2x3 arrays or Gigantors), and affected all such ships in flight whether I had focused on them or not. I also "fixed" and saved several ship designs in the VAB when I first noticed the problem, before I sorted out the Kopernicus connection--and now with Kopernicus uninstalled the "fixed" ships have corrupted solar arrays. (Apparently Kopernicus replaces some existing solar array code modules with its own, and this update did not do so as elegantly as one might have wished?) None of which changes the core of my question--but I don't want my mischaracterization of the issue to mislead others who may have this or similar problems.
  7. Excellent! I never would come up with that on my own! My space program is SAVED! Also good to know (it does in fact have Nvidia graphics and the associated utilities). In fact, that's my preferred solution: make the keystrokes do what the rest of the software ecosystem expects, rather than what one greedy and narcissistic utility demands/imposes on the rest of the system.
  8. I'm not sure if this should go in Gameplay Questions or Tech Support, but-- My new laptop does not seem to send the Alt-F# key combinations correctly--or at least, absolutely nothing happens in KSP if I press Alt-F5 (should be Named Save), Alt-F9 (should be Load Named Save), or Alt-F12 (Debug/Cheats). The non-ALT versions of those keys work as expected. The Alt-F5/Alt-F9 issue is really only an annoyance/inconvenience--I can get to the named save/load save dialogs by using the ESC key. But I am not aware of any method other than Alt-F12 to get to the debug/cheat window, and the cheat window is the only way I know to get temperature data added to the part-info window (useful-to-essential during SSTO reentry and for really long NERV burns). And of course, on rare occasions a contract gets glitched and I need to go in and force it. But mostly I want my temperature data. I figured I'd just remap the cheat/debug menu to some other key, but it doesn't seem to be remappable in Settings. Is there some way to remap that menu, or is there some other way to invoke it? Or alternately, is there some other method to get part temperature data that does not require I have access to the cheat menu?
  9. Well dang. This snuck up and took me by surprise. I didn't clone off a backup copy before the update dropped. Now I have to remember how to roll back to the previous version on Steam so I can keep playing in 1.5.1 for the next few days, until the inevitable game-breaking bugs are reported, the equally-inevitable emergency bugfixes are released, and 1.6.x is established to be reasonably stable. (I'd like to think I'm being needlessly pessimistic, but history is on my side here....) On the plus side, vacuum engines that actually LOOK LIKE vacuum engines! YAY! My beloved Mk 2 Lander Can getting its much-needed lightweighting, PLUS increased utility! Double-YAY! Really looking forward to 1.6.1 and updated mods!
  10. Srpadget

    Deep Space Relay Networks

    I go with 3 equatorial relays (typically using RA2s) spaced ~120° apart around a planet and each of its moons for ground coverage, and 2 long-range (RA15 or RA100 depending on the planet) ~180° degrees apart in high polar orbit. It seems to work plenty well enough (actually it's generally overkill). It's not a really big effort--typically I do that using 1 launch with 2 long-range relays and another that packs 6 of the smaller relays into a single fairing (planet plus 1 moon). Certainly seems less hassle to me than that constellation of 18 to 42 solar-orbiting relays.
  11. Srpadget

    What did you do in KSP today?

    It was bound to happen sooner or later, I suppose. The last few meters in Yet Another Launch Vehicle Docking With Space Station. Crabbed in a bit sideways, so had some lateral velocity to kill once I was aligned; no big deal. Reach for monoprop controls when almost-aligned so as to ease the lateral to zero, and I brushed another key with the side of my hand. The Z key. Oops. Full-throttle acceleration right at the space station. Which rang like the proverbial bell upon collision. Luckily, I'd put some rather severe throttle limiting on the launcher's main engine once in orbit, so the actual collision happened at maybe 2 m/sec, and at a slight angle so it was a glancing blow. The launcher even managed to "thread the needle" during the collision such that none of the really fragile bits (solar arrays, TCS panels) hit anything--and I have NO IDEA how that happened, as the core station plus a couple other docked vehicles made it a veritable forest of fragile arrays. It looks as though every part is completely intact. Freakishly good luck, that. (Other than, y'know, the whole "slamming the throttle when only a few meters away from docking" bit which started it all!) So in the end, all I had to do was stop the runaway SSTO, swing back around, re-orient everything (the station didn't break, but oh boy did it tumble), and do the docking RIGHT this time. No pictures of the exciting bits. Sorry about that--I was too busy a) panicking, b) stopping the runaway, c) checking the timestamp of my most recent quicksave (TWO DAYS ago...!?), d) looking for damage, and e) making a PAINFULLY CAREFUL (re-)rendezvous and dock, to even think about screencaps.
  12. I actually posted 2 separate messages. While I was composing the first (which ended at the bit about "Real Life", Gargamel wrote and posted his suggestion. When I was done with mine, I was able to see his suggestion; I still had a couple minutes before I really HAD to go offline, so I gave it a quick test, it worked, and I came back to write a SEPARATE REPLY to that effect. But either I did something odd and inadvertently appended it to my previous reply, or the forum software decided that two consecutive replies from the same person really should be concatenated into a single entry. At any rate, there really was a short period in which that last part didn't exist.
  13. Oh, I totally agree that the best answer is to clear out the useless bloatware. But not ALL of the preinstalled stuff really qualifies as "USELESS bloatware". Some of it is useful (I do rather want at least one app that will let me change the keyboard backlighting away from the default garish rainbow, for instance). And I don't know what among the ocean-o-bloat are actually useful-behind-the-scenes utilities, nor which of them is/are responsible for this annoying behavior. I've made inquiries on MSI-specific sites, but so far to no avail. Lots of "reads", but no "replies". I'll try to find out (most likely via experimentation, as MSi support is nigh-nonexistent even by gamer-hardware standards) if some additional keypress is needed. But I am not optimistic, as the regular Fn keys work as expected--it's just the Alt-Fn keypresses that don't work. (Gotta go deal with Real Life at the moment, so it may be a while....) That did it! Ctrl-Alt-F12 just got me the Debug menu! So I now have a workaround, PLUS a narrowed-down list of potential culprits! Thanks ever so much! (Now to find out if the NVIDIA app responsible is one of the useful-to-essential ones, or something pointless and stupid....)
  14. The subject pretty much sums it up. I just got new hardware (a high-end, for me anyway, gaming laptop from MSI) and I am currently unable to access any of the Alt-Fn commands in KSP. Near as I can tell, some app in the vast array of software preinstalled by MSI is intercepting all the Alt-Fn keypresses for its own purposes and they never get to KSP. Now, this is mostly just an annoyance because the only Alt-Fn commands I typically use are Alt-F5 (named save) and Alt-F9 (load named save)--and I can get at those commands via the Esc menu. But sometimes I really want to get at the Alt-F12 cheat/debug menu--that's the only way I know to get detailed thermal data to display, in particular. And IME KSP isn't completely bug-free (OMG say it isn't so!), so on occasion I may need to get at other parts of the Alt-F12 functionality (forex, my stupidly-complex mission profiles sometimes seem to confuse "Exploration" contracts which include a "...and return to Kerbin" clause and I have to force them to complete after I get back). I don't see any way to remap those functions in KSP, and so far my queries about the MSI side of things have gone unanswered. So is there ANY way to get at the debug menu without using Alt-F12? Or at bare minimum, some other way to get temperature data in part-specific right-click popups?
  15. But WHICH clock speed is of primary relevance for predicting KSP performance? Base speed, or Turbo? I'll toss in the relevant numbers here, so it's easier to see what I'm talking about: i7-7700HQ: Base freq: 2.8GHz i7-8750H: Base freq: 2.2GHz So if it's running at the base rated speed, the older-tech 7700HQ is obviously faster in single-threaded operation. This looks like a no-brainer for my purposes, as KSP is (oversimplification alert!) basically a single-thread hog and won't/can't take advantage of the 8750H's two additional cores. But wait--that's not the whole story! In the new chips, Intel put the Turbo settings on Turbo, so to speak: i7-7700HQ, single-core Turbo: 3.8GHz i7-8750H: single-core Turbo: 4.2GHz So if the chip can STAY in Turbo mode for long periods, then the 8750H will be pretty substantially faster and give better performance with KSP. and THAT is the Core (as it were) of my dilemma.... ========= ETA: Well dang. Weird formatting glitch in this post, and I can't figure out how to fix it with my phone's lobotomized browser interface. Sorry about that...