TheTranceMan

thx i can't believe i had never noticed this before now. then again, i can't think of anything that i ever sent to minmus that had large power requirements and would run out of power in the shade. i only sent a mining vehicle there to fulfill a contract; not something i would waste time with otherwise

it's not the warp. i have left the game running for at least an hour without warping and panels are still producing electricity.

mining minmus with a vehicle that i only designed to run full-bore during the day while gigantor panels were exposed to sunlight. however, at nearly midnight local on minmus, the panels are still reporting that they have full exposure and are still supplying an abundance of electricity. is this a bug?

i answered this here: http://forum.kerbalspaceprogram.com/threads/117181-Have-docking-controls-changed-Shift-throttles-up-while-in-docking-mode?p=1880227&viewfull=1#post1880227

you have to actually press the key on your keyboard when setting the flags (flight/translation/rotation) or it won't save the change to the mode flags

i had the same problem but it is fixable. start the game and immediately go into settings and select input controls and look at how the keys are bound between normal flight and translation. see those little glowing bullets? they are set to function the same no matter what mode you're in. you need to select the primary flight (WASD) and unset the translation flag (make sure you actually press the key on your keyboard or no changes will be saved) and then go down to the translation section and unset the flight and rotation flags whilst also reassigning the keys back to the way you like. i was, at first, furious at the change, but once i understood that it is a layered keybinding that depends on your flight mode, i think this setup is brilliant. it would have been nice if the devs had communicated this change because even though many here seem to regard translation as "eh, what good is it?", some of us are master-dockers who can park an orbiting dumptruck on a pinhead with our translation skills and for us, the old translation controls were not only just fine, but imperative that they used the same WASD hand position. strange to find myself so disappointed by something i consider to be a radical improvement.

out of memory crashes don't happen at less than 2.7Gb; there is something else going on. probably something really simple interfering with the way that KSP tries to assign addresses to textures as they are loaded into ram. i toned down the terrain to default and now have no problem. the pyramids are there now, whereas before, they weren't. now running comfortably with all mods at 3.3Gb, whereas before, without mods, crashing at 2.6Gb.

error.log https://paste.ee/p/l5D7z output_log https://paste.ee/p/7Jy3a

ubisoft is hardly reputable, unless the reputation you refer to is for its absurd DRM policies which punish paying customers, including starforce that bricked thousands of PC's

deorbiting a lifting stage to recoup funds, i realized that my landing site would be really close to the pyramids. i haven't been there since like .21 so i thought it would be a nice diversion to visit. just as i'm getting close (<2km), KSP suddendy crashes. no warning, no alert, no freeze, just a terminated process. the autosave gave me a save point at about 80k altitude on a fairly shallow re-entry, so i tried again. and again. and again. and again. three more times. each time, KSP crashes just as i'm getting close to where the pyramids *should* be. i cleared my mods after the 3rd crash so it was running completely stock and still got the same results. the error log shows the following: KSP.exe caused an Access Violation (0xc0000005) in module KSP.exe at 0023:011b08a3. anyone have a clue what is going on? 0.25 has otherwise been the most stable version i've experienced thus far.

sticking to the topic of the thread... i use a few mods, but even without them, the KSP 32-bit process ends up colliding with the memory cap and subsequently freezing. i've tried the 64-bit release but it's so buggy compared to the (now) very stable 32-bit that it's just not worth it until the 64-bit unity process gets cleaned up. that's clearly going to be a while. if i were able, had the skills, i would write a plugin for blizzy's toolbar that would track the memory usage of ksp and maybe give a warning when the process gets close to the cap. i would much rather save and restart than deal with the crashes and possible losses or (badly timed autosave points). right now, i use task manager but it cant be seen if running KSP full-screen.

as it stands, the IRW's mass and electricity requirements make it a completely useless part and every vessel in my library that had one instantly became un-flyable. i'm just going to edit the part.cfg file instead of redesigning all of the vessels which use it. chances are very high that any vessel requiring extra torque to be flyable still isn't going to be flyable with a measly 8 units of torque. squad shouldn't have broken that part.

if that were the case, why are my older SAS-equipped designs so nerfed? why would a part with higher torque be available sooner in the tech tree. there is no way the mass of the part has any effect on the torque it provides. do some testing and see for yourself

what is the virtue of even having the IRW in the game if its mass is higher than the IAS and has only half the torque and nearly the same electricity requirement? i recall the IRW having a higher torque value (i swear it was 20), which made them worthwhile, but now it is just a completely impractical part. tech tree aside (IRW is available one tier sooner, but no other requirements to unlock IAS next) is there some benefit that the IRW imparts that makes it worthwhile? or is this just an instance where the devs overlooked an obvious mistake in the stats?

in terms of sheer efficiency, turbojets are have, by far, the highest isp. feathering the intakes through the highest parts of the atmosphere to gain horizontal velocity is the real trick...

i took a space-plane to duna ages ago. what i experienced was that only the lowest elevations of the planet's atmosphere gave any effect, and it wasn't much. like flying on kerbin at 45km

i wouldn't bother with the rescue contracts until you have RCS tech unlocked. i'm not saying that it can't be done, but as someone learning a game with the most atrocious learning-curve of any gave in existence, learn to dock with RCS as it is meant to be done.

jean deaux is right; use the navball. in orbital view, select the kerbal as your target and create a maneuver node to get a close encounter (try for less than 1km). after you have burned to set up an encounter, switch the navball to "target" mode (click on the text above and it will cycle through surface, orbit, and target) and place your heading indicator on the green retrograde symbol. at close approach, burn to zero out your velocity relative to your target. now place your heading onto your target (pink circle) and do a small burn to start getting closer. if you are already very close (<500m) you can switch to docking and use RCS instead. you will want to switch to RCS at close range anyway. at this point, you want to get your heading, target, and prograde indicators all lined up on top of each other, and start zeroing out your velocity with RCS to reach a dead stop when you are very close to your stranded kerbalnaut. using only the navball and velocity indicators, you can maneuver your vessel to ever-so-gently kiss your kerbalnauts every time. i accepted the minmus exploration contract first thing and sent a craft on its way with an eta of like 6 days. there are still 3 days to go and during that time i have rescued 17 kerbalnauts on contracts. on most of those rescues, i have only needed to switch to the kerbal to gab the ladder as the vehicle drifts into him. getting your craft very close is what makes this contract easy. i wouldn't dream of switching to the kerbal at more than 10m out. consider the kerbalnaut rescue an essential 'trainer' in KSP. getting good at orbital rendezvous and docking opens up endless new possibilities in play and design. without it, you simply can't experience the more amazing aspects to interplanetary travel in KSP.

i had no idea that there was a mod for this. i have been in the same boat as OP, but i created my own parts by copying the part folder of an existing part (i used existing fuel tanks) and altered the mass in the the part.cfg file. these parts have persisted throughout updates since .17, still work as test ballast/weights, and i still use them

thx guys that makes sense; earlier i docked with a station in orbit (it had both SAS and RCS active) and i did not encounter any anomaly.

being adept at orbital rendezvous and docking, i typically approach my target "hot" and execute what would be described as a hard burn to match velocity at close range. when playing a rescue contract, every single time my craft approaches the stranded kerbalnaut, the SAS, RCS, and throttle all go dead; they either turn themselves off or the throttle is killed. this completely screws my rendezvous and i'm finding this behavior beyond frustrating. is this a bug, or is this just the way KSP works from now on?