rodion

NEAR hits the spot for me where FAR couldn't. Still throws out the treacle atmospheres and laughable drag calculations of the stock game a la FAR without making me feel like i'm at JPL when i'm just trying to play a game and tinker with new designs. Rockets mostly take care of themselves, it penalizes you for not watching your thrust/vector offset in flight and trying to re-enter and soft-land unrealistic lumps of space hardware is more dangerous than in stock, which are good checks on the more silly and forgiving aspects of the stock game for me.

I did have a rocket start to flex alarmingly about its midsection recently and i must say it was bizarrely nostalgic...but, nah, let's look forward to more sane kerbal physics and not back.

i haven't personally used FAR for a while but i've heard that it doesn't play too nicely with PF. usually even with the more unwieldly shapes of rocket putting control surfaces at the bottom is enough to easily maintain control authority in the atmosphere. maybe try launching with an alternate set of fairings (KW's are nice, though obviously more limited than PF) and see if that's the issue.

indeed this is an incredibly finely detailed image, especially from a target 450 ly away...modern telescopy blows my expectations away sometimes. it's incredible to be able to image such a process in the raw "as it happens" in such detail rather than as models and simulations.

it's awesome that this actually happened to several people, it would really make my game feel alive if such an event happened to randomly happen to me. highly interesting.

more of a meta-failure outside the kerbal universe, but due to some shoddy modding i finally broke my gamedata (it was bound to happen) and had to tediously rebuild it one piece at a time until it was stable again. spent about 2 and a half hours. my other idiot moment is that whilst designing my mun base i tried to account for many things, but failed to remember that a kerbolar day on the mun is something like 20 hours, which TACLS takes exception to. even though my laboratory module has giant battery banks and currently supports only one kerbal, it can only barely scrape through a munar night without suffering a power failure. fortunately the next module with supplementary KAS boxes full of RTGs and fuel cells will be on its way shortly. power management, it's no joke.

i can think of two ways to help alleviate this problem: one is by running the very useful TAC Fuel Balancer mod to make sure that all tanks (and by extension engines) have an equal share of the resources in the craft, the other is using the tweakables menus in the SPH to change the fuel/oxidizer balance in the tanks to represent your best guess as to what the flight profile demands (with a SABRE/RAPIER that usually just means 10% or so less oxidizer, if i recall), so you don't end up with any excess resources left over in your tanks.

i think that'd be awesome.

hi, i've been enjoying this mod a lot but i've been looking to fix myself a better ScaleExponents config to resolve the often nonsensical results that the current price scaling behaviour brings: for instance, on one hand if i want to use a simple radial attachment point to cover a 1.25m section it costs 1,250 funds, but if i want to use the part to do the same on a 2.5m section it now costs 11,000 (!). on the other hand certain configs that are clearly very powerful (like a 0.625 NERVA on a probe assembly) are made ridiculously cheap to a basically game-breaking degree. currently i have !dryCost = 0 in order to neutralize both these behaviours, but the the situation closer to real-life (as i reckon it) is that scaling existing technologies up and down both entail more expense as they require a greater degree of engineering technique, fabrication, materials science etc. so my question is, is there a way to implement such a thing in the mod cfg as-is - a custom exponent tweak that makes the values increase to a set degree both when you scale an object down and up? i haven't thought of one yet but i haven't slept well so i can't really sit down to a scribble pad yet until i feel sharper.

that cabin is rather well-modeled and textured, actually...in fact i think it's the main thing that tips it off as being a fake easter egg, as almost all of the squad ones basically look terrible.

