Srpadget

Nothing particularly exciting or photogenic today. 2 probe launches to Eeloo; one of them carrying 2 comsats with RA-100 antennas to go in high polar orbit and provide a comm link to the KSC, and the other with 3 comsats each with RA-15s for equatorial orbits to relay short-range signals out to the RA-100s. the nearly 4-year (in game) trip is going to take quite some time IRL before I finally get there, though. It's a career save and I have several other interplanetary missions in=progress or soon to launch (Comsats to Jool and a whole infrastructural fleet to Duna/Ike are in-transit now, and launching "soon" (for values of "soon" that are short compared to Eeloo transit times) are comsats to Dres and an infrastructure fleet to Eve/Gilly. (I might even send something toward Moho. So I doubt that I'll be reporting back with a meaningful post-mission debrief any time soon.

I had figured out the normal/antinormal strategy, but I had not thought of the Ctrl-Shift trick. I'll have to try that with my next comsat-constellation deployment! Thanks!

Is there some way to throttle them down? They're still too powerful for my candidate use unless they can be throttled down. My comsat network wants TINY stationkeeping motors for miniscule worlds like Minmus and Gilly. I've been using Ant engines thrust-limited all the way down to 0.5%, then using the shortest bursts of minimal throttle I can make my fingers do (one hand on the Shift key, the other on the X, and hitting them nigh-simultaneously). But even with that, I have to be clever about things like burning mostly out-of-plane to get the radial and/or prograde thrust-vector components small enough to be useful. Mind you, a network of comsats with orbits that are all 1) perfectly circular to within a meter and 2) identical to each other to within a meter? Not sure that's going to count as "impressive" to anyone except me...

No pictures, as I was away from my computer during the key moment (this becomes important later!), but today I did my first EVA-repair job that wasn't a contract. So I was doing a milk-run training mission for some rookie kerbonauts, with a Flying Dutchman transfer vehicle approaching docking with Minty Dessert station in low Minmus orbit. Ho-hum, something I've done dozens of times before... I had sound turned off and was livestreaming a virtual music festival on my other laptop (this also becomes important later). About 1 1/2 minutes from the braking burn on final approach, Real Life(tm) intruded. In the form of my cat doing his "I've got a hairball" dance. *Right over my #2 laptop which is streaming the music.* I jump up, move the cat, hold him away from the laptop until he's ... um ... taken care of business. And only then do I wonder if I remembered to hit ESC to pause the game. No, I hadn't. And OF COURSE I hadn't bothered to save before this utterly-routine operation. Well, the Dutchman was still there and wasn't an expanding debris field, so I should be okay. And Minty Dessert Station was only a few hundred meters behind me, so it was trivial to kill relative velocity and then do a manual/eyeball approach and dock. Except that at some point during docking I noticed that the Dutchman was missing a thermal wing and the Minty Dessert a solar array. OF COURSE this happened to be the time that I set up a rendezvous two orbits in advance and executed it so precisely that my uncorrected miss distance was UNDER TWO METERS. Luckily, I'd earlier stowed a few repair kits and an experienced engineer on-board the Minty Dessert "just in case". So, everything's fixed now, and a survey of both vehicles seems to indicate everything else survived the near-collision okay. (As well as both computers, and the cat!)

Oooh, that might work for me! Let me know what to do, and I'll try it out. Thanks muchly!

Pol also looks like it's got an atmosphere--though it's yellow/orange/brown rather than minty-dessert green. Looking around other vacuum worlds, I think I might see a fainter version around Ike; I definitely see the same kind of glow (albeit colored appropriate to each world) around Moho and Eeloo. Bop and Gilly, though, look like rocks surrounded by hard vacuum, as I'd expect all the no-atmosphere worlds to look. I'm guessing this is intended behavior, but it's not for me. I suspect I'll have to go back to individually installing SVE + TextureReplacer + I don't remember what-all else. Alas--I was really enjoying the idea of getting all my visual-beautification needs met via "one-stop shopping". (And your sunsets are GLORIOUS...!)

