RidiculousRichard

Thanks for the fast replies; this is something for me to bear in mind to make sure the batteries are fully charged well in advance of a night-time excursion Thanks, Richard

Many times the entertainment!

Hello, I've just managed to get to the Sci Lab in my first career game and noticed something that I initially thought was odd when using time acceleration and focussed on another vessel. It appears to me that vessel battery charge is not simulated while I am piloting another craft using time acceleration (which is most of time allowing for the acceleration). After I thought about it I've concluded that perhaps this is a deliberate optimisation to avoid slowing the engine down. Am I correct about this effect? It may be a bit of a bore to have to sit there watching a huge battery slowly charge up (for long night locations) if I notice that it's low; is there a mod that improves this otherwise unexpected behaviour? The next thing that occurred to me was to wonder about researching in the sci lab. I think it continues regardless which is convenient. Am I right about this or have I simply not been paying enough attention to the research level? Does this sort of behaviour impact anything else of importance? Thanks for your help, Richard

Download link updated to http://s000.tinyupload.com/?file_id=71057878838376790157 I've concluded that filedropper.com is a scam to try and get you to pay for their 'PRO' version (I should have twigged when pasting the link; it could never be as nice as that. They put some effort in mind as the download works when you try it shortly after uploading)

I'll check the download and fix it tonight From memory all that I have on such pods are: Mk 1 capsule Clipped Octobody thing (for rescue / kerbal football) Small battery Mk16 parachute I may have: 2 basic solar cells 2 radial parachutes (paranoia backup)

I've only played the demo and 1.0.2 so I'm not sure what the changes were that caused a fuss. For light-weight landers using a capsule base has been very reliable. Batteries on the side of a vessel are most likely to overheat. The mk16 problem above only happens at the moment of touch-down; they function properly during the terminal descent. As you say, opening them in a fireball is not a good idea. Regards, Richard

An update for anyone who comes across this: 1) It is not clear if there is any heating rate dependence on the altitude at which re-entry effects are shown (36km vs 86km) but I believe that there is although it is not too severe and should be a cause of concern (I can't get a 36km re-entry effects to make an absolutely unbiased comparison) 2) So far the only component that explodes due to overheating as soon as a re-entry vessel touches down is the Mk16 parachute (but I'm only in the early career game); you are simply denied the recovery refund on the parachute 3) Pilot prograde / retrograde can be erratic; don't leave a vessel unattended in these modes. I've not had any problems with using basic stability which so far has always been fine. 4) Always keep a pristine zipped up copy of any KSP version; I'm not that trusting in it's consistency over time Please do comment if you have any reason to suspect any of these observations may be untrue

KSP: 1.0.2.842 32 bit on windows 7 HP 64 bit build id = 00842 2015.05.01 at 21:02:12 CEST Branch: master Problem: Consistent increased re-entry effects, mk16 parachute explodes on landing and pilot orientation hold suffers high frequency oscillations and moves away from the selected orientation Mods: Precision node Kerbal alarm clock Reproduction steps from save file: 1) Jettison upper stage 2) Use Jeb's piloting skills to hold prograde or retrograde; restore orientation hold before entering the atmosphere 3) Allow the command pod to perform re-entry (it is already on a re-entry course) 4) Deploy parachute ~2km above terrain Log file and save file obtainable at http://s000.tinyupload.com/?file_id=71057878838376790157 Reproduction effects without save file: 1) Build a rocket with a mk1 capsule and mk16 parachute re-entry vehicle 2) Launch into orbit and get into a 80km x 30km re-entry sub-orbital trajectory 3) Use piloted prograde or retrograde hold to see bizzare behaviour 4) Watch re-entry using SAS in orientation mode 5) Deploy parachute ~2km above terrain Update: The re-entry and parachute behaviour is occurring for all games (new and existing) on my KSP 1.0.2 install Hello, Within the last week a strange thing started to consistently happen while playing my first KSP game (Career mode Medium difficulty) running v1.0.2.842 I installed Precision node and Kerbal alarm clock fairly quickly after getting the game and they are the only mods I have ever used. The game has been functioning normally with those mods for about two weeks with Kerbin moon return missions * At the current time putting a single mk1 capsule with a mk16 parachute into a 80km x 30km sub orbital trajectory will cause re-entry effects to start between 65km and 68km at ~2.3km/s. Previously these effects only started at ~36km * At the current time the mk16 parachute will explode due to overheating on touchdown despite functioning normally during the final descent. Previously this did not occur. * At the current time using the prograde or retrograde hold provided by a pilot results in the craft pointing vector oscillating rapidly and steady drift away from the appropriate orientation. I have never really used this much before but don't remember noticing this obvious problem; Basic SAS works fine I did have a self inflicted physics oops as discussed in http://forum.kerbalspaceprogram.com/threads/123867-What-are-the-default-physics-settings but that was rectified by following the suggestion. The physics.cfg is normal (I have checked that the file contents have not changed since) I have not upgraded to 1.0.4 (title screen still shows 1.0.2.842) and have not upgraded the two mods to avoid incompatabilities. I obtained KSP via steam and have copied the entire directory off to another location to stop it being messed with and I start KSP via a link to the copied KSP.exe rather than via Steam (32 bit on Windows 7 home premium 64 bit). I have not knowingly experienced any of the bugs that the 1.0.4 change log suggests are fixed in that revision. I have not experienced any of the self help issues I am concerned that my returning 1st interplanetary mission is going to run into some kind of difficulty (unusual re-entry effects and things exploding are not a good sign when your rapidly approaching kerbals are depending on a predictable aero braking manoeuvre). Is there a known recommendation to restore the 'normal' previous behaviour (or was that itself the bug)? Is my only hope to abandon my KSP 1.0.2 game and start a brand new game from the beginning with 1.0.4? (loosing all game progress is not a desirable outcome) I could obtain and post some screen shots showing the new behaviour if that is likely to assist. Reporting information and save game at the top of this post For those that fixate on such things I am deliberately still playing KSP 1.0.2 with my sole existing game to avoid any possibility of the changes from breaking / penalising my in-progress game as a result of the game rule changes. The next game played would be a hard difficulty career game and would be played with the latest release at that time once I've finished the current difficulty; I'm am not a fan of rapid feature updates (as opposed to rapid bug fixes and occasional feature expansion updates) and consequently I don't buy pre-release games but each to their own. Thank you for any suggestions you might have, the lives of several kerbals are on the line (and the accident investigation boards are getting tired of "oops" as the cause of death), Richard

