Srpadget

Members
  • Content Count

    292
  • Joined

  • Last visited

Community Reputation

161 Excellent

About Srpadget

  • Rank
    Spacecraft Engineer

Recent Profile Visitors

1,335 profile views
  1. Hmm, is this strictly a texture-map revamp? The height maps stay exactly as they are now? Asking for those of us with permanent surface-based infrastructure and ongoing career saves. I restarted a new save -- AGAIN -- with the release of Breaking Ground in order to play with the deployable surface science. I'd like to keep this save going past the 1.8 update in the hopes that someday I will get out to Jool in a career game, but if the height maps change it'd probably end up destroying all my surface-based infrastructure.
  2. Like so many others, I'm annoyed by the nonstop deployed-science message spam. So I decided I would at least shorten the duration of it, by the simple expedient of spamming experiments. (I'll get to 100% science, and thus the end of the message-spam, in fewer game-days that way, right? Heck, at this point I'd be happy getting to 50% to fulfill the contract, so I can send out a crew with crowbars and axes to destroy the dang things...err, I mean, send out trained professionals to gracefully deactivate the experiments!) I sent a lander to my deployed-science setup, with a scientist, engineer, a couple more Go-Ob consoles, a couple more Ionographers, and another solar power array to keep them running. It didn't work. The new (duplicate) experiments refused to function, despite being close to the controller and plenty of power to operate all the hardware. I concluded that only one of each type of deployed experiment can be operating at a single location. (Either that, or I did something stupid in deploying the experiments--and I would NEVER make a boneheaded error like that! *shifty-eyes* ) What I'm not immediately clear on is whether only a single instance of each experiment can be deployed on an entire celestial body, only one per biome, only one per controller...? (If one of the latter two, I can always send out a couple more controllers and set up additional deployed-science stations at different locations.) I'm sure by now plenty of people have tried all of the various options, and I'm hoping to learn from your results. Or should I send out another controller and try setting up a separate station elsewhere on the Mun, and report back on my results?
  3. I am finally reaching the point in my 1.7.1, 1.7.2, and now 1.7.3 Breaking Ground save where I'm going to need to use KAS. Looking through recent posts, I see that KAS1.4 is good to go with KSP1.7.2. (Huzzah!) So, what's the word (if any, it's still early days) for 1.7.3? That is primarily a bug-fix update (except for propellers, which I have no immediate plans to use), so I would not EXPECT any problems. But KSP has surprised us in the past. Sure, I can fire up a sandbox save and test it myself. But I figure others have already done this, and I might as well see if there's already a consensus that 1.7.3 didn't break anything (or conversely that there are serious known issues using KAS1.4 with KSP1.7.3).
  4. Welp, more weirdness. But this time it's GOOD weirdness. I got home from work this afternoon, saw the above additional things to try, rolled up my (metaphorical) sleeves, and prepared to do battle with Steam. But Steam was telling me I had a KSP update queued. No idea why, but there it was. So I let it download/install/start. And KSP is happy as a clam, with the new/correct Breaking Ground. Not a clue what happened while I was asleep and/or at work. It seems to be working okay, too. ::shrug:: Thanks for the tips!
  5. Okay, assuming you DID mean for me to clear out the directory that KSP is installed in--Steam's Uninstall DID in fact leave some files undeleted in that directory. So I deleted all remaining files after the uninstall, and deleted the Kerbal Space Program directory itself, and yes I emptied the Recycle Bin too. Then into Steam for a reinstall, which seemed to take longer than the previous SEVERAL REINSTALLS I've done today (not that I'm annoyed, or bitter...), so I figured that was a good sign. But no joy. Exactly the same "Breaking Ground 1.1 is not compatible, you should install BG 1.2 instead" error. So I'm back at the "how can I make this MORE clean/pure/virginal?" phase of confusion/frustration/cluelessness. That, and wondering if Steam's own install script and/or supporting files are somehow hosed...except that I'm not seeing a wide-ranging hue and cry, so it MUST be just me....
  6. Sorry if I'm being a bit slow, but... I assume you mean something different than merely the installed location on my hard drive? (C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program) Is there some intermediate location where Steam stores a temp file or something?
  7. Standard background info: Win 10 running on i7-7820HK & 16GB RAM (i.e., not a potato). My KSP is through Steam. As of yesterday, I was running trouble-free. Today, KSP auto-updated. Started okay after that, but I didn't see any of the new parts in my Career save. Quit out to Windows, restarted, started a new Sandbox game, still didn't see the new parts. So, I did the obvious: went into Steam and verified local files. A couple files were corrupted, as expected. So I let Steam do its thing, and then restarted KSP. Only to find that I was borked ON STARTUP. As soon as I got to the Main Menu, I also got a couple popup messages saying that the BG expansion didn't load because of a compatibility issue: my BG was version 1.1, and version 1.2 is required. So, back to Steam. Re-verify local files. A couple are corrupted. Let them re-download, the re-verify while still in Steam just to be sure: Steam claims all is good now. Same thing happens on startup. KSP refuses to load the Breaking Ground expansion, with the same "this is V1.1 and V1.2 is required" error message as before.Com So I invoked the "nuclear option". I went into Steam, used its Uninstall utility, then did a clean install. When that was done, I immediately started KSP (no mods, no existing saves, nothing--EXACTLY as installed by Steam). On startup, KSP STILL claims I have Breaking Ground v1.1 and refuses to load it. Does "uninstall" fail to uninstall the DLC? Is there something else I need to do to nuke the Breaking Ground expansion and get a TRULY fresh/pure/virgin install? I am at my wit's end here...
  8. Where in the tech tree do the new parts appear? I just poked through everything in R&D and didn't see any of them. (Yes, I have both DLC packages.) Are these sandbox-only parts? Or is there something wrong with my install? === ETA: Nevermind, I started a sandbox save and found no new parts there either. Off to Steam to verify files and get reinstalled... === Edit 2: Well, I seem to have been well and truly borked. After 4 "verify, fix, reverify, start KSP and see problems get WORSE not better, back to Steam and find I've been re-corrupted", lather-rinse-repeat, I am now uninstalling and doing a clean re-install. Let's see what happens... === Edit 3: I only THOUGHT I was borked before. Uninstall & clean reinstall followed by immediate startup of what should be a virginally-pure brand-spanking-new copy of KSP (no mods, no existing saves from previous version, nada) and it STILL refuses to load what it claims is BG 1.1 (because KSP 1.7.3 needs BG1.2, no more, no less). Off to the Support section of the forum, I guess...
  9. But but but ... Okay, I am an engineer by profession and I think my brain just broke. Okay, then, that explains why I had concluded the sliders didn't actually do anything. Here I was, expecting that if I increased "damping" that it might, oh I dunno, "increase damping"! Crazy, right? (How do I add an 'eyeroll' to this thing...? Ah, there it is...)
  10. Heh - my 40-ton tanker truck, on a run of 100 meters or less, at about 2-3 m/sec, along level ground (as level as I could find, anyway), between my refinery and a rocket landed nearby to refill its tanks? If it EVER catches air (so to speak...!) for any reason whatsoever, I have WAY bigger problems than wheel settings...! But yeah, that's good info to spread around, for those folks who use rovers for speed runs or for long-distance exploration. YES! THAT'S IT EXACTLY! Near as I can tell from that heavy tanker's behavior, the surface of the Mun is entirely wet slush over ice! So, crank up the tanker's wheel FRICTION overall, but only moderately on the front pair of wheels, and progressively higher on each pair until friction is maxed out on the rear wheels--and then be REALLY careful to keep speeds down (though see above) when backing up (and possibly when returning empty to base). Funny thing--I actually want/intend/prefer to play Kerbal SPACE Program as, y'know, interplanetary exploration via rocketry (yeah, I know, imagine that). And yet, what I spend the most time tweaking, am generally most pleased by when it works out, and take/share the most screenies of? A mining/refining operation and associated trucking infrastructure...
  11. I'm looking for ways to improve the usability of the abysmal wheels (and landing gear, but esp wheels) that we've been stuck with since Version 1.3. And I am trying to avoid the 'fun' of endless experimentation in Sandbox mode just to rediscover what people here might already know--I don't want to waste my time 'reinventing the wheel', so to speak. So what are those PAW "override" sliders actually for? What is each of them supposed to control? For instance, what's the difference between "friction control" and "traction control"? And is there any reason I shouldn't just peg the traction, spring strength, and damper strength to their maximum values? And for that matter, do they even do anything at all? My findings from trying to adjust spring/damper settings on Mun and Minmus would seem to indicate they do absolutely nothing whatsoever... My primary issues: 1) On the Mun, larger/heavier vehicles (fuel truck massing ~40 tons fully loaded) slide sideways down modest slopes and CANNOT climb back up, even via switchbacking (where by 'modest' I mean "the most level patch of ground in the vicinity--unless I'm watching the navball indications, I have to look closely, possibly from several different camera angles, to tell that there is a slope AT ALL or which direction is downhill") 2) On Minmus, small rovers (~ 1/2 ton) bounce their suspensions in a never-ending, zero-damping spring-action. While PARKED. Upon physics load, the rover starts in a neutral position and then the suspension 'sags' (okay, that's as expected as physics kicks in) and then rebounds, sags, rebounds, sags, FOREVER. And I mean FOREVER, not just "for longer than I think it should". I mean ZERO damping, no matter how long it stays in scene or how high I set the damping slider. (Note: so far, I've just played with the settings after arrival at Minmus. Dunno if maybe the slider might actually do something if I cranked it during construction.) Bouncy-bouncy-bouncy, through the suspension's full range of motion, on and on and on and on...; it looks like one of those dancing inanimate objects from a 1920s-1930s cartoon short 3) And of course there's the whole issue with landing legs being under-damped and leading to landers going through crazy gyrations, plus the surfaces of all bodies appear to be made of grease so that any object sitting on the surface will sloooooowly sliiiiiiide down any slope no matter how slight... The second effect is annoying but kind of cute, and honestly doesn't especially impact gameplay. The third is a bit more problematic, but hasn't caused much in the way of serious problems yet (as long as I remember to record the initial coordinates of any surface bases I intend as permanent infrastructure, and periodically update my .persistent file to move the base back to where it's SUPPOSED to be before it crawls to a steeper slope...) But that first one? There's just nothing as "fun" (in the 'not at all fun' sense of the word) as watching a Jumbo tank full of LF/O just drift away down a two-degree slope and being *utterly unable* to do anything about it--even driving all 6 wheels at full "battery drain" power just changes the angle at which I drift downslope. Grrr. And I am really not looking forward to trying to set up a fuel refinery on Ike; I'm guessing that its lower-than-Mun gravity (hence presumably even lower traction/ground friction?) and scarcity of genuinely level ground will make Issue #1 worse, not better... I did a quick search in Tutorials with keywords "wheel" or "wheels" in their subjects, but didn't come up with anything useful. "Help me, Jeb-Wan Kermanobi, you're my only hope!"
  12. So, I opted to send Jeb home, and after his return (the other half of the contract) I'd Alt-F12-complete it. Mun-escape burn complete, Jeb headed back down to the bottom of Kerbin's gravity well. I still had this Mun lander in low orbit, just a few km away from the contract rescuee, right? I scooted on over there, matched velocities, rescuee jetpacked over to the rescue vessel, grabbed on and climbed on board--and BAM. The rendezvous contract parameter completed. Near as I can tell, it completed when the rescuee climbed aboard (though I can't be sure; it's not like I was staring at the upper right corner of the display at the time). (Bert from Sesame Street) "It's not fair...it's just not fair..." ::sad trombone::
  13. My current Exploration contract requires a "rendezvous" near the Mun. Now, I am a "von Braun-style infrastructure builder" by playstyle. By the time I go interplanetary, I generally have orbiting fuel depots in low Kerbin orbit, low Mun orbit, and low Minmus orbit, with reusable landers at each moon, "reusable" SSTOs shuttling from KSP to the Kerbin station, and multipurpose nuclear tugs transferring crew/cargo/etc between stations. In other words, I do LOTS of docking and I can set up and execute a rendezvous in my sleep. This contract was offered immediately upon completion of the "land on the Mun" exploration contract, while Jeb was still doing his "science, flags, and footprints" dance on the surface. And I already had a "rescue from Mun orbit" contract, so I figured I'd just stop by and taunt the poor marooned Kerbal before heading home. No joy--the contract refused to complete. I figured it was because I had left Jeb for a while to do something else, and when I came back the 2 ships were within a few hundred meters--and the contract probably looked for the moment a ship crossed the 2.5km (or whatever it is) limit for loading a craft in order to check off "in visual range". No sweat--I had plenty of dV, so I figured I'd boost apo so Jeb did one orbit while the victim...err, rescuee...went round twice, RE-rendezvous (while maintaining focus this time) and it'd complete. Again, no. Fine. Maybe the contract doesn't recognize the rescuee and derelict capsule as "my" vessel, and therefore doesn't consider it a valid target? Okay. Jeb stayed in Mun orbit while I launched a second (uncrewed) Munar lander--my plan was to rendezvous with Jeb to complete that part of the exploration contract, then pop over to rescue the Scientist in his capsule, and land on the Mun for a tasty batch of additional science. But NOOOOO... So, to recap: two separate vehicles launched on separate boosters on separate occasions. And I bumped their rocket nozzles together at a relative velocity so low the navball registered 0.0. Nada. Screenshot showing contract, ships, and navball with target velocity: https://imgur.com/u3Soyl2 (I cannot for the life of me get the darned thing to embed, so you get a link to click...) So am I missing something? If it wants me to DOCK (using a docking port), I'd think it would SAY so. (I'm pretty sure I've had "DOCK two vessels in orbit around (body)" contracts before...) Ditto if it needed to be two NEW vessels launched after accepting the contract (like the standard language called out on satellite contracts). Or is my contract just bugged?
  14. So can I assume I am not alone in the mysterious appearance of the nyan cats today? The nyan cats are intended to be a really intrusive way to show version incompatibility. Kopernicus is version-locked, and a given version of the mod ONLY works with a specific version of KSP. When Kopernicus loads, it checks for compatibility, and if it's trying to run on an incompatible version of KSP it shows the nyan cats. I have no idea why the nyan cats are showing up today when running a configuration that was demonstrably compatible yesterday with no updates in between. ================================ (Later addition follows) =============================== Ah-HA! Apparently, these are NOT the Kopernicus nyan cats. TODAY'S nyan cats are an "Easter egg"/"April Fool joke" built into Module Manager. Which for some reason activates on 22 Feb rather than (in addition to?) 1 Apr. Relevant thread over in Tech Support for Modded Installs.
  15. Okay, this is seriously weird... First, let me state that I have made ZERO CHANGES since yesterday's last completely ordinarily-functional KSP gaming session and now. (I could not possibly have, what with sleep and then office job). KSP 1.6.1.2401; Making History 1.6.1. About a dozen mods, Kopernicus among them as support for Stock Visual Enhancements. The same Kopernicus that I have been using since (presumably on or shortly after) 12 January. Today, I get the dreaded "Nyan Cats of Version Conflict". And the weirdest thing of all? I get that on TWO SEPARATE INSTALLS: both my default Steam install AND my completely separate backup install. (Though admittedly, it's been quite some time since I last actually tried starting up the backup non-Steam copy...) I don't even know where to start thinking about troubleshooting this, other than maybe move my savegames, uninstall everything, and reinstall everything from scratch. Are there any known issues that could cause spontaneous Nyan Cats where there were none before? EDIT: I should probably add that everything seems to WORK okay--I can fire up a saved game and it runs fine, including SVE's Jool rings which require Kopernicus. The issue really is just the nyan cats flying around during startup. So it appears that this is just an annoying cosmetic/aesthetic issue, not an actual game-breaking (or even in-game aesthetics-breaking) problem.