No, I installed from your download. I hardly ever use CKAN for anything these days. Thanks for the tip, apparently I'll have to install the latest CKAN and look for your lights. No, it looks from orbit like it has a deep (for Minmus anyway) minty-green visible atmosphere: https://imgur.com/CzCLP1Lhttps://imgur.com/CzCLP1L (Hoping I successfully pasted a screenshot into this... I haven't done that for a year or two and imgur appears to have changed significantly since the last time I did this...) ...several further attempts just made it worse. You'll have to click the imgur link, I guess; apologies from this old guy for my net-forum incompetence....

Manually installed Spectra with my KSP 1.11 (first time with Spectra; I've used other EVE-based visual mods in the past), and I've got 2 unexpected observations: 1) No city lights on Kerbin's night side (I assume this isn't an "issue", so much as a matter of personal preference); should there be city lights with Spectra? If not, I assume I can get the relevant files from a different EVE-based visual pack--yes? (I personally enjoy seeing the city lights from orbit, but more importantly I use the coastline of the continent east of KSC as a navigational aid when setting up a reentry burn. And that technique becomes much more challenging when that coastline is invisible.) 2) There appears to be distinct atmospheric 'sky glow' around MINMUS. (Okay, THAT is Just Wrong(tm), and definitely not merely a matter of personal preference.) This is visible in-mission, in Map View, and via the Tracking Station. Install was done manually, and I am using Scatterer. Any troubleshooting tips/fixes greatly appreciated.

What exactly is meant by "launched complete"? I see the INTENT is to prevent using EVA construction, but I pretty routinely build larger contract stations by DOCKING payloads from multiple launches (similar to how major ISS components were berthed together in real life). Is that an unusable strategy now?

