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...