this thread also makes me wish i kept my old screenshots - i deleted them twice, i believe; once migrating from the original non-steam version and deleting the spare game files left on my HDD (remember having to go to the site and log in every time an update was released because the patcher didn't work and having the servers overload so you couldn't get it? that's some nostalgia for you...) , and another time when i deleted my KSP dropbox archive when i thought it wasn't interesting any more - "when will i ever need this old junk again?" well, now i know the answer to that question.

this is awesome, i wish i had access to this in the days of yore when i was often wrecking various builds for lack of a way to do this by hand in an orderly fashion.

in my opinion the moon (hard not to write mun, sometimes...) is the ultimate sandbox for working out the details of how to support medium-long-term human habitation on a fairly remote and hostile solar system body - testing life support and recycling facilities, deploying living space modules, engaging in the "basic" (read: complex) maintenance required to keep a base working, deploying and utilizing full-size laboratories, etc., but with the handy corollary of being close enough to earth that it's possible to launch routine supply missions or an emergency abort in a relatively short-notice and practical way. i see it as a logical step up from the grand experiment of the ISS, which has been and continues to be a fantastic platform for learning how to keep a crew of people healthy and happy over long periods in space, but as it's only in low orbit it's not exactly huge leap from earth-boundedness. if anyone's half-serious about launching manned missions to mars i think the learning experience of conquering the moon is a very necessary step towards that goal.

One of the cool things about FAR and NEAR is that is gets rid of the "soupy" exaggerated air density at low altitudes that come with the stock game, so you can accelerate your vehicles a lot more easily from sea level. of course, the other side of that coin is that you can no longer rely on the magic "cushion" of air to catch your re-entering vehicles and slow them down to ~100 m/s as in stock. anyway, tonight i finalized several designs for an upcoming Munbase (3 down, 4 to go, it's 10x as much effort as i originally planned), including a new rover: i'm particularly happy with the rover since in the past the great majority of my rover designs have been characterized by questionable COMs, improptu aerobatics, "what just exploded?", etc. but this one for once actually just worked great more or less from the start; it's stable, it's fast, it can be delivered easily with a simple sky-crane, it's well-equipped with various gizmos, it's TAC- and KAS-compliant, and just generally works well. hopefully it will show up in more places than just the Mun at a later date.

this is extremely awesome, a few years (feels far longer) after the shuttle retirement it's great to finally see a new piece of manned spaceflight technology from NASA get rolled out in an actual assembled, flying-fit form. hoping it meets and exceeds all design expectations this coming december.

indeed they are amusingly overpowered. out of 2.6m funds sitting in my account at present i think 2.1m came from a couple of Kerbodyne contracts...no doubt it's a condition that won't last forever.

haven't tried this mod yet (definitely planning to add it to my 0.90 game), but i just want to congratulate the developer for implementing a whole new KSP gameplay paradigm - "Unrapid Planned Assembly".

absolutely fantastic mod, just what i needed to develop my hardcore mode save without tediously duping craft files and working everything out in sandbox mode. the loading times are pretty long compared to other KSP scene switches and not being able to switch to nearby in-scene objects is limiting sometimes but there's so much functionality and convenience in this mod, it's just great.

just spent 3 hours or so fixing an insidious problem separating strap-on boosters on medium lifter - after numerous tweaks and redesigns realized that the sep. motors were causing the mainsail to overheat and explode, but only if it was at 80%+ throttle. Tried tweaking the thrust limiters and moving both the motors and then the strap-on boosters away from the engine as far as possible but couldn't get it so that the boosters separated cleanly without rotation + hitting things. Finally fixed it so the mainsail is action grouped and is manually disabled for a split second before separation - it's a brittle solution and I don't like it because if i forget to do it my whole payload, vehicle, crew falls in the ocean and gets obliterated, but since the launch vehicle is otherwise capable (tall, oversized, heavy payloads, handles well) I think i'll just live with it temporarily. Probably the longest I've ever spent on a single-issue build problem in KSP, also most design defects i caught on one mission build before launching it (11).

Get a real GPU, dummy.

This basically explains itself, but here's the verbose version: If I'm in a fullscreen game session and at the KSC overview, to exit the game i have to click the Menu icon (else: Esc), then I have to click Quit to Menu, then I have to wait for the text animation on the Start Game screen to execute, then I have to click Back again to return to the home menu, then I have to wait for another set of animations to execute, then I have to press Quit, and then finally I have to answer a prompt asking me if I really want to quit. [Hint: yes.] This is all just to get back to my own desktop. Proposed amendment: KSC Menu --> Quit to Desktop [Optional: confirmation prompt] I know this is a small annoyance but I think most people will agree that in the long run it's the small warts that be most frustrating and unaesthetic of all at times, if you have to live with them long enough.

BLARGH! A bizarre glitch killed my whole Minmus expedition. Cause of death: instrumentation failure: Somehow, at some point during the return leg from Minmus, Squad, Flight Engineer and RealChutes all decided to totally disagree on where sea level even was on Kerbin. Atmospheric entry at first went normally but on final descent while I was avidly monitoring FE's radar altimeter display (which I always considered to be a rock-solid bastion of accuracy) I totally failed to notice that the stock altimeter was quietly indicating to me that the water was actually almost 1km closer in reality than suggested. Given a stock game I would normally just eyeball the water for safety, but Planetshine drastically reduces the amount of ambient night light back down to realistic levels so it was strictly instruments-only. If the parachute deployment logic was unaffected I wouldn't have minded, but RC was confused and didn't even start main deployment (700m) before splashdown...if I had just noticed three or four seconds sooner I could easily have throttled up and killed the excess 200 m/s and saved my ship and crew. What's worst of all is that this is all early-game and I seriously needed the science return to advance through the vital parts of the tech tree...samples, goo and thermometers that I carefully collected and were obliterated totaled 930 science, a whole bunch of nodes for me. I'm not even mad...I'm just disappointed.

hi, it's been a long time since i've used PF in any form, so could anyone explain to me how buy-in works (or doesn't work) in career right now? i started a new game lately for 0.25, hit a few basic nodes before installing PF and the problem i'm running into is that if i go into the tech "flight control" node and buy into the 1.25m PF parts and fairing walls (well, activate, since it's 0 funds) in the tech tree, go back to the VAB/SPH, and go to use the parts, the walls show up as still requiring their entry purchase although i clearly did that, and the fairing bases don't allow any tweaking to 1.25m either. also tried with the deprecated parts folder removed but it's clearly stuck this way. slightly clearer diagram:

doy, guess i really should have checked for that in the first place . stock and mod interiors working as expected again, thank you guys.

now i'm puzzled...RPM cockpits have vanished into smoke on my game, all squad internals are back to stock appearance and behavior. i'm assuming this happened somewhere between 24.0 and 24.2 because initially everything was working normally. i updated to the RPM 0.18.1 hotfix but nothing happened, is there some sort of conflict i may be encountering with other mods that i'm unaware of?