First, you may want to go into settings and increase the number of conics shown in Map View. I have mine increased from the default in order to ease interplanetary trajectories involving moons of other planets. (This bit assumes you're in a low, circular, prograde orbit around Minmus) Ejection burn on the trailing-and-outboard (from Kerbin) quadrant of Minmus; fuss with the placement to get an optimum burn (either minimum time for a given dV, or minimum dV if you're more patient than I am); if I recall correctly, ~300 m/s is a decent compromise between minimal fuel usage vs reasonable travel time--but don't take taht as gospel; I haven't done it in a while and I may be remembering wrong. WARNING: if you leave the Kerbin system with too much excess velocity, it can take a surprisingly large amount of dV to get back--so don't get too impatient in regards travel time. And make sure you check that you're leaving Kerbin SOI, not just Minmus. (Yeah, it may sound insultingly obvious, but it needs to be said. Been there, done that...) As you approach the transition from Kerbin SOI to Sun SOI, add a burn to kill most of your velocity. (This step is not strictly necessary, but it makes me feel better to know that I'm just barely drifting out into interplanetary space; the dV is basically the same either way.) I like to leave my ship pointed retrograde (back toward Kerbin) for this part, as it makes the initial guesstimate of the return burn easier. Once out in interplanetary space and you've earned your "Sun SOI" merit badge, set up your return burn. This will be ROUGHLY aligned with the axis of your ship if you left it oriented as described above; relative your orbit around the Sun, it will combine prograde/retrograde and axial in/out (the exact direction depends on where Minmus was in its orbit when you left it, and hence what direction you were going relative to the Sun when you got flung out of Kerbin SOI). From here on out I can only give you arm-wavy "fiddle with this and see what happens" sorts of guidelines... You'll want to play with the prograde and axial burns until A) you have a return to near-Kerbin space, then fiddle some more until your return trajectory has a Pe a bit smaller than the Mun's orbit. You probably won't get an intercept at this point, but that's ok; you should get "closest approach" indicators--and they'll probably tell you that Mun is way over on the other side of its orbit at the critical time. Not to worry. Fiddle with the prograde & axial burn handles a bit more. One of them will change your arrival time more than it changes the trajectory; the other will do the inverse. Use that knowledge to tweak your Mun-orbit-distance arrival time such that you arrive there when the Mun is in the right place. It'll be frustratingly slow the first couple times you do it, but you learn the trick of "dragging the Mun to the right place" with practice--it's like rendezvous and dock in that way. The ideal goal is for your return trajectory to just-barely-graze the Mun's orbit (in the prograde direction!) so that you have the smallest possible capture burn when you get to Mun. Since it can take 20 days or more to get back to the inner Kerbin system on a long slow trajectory and the Mun's orbit is 4-ish days, you CAN do it. Depending on where Minmus was in its inclined orbit and how you ejected, you MIGHT come in above/below the Mun's SOI and need a plane change to get a decent intercept. The Mun has a pretty big SOI, so it's unlikely, but it might happen. Or you might want to capture into a near-equatorial orbit in order to refuel at a space station orbiting Mun--this also will need a plane change. That will happen as a separate burn, while already well on your way back into the inner Kerbin system--but you may want to set that burn up at the same time as you set up the "return to Kerbin SOI" burn. (Remember at the beginning, when I was recommending you increase the number of conics...?) This part is really similar to the midcourse correction/plane change burn on an interplanetary trajectory--there are lots of tutorials on that topic which can explain it way better than I can. It can be fussy, but you've got something working in your favor: the Mun's SOI is a Great Big Honkin' Target(tm)--if you can reliably set up a Minmus intercept from low orbit, then you can get a Mun intercept from just outside Kerbin's SOI. Just remember that you need to adjust BOTH the axial and prograde handles concurrently, and you'll be fine. And if your dV is limited, remember that a long slow trip is VASTLY more fuel efficient--you're gonna have to kill all that excess velocity once out in Sun SOI and then again at Mun capture. So unless you've got some hard time limit (need to return before an interplanetary launch window, for instance), the long slow leisurely trip is going to be lots easier on the fuel tanks. Good luck, and let us know how it works out!

Today's mission did not go exactly to plan. Landed in the Mun's East Crater, set up a Deployed Science station (controller, solar power, Goo-viewer, and one of the new deployable lamps). Turns out that the lamp on the tall stand is subject to physics, and its tripod legs are NOT wide enough to successfully deploy the lamp on even a fairly gentle slope (the lamp overbalances and falls over). Lesson learned: use the short lamps that sit on the ground in the future, unless on Minmus's flats. I was eventually able to make it work, but it took way more fussing about than I expected. It also turns out that a kerbal can't carry deployable science while wearing a jetpack. Not a big deal, but I was kinda surprised--I've always just assumed that the backpack contained the suit's air supply and life support, as well as the jetpack--so it was really weird seeing them wandering around in hard vacuum with no backpack! I also got annoyed by the "flags fall down when deployed" bug. But neither of those is really the reason I say things did not go exactly to plan. See, the landing was from an equatorial orbit, so the new science station was near the crater's north rim. And Bill claimed to have seen something weird on the crater rim during the landing, so after all the official science-y stuff was done, Jeb went off-script and decided to go check it out. (Dammit, Jeb, this is why I usually assign Val to the big "first time" missions--SHE can focus and stay on-task!) He popped back into the lander, grabbed a jetpack, and ZOOMED his way north and up the crater wall. Triumphantly "discovered" the Arch, and claimed the right to a percentage of the profits from any tourist attraction ever built there , by staking his claim on a plaque he left there next to a flag that he ... um ... laid on the ground because the flagpoles don't stick in the dust properly. That was when he checked his gauges and saw he'd used over 4 units of jetpack fuel to get there, and therefore had less than 1 unit remaining for the return trip. So...a couple hours of keeping the W key pressed while Jeb trudged more than 9km back to the ship, on foot, over rugged crater-wall terrain. And did I mention it was late afternoon East Crater time when he pulled this stunt? By the time he finally got back to the lander (jetpacked most of the last km or so with his remaining fuel, and landed on fumes--the gauge read 0.00 when he touched down; that becomes important later), it was very nearly dark (not that I care about Jeb walking in the dark, but I do care about having enough battery power for the reaction wheels at launch). And then Jeb couldn't climb the ladder properly--he got stuck at the top of the deployable ladder and couldn't transfer over to the ladder built into the Hitchhiker (Jeb says there's a bug in the "don't fall off the end of the ladder" safety catch; I maintain he was too tired after his walk, and he should have done more squats and fewer snacks). And he couldn't go with the usual Plan B in event of ladder issues, because he was all out of jetpack fuel. (I said that'd become important later!) After several attempts and with daylight fading fast, he had an idea! Bill stuck a fresh jetpack in the airlock, Jeb swapped his depleted one for the new, and with a fresh load of fuel, he could fly up to the hatch. HOORAY! The rest of the mission went uneventfully--nothing wrong with Jeb's piloting, just his judgment/impulse control. And yes, he's going to be grounded for a while. Again. Next time, Mission Rule Number One will be NO UNSCHEDULED SIDE EXCURSIONS. For all the good that's likely to do....