That's useful information; I wonder if people have been caught out by that

Thanks, I'll give that a go when I can Richard

Thanks for the replies; I'll check on Sunday when I get home what is happening. Is there a copy of the 1.0.2 physics.cfg that people can download to repair an installation (without nuking it and reinstalling?)

The reason I am asking this is that I was experimenting in sandbox mode and so I was just playing around and discovered the Alt-F12 menu. After briefly experimenting with the settings and making some entertaining explosions, I went back to my career game and discovered that it is now messed up with the nonsense settings. I would like to reset them to their normal defaults so I can play properly. Can anyone tell me what the unmodified settings should be for v1.0.2.842 (a reset to default button would have been very useful; I don't trust the limited information I can find with a web search) Thank you for the help, Richard

Thank you for the replies. They saved me a great deal of time trying (and failing) to utilise them!

Are Lagrange points usable in KSP? I.e. is the physics model good enough to include them and can you practically find and utilise them with the stock instrumentation?

Arrrg, I may need to start a local Kerbal Anonymous; must stop playing now ..... noooo can't resist one more contract!

Thank you all for your tips; they are making my entry to the game more manageable Richard

For those interested in this or similar question I found the following delta-v diagram at http://wiki.kerbalspaceprogram.com/images/7/73/KerbinDeltaVMap.png which is used in http://wiki.kerbalspaceprogram.com/wiki/Cheat_sheet andwhich suggests it takes ~4550m/s delta-v to launch to a 80km circular orbit. The rocket above has a full weight of 13.7 and a dry weight of 3.7. If you assume an Isp of 345 over the full flight this gives the rocket above a maximum delta-v of 4426m/s which is just enough to get to a 70km altitude. NB: the difference between a 70km and 80km orbit is only a 17m/s delta-v if I've plugged the numbers into https://en.wikipedia.org/wiki/Hohmann_transfer_orbit#Calculation correctly (600km planet radius & u=3.53x10^12) I suspect the Isp should be higher since the rocket climbs out of the densest part of the atmosphere quickly (max Isp of 370 gives delta-v capability of 4747m/s) which means there is room for improvement on my launch piloting. Despite my Isp suspicions I am at least now happy that I've not got piloting totally wrong.

Hello everyone, I recently became aware that KSP has reached release so I though I'd check out the demo and look up a couple guides to get me started. My impressions are that KSP is a mixture of an open ended building game (which doesn't appeal to me too much) and a skill challenge game which is more interesting to me but has limited replay value. I've enjoyed the demo but I've found fairly few challenges (orbited Kerbin / Mun / Sun and returned safely with the last things I can see to do is to be able to land under power and doing so at a predetermined location both powered and unpowered) and wanted to make sure I'm not making unjust assumptions about the main game. Some youtube reviews make it look like there were plenty of variations on several times the possibilities in the demo but I'm currently umm'ing and arr'ing about it (space planes looked really fun). To make sure I've got a fair understanding of the required game piloting skill could someone tell me if the following minimal orbiter performance is anything close to what a skilled player can achieve. This is the best I can reliably currently do and I am trying to use it to determine if there is a large amount of piloting skill development that I will be able to grapple with in the full game. KSP demo (v0.18 I think) Minimal Orbiter Single stack: Mk16 Parachute Command Pod Mk1 TR-18A Stack Decoupler FL-T400 Fuel Tank FL-T800 Fuel Tank FL-T800 Fuel Tank LV-T45 Engine Ascent Profile Ascend at full throttle Immediately ascend at 85 degrees At 7km alt ascend at 70 degrees Align thrust vector with velocity vector when <70 degrees during rest of ascent Cut thrust when apoapsis reaches 70km altitude Ride apoapsis initially at T-20s to enter >70km orbit Remaining fuel in established circular orbit 15 +/- 4 Based on this (very limited) test how far am I from the launch piloting skill required for the challenge (career???) mode of the game? My sincere thanks for you help, Richard