With all the discussion about Tourist contracts being (the greatest thing ever)/(a waste of time), nobody's really touched on that question. My standard single-launch "training run" once I've got the relevant tech & infrastructure in place is Launch to LKO -> Minmus-> Sun SOI -> Mun -> home. In my experience, it's trivial to go from Minmus to Sun SOI and pretty easy to get a good Mun intercept from just outside Kerbin SOI (regardless of the Minmus-Mun geometry when you leave Minmus--so no "launch windows" to worry about). The Mun's orbital period is short, and you can drastically change your ship's travel time from Sun SOI with a relatively small change in dV requirements. So it's not hard to set up a return trajectory that grazes the Mun's orbit on a tangent and allows a simple, low-dV capture.

That was certainly my intent--for a typical Eeloo transfer, most of the midcourse correction will be plane change. But that does not mean you necessarily have to match planes/inclinations, as bewing made explicit. Putting it on the AN/DN and matching inclinations makes the trial-and-error to get an encounter simpler/more forgiving, but as noted it's wasteful of dV. Putting it elsewhere and 'splitting the difference' (if you will) between the initial transfer-orbit plan and the target plane is generally much more efficient--but when there's a substantial plane change involved and a small destination body with a small SOI, getting the encounter gets fussier than if you've matched planes. And it's almost never a pure plane change--you will need radial/prograde components in order to make and/or fine-tune the intercept. I noted that in passing in my giant wall-o-text, but I probably should have emphasized that/been more explicit. And congrats on a successful transfer! Eeloo is challenging! (Dres would be as well, but of course nobody ever goes to Dres. )

What bewing said about splitting your burn over 2 orbits. That'll knock time off the longer, trickier burn. For the 2nd burn, I'm going to espouse heresy: Ignore what the transfer-window planner tells you for all except the day (ish) of departure. Your high-efficiency, low-thrust transfer stage will not be able to make the desired burn with sufficient precision. I've had success getting to Eeloo and Dres with the following (and my apologies in advance for the Giant Wall O' Text): 1) Set up a "dummy node" from LKO with a prograde burn that gives you an Ap at about the right distance from the Sun and an ejection from Kerbin SOI that's parallel/tangent to Kerbin's orbit. That tells you where you need your FIRST burn in order to get its Pe in the right place. (You won't get an encounter; you likely won't even get 'closest approach' markers. Don't sweat it. Just rotate map view so you're looking "down" on the whole solar system and eyeball it.) 2) Reduce the magnitude of that burn to give you the first burn that bewing mentioned. (I'd recommend setting this up for a day or two before the optimum launch day, and a dV of around 800-850 m/s; this will put you a bit late for the optimum launch window, but that shouldn't be critical--Eeloo wants precision in the trajectory burn vs trajectory planning, but it doesn't need to-the-hour precision timing for departure in my experience). Once you've made that burn, set up your transfer: 3) Repeat Step 1; this node should be ~800-850 m/s smaller (and correspondingly shorter duration) than what you had in Step 1 in order to achieve a similar trajectory. Again, you won't get an encounter; don't sweat it. 4) Drop a node onto the transfer orbit (the simpler and more reliable method is to put is on the ascending/descending node, but it's often more fuel-efficient to put it earlier. That's REALLY fussy, though, and I don't recommend it if you've got enough dV--especially for your first time). Set up a plane change to bring your intercept point up/down as needed to get closer to an encounter. Your goal here is to get a "closest approach" indicator. 5) Once you've got that, fuss with BOTH of the nodes from steps 3 and 4 (the "plane change" node will likely need some prograde/retrograde and radial components), driving the closest-approach distance ever smaller until you get an encounter,and then focus view on Eeloo and use the same technique to drive Pe smaller. (This last part should be familiar to you from fine-tuning arrivals at easier planets.) Ideally, try to achieve a collision course so as to have the most room for error later, but don't get TOO fussy about it. 6) Once those 2 burns are arranged to your satisfaction, prepare to execute the Kerbin-escape burn. In map view, get the plane-change node from Step 4 as near the "camera" as you can reasonably manage--you'll be watching it like a hawk for the last 100 m/s or so. 7) Execute the Kerbin escape. For a long-duration, low-acceleration burn like you're going to be doing, I kind of 'split the difference" between burning prograde and burning to the node: I'll burn basically prograde, offset about 10-15 degrees in the direction of the node. You'll need to adjust your pointing over time, and you'll eventually shift from burning somewhat radial-in to somewhat radial-out. 8) As you get down to the last minute or so of the burn, shift to a basic prograde burn and go to map view (if you aren't already there) where you preset your view for the plane-change burn in Step 6. Your goal is to place your actual trajectory right smack on top of the planned trajectory at that node. IGNORE WHAT THE NAVBALL SAYS ABOUT HOW MUCH BURN YOU HAVE LEFT--you want to match the TRAJECTORY, and that low-accel means you won't exactly match the dV of KSP's "instantaneous-velocity change" node planning model. Cut engines when you're as close to nailing the trajectory as you can manage--rotate ship and make a short retrograde burn if you overshoot. (I am also shameless about knocking the thrust limiter down to 0.5% for tiny final adjustments; it's cheaty, but OTOH the stock game doesn't provide any REALLY low-thrust maneuver/attitude jets, so I justify it that way.) Once you've managed that, delete the Kerbin-escape node. KSP will now lay your planned midcourse node onto your ACTUAL transfer trajectory rather than the initially-planned transfer--on a trip as long as Eeloo, there WILL be errors. That's okay. 9) In map view, focus view on your destination (Eeloo). See how close you got. If you're very lucky, you may still have an encounter. Even if you don't, you've probably at least got closest-approach markers, and should be able to adjust your midcourse burn to regain the encounter and place your Pe where you want it. 10) When it's time for your midcourse plane change, focus map view on Eeloo and watch THAT for the last 100 m/sec (-ish) of the burn, with the goal of eyeballing the last bit of the burn so you match the planned trajectory as best you can. Again, that's more important than precisely matching the planned burn time/dV. That should get you there. It's not a technique for the impatient, as there's a LOT of fussing about re-fine-tuning nodes that you've already fine-tuned once before. But Eeloo isn't MEANT to be easy. Let us know how it comes out!

I am about to take the Breaking Ground deployed science parts interplanetary for the first time. And I'm wondering about power requirements. I would rather use the cheaper solar array (OX-Stat-PD) rather than the RTG, but it's not clear to me how many I should bring. IF that game mechanic was designed properly (and I'm not sure how big an "if" that is!), the power provided should change with distance from the sun. I'd expect to have to set up roughly twice as many solar array 'units' at Duna as at Mun (for instance), and if I were setting up deployed science out at Eeloo, I'd have no real option other than an RTG. BUT...I've seen nothing indicating that this is the case. Everything I've seen in writing implies that the ONLY variables affecting the power output by the Breaking Ground deployed-science solar array are 1) Engineer level of the kerbal who deployed it, and 2) whether there's direct line of sight to the sun. Can anybody verify one way or the other? (It's one thing to experiment with it myself on the Mun, and send out a repair mission if I got it wrong the first time. It's a much bigger deal to discover I need to send additional parts to Duna...)

THIS. That's the primary (ONLY, really!) reason I use Texture Replacer -- so I can quickly and easily distinguish the different specializations via colored EVA suits. Pilots are gold, Scientists are blue, and Engineers are red--the way God and Roddenberry intended. (Tourists are green. Obviously. Think about it.) Or, failing that, I want the ability to define a suit design for each Kerbal by name and make it "sticky" so it stays the same from one mission to the next. Because I am NEVER going to remember to go into the UI and (re)set each crewmember's suit to the correct color at launch time. (Heck, I'm doing well to evict Jeb from the pilot's seat--AGAIN--and remember to load the crew I intended.)

bewing's "fix microbouncing by tweaking springs first, then damping" seems to have helped. Fussed with various settings on my (current) 'problem child'; seems that my early efforts to the get thing to STOP by maxing out the "Brakes" setting to 200 was a bad move that CAUSED a bunch of juddering/bouncing. Friction (at least on the itty-bitty Model S2 wheels for my half-ton Ore prospector) actually maxes out at 8.2, not 5--and it' was already up at 8.2. The "Spring Strength" was at a very low value--dunno if that was what I'd tuned it to during a similar but less severe set of issues back in V1.7 (seems unlikely) or if I'd messed with them earlier today (I don't think so, but I might have), but it seems to 'want' to be between 1 and 1.5 or thereabouts for 4 S2 wheels under a 1/2-ton mass in Mun gravity. So the prospector appears to be behaving itself, at least for now. Will see what happens when the same design reaches Minmus. I gave up on salvaging my old standby ISRU base (~25 tons empty, ~120 tons with all tanks full), and replaced its LT-2 landing legs with Breaking Ground robotic pistons and grip pads; that seems to have fixed its newfound (in 1.8) tendency to spin in place at ~1 complete revolution every 5 minutes or so. And since it doesn't need to MOVE after it lands, it really wants to be basically glued to the surface. (I wonder what would happen if I got rid of the pistons, and just plastered grip pads onto its bottom surface? I tried landing it directly on tankage once, back in V1.0.something...it was not pretty. Nothing exploded, but all the parts broke apart, like all its joints had been made of spun glass!) Will see what happens with the (~40 tons fully loaded, 8 TR-2L Ruggedized wheels) LF/O tanker truck, when it lands. I *started out* a bit concerned about that one, as it's been troublesome even in past versions, when other vehicles currently giving me headaches were just fine...

Apologies in advance for the more-ranty parts of this post. I'm frustrated to the breaking point, and almost ready to just give up on KSP after countless thousands of hours over the last 6(?) years... People say the hardest basic skill in KSP is rdzvs/dock. I disagree--the hardest basic skill nowadays appears to be working with wheels. (They get MORE borked, not less, each time KSP updates to a newer version of Unity. What's up with that?) I understand it is apparently possible to manually adjust the various wheel-control settings, via lengthy trial and error. But apparently the settings typically do NOT do what you'd think they do from what it says on the label...? At the moment, what I appear to need is some way to increase the friction/grip/traction (I am not a 'car guy', so those are doubtless technical terms which have very specific definitions in the automotive community but which I'm inadvertently misusing; sorry about that) between the wheels and the ground. Right now, I don't seem to be able to create a wheeled vehicle, large or small, which is capable of gripping the ground well enough to do much of anything except slide sideways across the ground (usually downhill, sometimes UPhill, sometimes I'm not sure if it's up or down because the ground appears to be locally flat and level), often with bonus spinning if I did something foolish like try to steer with SAS off. (Note that 'steering' is currently accomplished by reaction wheels, as wheel-based steering accomplishes nothing--even when the front end of the vehicle happens to be more-or-less-stably aligned with the direction of skid.) I should emphasize here that I am NOT trying to create some supercar that turns on a dime while zooming over rugged terrain at aircraft-like speeds. Repeat, NOT trying to do that. I'd be reasonably content if I could put together a small, light ( <1 ton) vehicle that could travel 5-10 meters/sec on level terrain, successfully navigate modest hills at lower speeds (even 1 or 2 m/sec), steer using wheel controls, and brake to a stop. Preferably a full stop, but at minimum with a small enough 'slide speed' to allow a save and/or change of focus to a different vehicle/scene. Added bonus would be a larger (~40 ton) vehicle capable of trundling along for ~100 meters at ~1 m/sec on reasonably flat/level ground (what passes for flat/level on the Mun--not going to ask the impossible and insist on what passes for 'level' on Ike!) and return to its starting point. And, y'know, STOP. Well enough, at least, to allow me to shift focus away from that vehicle, do something else, and come back to it later. I don't WANT to spend countless hours tinkering with wheel controls, via trial-and-error, for every single vehicle design and every celestial body (I thought I was buying Kerbal SPACE Program, not Kerbal WHEEL AND TIRE OPTIMIZATION Program, after all), but apparently that's what's required. So is there a guide somewhere that at least says what each control nominally DOES, so I have some clue how to proceed? (I do know that you can't trust the labeling on the controls...) What I know so far: Adjusting the "spring" does not change the "spring constant" that we learn about in high-school physics. It apparently invokes an "upward force" on the suspension (which I guess is kinda-sorta like a 'spring' if you don't think too hard) Adjusting the "damping" does not change the "damping constant" that we learn about in high-school physics. It apparently invokes a "downward force" on the suspension (which has NOTHING to do with 'damping' as far as I can tell) Adjusting the "traction" does not change either the static or dynamic friction of the tire/ground interface. It apparently invokes an anti-skid system akin to an automotive ABS (anti-lock braking system), with a larger numeric value driving a more-aggressive, more-sensitive reduction in power applied to the wheel. So INCREASING the "traction control" actually REDUCES the vehicle's ability to start, stop, climb, etc.--but (I would assume) primarily under more-challenging conditions, NOT low speeds on flattish ground...? No idea what the other controls actually do, but at this point I'm reasonably confident that whatever I conclude from the name of the control will be wrong Mind you, the above is what I've been TOLD. Left to my own devices, I'd come to the conclusion that those are just placebo 'controls' that actually do nothing at all... So are there ANY useful tips/pointers beyond 'try every possible setting of every possible control in every possible combination, and HOPE'? Or should I just let my frustration get the best of me, and give up wheeled vehicles as a bad idea?

Oh, cool! A vastly-simpler way to do what I kludged together myself as a solution! (Now if only I can manage to remember it later...)

Sorry, that's NOT my problem. the whole point of my first sentence was to say exactly that, and to attempt to avoid getting this answer. I'll try to figure out how to edit my original post to make that more clear.

I'm sure there's an answer to this somewhere already, but I can't find it. I recently acquired a shiny new big-screen 1440p monitor as my (Win 10) laptop's secondary screen. I want to run KSP there. I would prefer to keep the built-in monitor as the Primary monitor because Reasons. But I can't seem to find anything in Settings that admits to the existence of systems with more than one monitor. What incredibly-obvious thing am I missing...? All I've been able to find searching the forums are people trying to put map view on one monitor and external camera view on another--and that's not my problem at all. My problem is simpler/more basic: I just want the ONE instance, ONE view, on ONE screen--I just want to be able to specify THAT screen, over THERE. =============== EDIT: Oops, nevermind. I appear to have figured it out. For future reference and the edification of others: Start KSP, go to Settings->Graphics, de-select Full Screen, Apply. Drag the (now-windowed) game window to the secondary monitor, adjust resolution as needed/desired, re-select Full Screen, Apply. The game will go full-screen on the current (secondary) monitor. Quit and restart the game to verify that it restarts in full-screen mode on the secondary monitor. I have not yet shut down and restarted the computer, nor have I unplugged the external monitor, to see if it persists. I *suspect* it will be necessary to redo this each time I disconnect and then reconnect the secondary monitor, and OBVIOUSLY it will have to be redone if I play KSP on the laptop without the external/secondary monitor.

I believe (though I haven't verified explicitly) that the "hero" attribute allows a Kerbal to use a parachute even at Level 0.

I have a "standardized" ISRU base which I've been using since KSP 1.0.5 or thereabouts, and recreated from scratch every few KSP releases to keep it current with part updates or make little incremental improvements (I generally start a new save with each release that has new features I'd like to play the early game with). It's always had an inexplicable tendency to slooooowly rotate in place and drift position along an east-west axis (20-30 degrees and a few meters across game weeks/months and many unload/reload cycles), which I've always assumed was a KSP bug possibly related to accumulation of tiny state-vector errors during the aforesaid unload/reload cycles. I 'fixed' the problem by recording its state vector immediately after landing, and every now and again I'd edit the persistent file to put it back where it started. With the Unity update that borked wheels/gear (KSP 1.3, IIRC?), this sped up. Still slow, still fixable by periodic persistent file editing, but now if I focused in on the landing gear and just watched it for a while, I could SEE it drifting--to the east, usually; sometime to the west. Never north/south. Sometimes UPhill, oddly enough. But it was still slow enough that it didn't materially affect a single session. Now, my 1.8 career game has progressed to the point where I've got "collect ore and deliver to Kerbin" contracts. And while checking the newest rebuild for part clearances on the Launch Pad, I could WATCH the dang thing rotate in place over a span of a couple minutes. This thing is powered by Gigantor solar arrays oriented north-south to catch maximum sunlight, so I really don't want it rotating 90 degrees or more during a single gaming session. I know there was a Unity update for 1.8, and the last time KSP went to a new Unity version wheels and landing gear got borked. Did that happen again this time? Have other folks noticed anything similar? Or is it just me? Also, how do I share .craft files, in case anyone else wants to troubleshoot it themselves?

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.

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?