Drew Kerman

ok the game is nuking the FF save file when the game crashes. So that's my fault. There's a memory leak somewhere and I'm too lazy to track it down so I just keep an eye on the VAS usage, quicksave when it gets too high and let the game crash after a while. In regards to the saves, check out this: http://forum.kerbalspaceprogram.com/threads/71883-Plugin-Persistent-file-backup-generator His mod auto-saves only when you load the game save file. Don't know if it's the same thing tho for your mod

much obliged. I will give this a go next time I need to re-enter. Setting up a comm network right now before launching another kerbed orbital mission

my HallOfFame file got wiped out (0 bytes) twice so far since the new version. I have not yet been able to determine why. Thankfully I added my game save folder to my external backup program... speaking of backups I noticed they happen every time the game is loaded, Space Center is loaded, and game is exited. This is overdoing it way too much. I can overwrite 3-5 backup files in a single session easily. It should backup once per session either on load or on exit (of that particular game save)

posted the radial overheating issue over on the DREC thread and the suggestion was that there may be an improper transform used for the part. Don't know if there's anything that can be done about that though. I might just edit the part to withstand 5000C heat. It *should* have worked just fine the way I used it right?

I'll hop back over to the RealChute thread then. The radials for RC were prob based off the default radials that had the bad transform in it. Hopefully the RC author can change that. Not even close.

ppjoy. It's not supported on Win7 and there's a convoluted way to install it if you really really want to - I'm not that desperate when my X52 works just fine, and in some ways better

Yes, all chutes were undeployed. I even tried a re-entry without arming the chutes prior as I normally do in case that was causing something. So I finally gave up on the radials and decided to just try a test with the nose cone chute. This was totally unintentional the way I ended up re-entering the atmosphere (RemoteTech2 was enabled and I couldn't set myself up for re-entry). Still, the results were surprising. www.youtube.com/watch?v=UmI5N8AAuis Crap, didn't realize I resized the video to 640x480 when I clipped it down to just this section. Anyways, max temp for the nose cone chute was 760C The speed of this re-entry was pretty slow, I will grant that. Other tests I did ended up around 2-2.5km/s with the radials. I also still don't understand how every other part on the capsule can max out at around 300C and the radials flare up past 1000C.

I completely understand and agree, which is why I am confused about my radials going kablooie Anyways, thanks for looking into it

Here is the capsule as configured for re-entry. Capsule re-entered hatch-up on like a 35 degree angle, so the radials were to either side as the capsule dropped through the atmosphere. (nose was reserved for an escape tower, hence no nose cone chute) Here are the two examples I saw while watching Scott Manley KISQ: I've had similar results as well with trying to return a science module - it's hard to see in this image but the radials are above the Goo Containers attached to the Science Jr. Heat shield is under the nose cone - so nothing was directly blocking the radials from heat but I was hoping they'd be high enough up. Both burned right off just like Scott's: Again my main concern here, and the reason I think this is an issue, is the extreme temperature discrepancy. It's not like the parts that survived had a higher heat tolerance. No, every other part on the capsule didn't even come close to overheating. Even the nose cone chute never exceeds around 300C

The following mission report comes from the public relations account of the Kerbal Space Agency, detailing the fifth mission - a repeat flight (Flight 3) of Kerbal III commanded by a third astronaut, Bob Kerman. We're hoping for an even higher apogee to this flight to confirm that we have a more solid understanding required for orbital rocket design. These are only the tweets related directly to the mission on launch day. For more reports on the status of the KSA between missions, tune in to @KSA_MissionCtrl. Previous Mission Reports Mission001: Rocket Test Mission002: Recovery Test Mission003: Chimps are for Wimps - F1 Mission004: Chimps are for Wimps - F2 Catch up on what happened next over at @KSA_MissionCtrl!

has there been any discussion regarding the radial chutes exploding during re-entry? It happened to me when I placed them high atop a Mk1 capsule - I monitored their temperature and they got overheated to 1000+C while batteries lower along the side never topped 270C and the capsule itself only hit like 405C. In fact by the time the re-entry heat effect started the radials were already upwards of 600C! I saw the same thing happen to Scott Manley in his Interstellar Quest videos. At first I thought this was something to do with incompatibility between DREC and the RealChute radials I was using, until I realized Manley was using the stock radials. Nose cone chute works fine atop the Mk1 capsule, and I did successfully use radials but I did so by placing them on the flat top of an 2.5m AIES probe body - kinda kills the point of radials if you need to stick them on top of things for them to survive re-entry...

I've had my remote backups doing this for me but this way is even better. Thanks!

Hrm, unless someone can verify I'll need to test this. I can understand not modeling detailed physics but resources consumption shouldn't be a heavy processing task to undertake for any ongoing missions, especially when the entire ship data is loaded regardless of whether you actually load into that ship or not through the tracking station

N/M, I was new to the FF mod and hadn't looked closely at the detail window to see that they do track day/times of events - and also I think I misinterpreted the feature you had planned

It's like a question in how I should do this for a good balance of realism and gameplay I haven't done any far-flung missions yet but you're saying that a probe that's drifting off into interstellar space, if I don't load it until like a year after it launches it will have the same power level as when I last loaded it a year ago?

I've deleted and redownloaded the Kethane pack and still get this popping up in my KSP.log file: [LOG 02:01:06.337] Load(Assembly): Kethane/Plugins/MMI_Kethane [LOG 02:01:06.337] AssemblyLoader: Loading assembly at D:\Steam Games\SteamApps\common\Kerbal Space Program\GameData\Kethane\Plugins\MMI_Kethane.dll [ERR 02:01:06.337] Failed to load assembly D:\Steam Games\SteamApps\common\Kerbal Space Program\GameData\Kethane\Plugins\MMI_Kethane.dll: System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid. at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0 at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0 at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0 at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 I can't really attribute any instability to this, just pointing it out. There is also this: [LOG 02:03:24.733] Load(Model): Kethane/Parts/kethane_radialDrill/model [ERR 02:03:24.742] Texture 'Kethane/Parts/kethane_radialDrill/model000' not found! [ERR 02:03:24.742] Texture 'Kethane/Parts/kethane_radialDrill/model001' not found! [LOG 02:03:24.833] Load(Model): Kethane/Parts/kethane_tank1mLarge/model [ERR 02:03:24.842] Texture 'Kethane/Parts/kethane_tank1mLarge/model000' not found! [ERR 02:03:24.842] Texture 'Kethane/Parts/kethane_tank1mLarge/model001' not found! [LOG 02:03:31.656] PartLoader: Compiling Part 'Kethane/Parts/kethane_generator/part/kethane_generator' [ERR 02:03:31.657] PartCompiler: Cannot replace texture 'model000' as cannot find texture 'model001' to replace with [LOG 02:03:31.672] PartLoader: Compiling Part 'Kethane/Parts/kethane_heavyDrill/part/kethane_heavyDrill' [ERR 02:03:31.673] PartCompiler: Cannot replace texture as texture replacement string is invalid. Syntax is 'origTextureName newTextureURL'

So, I noticed in a recent play session that I can turn off the electrical supplies to my probe, causing it to go dead. But then I can re-enable the electrical supply and the probe will come back to life. This is possible even with RemoteTech2 - cutting off the supply means no connection, but that doesn't stop me from turning the supply back on and regaining a connection. I was considering using this for long-term probe missions, but not sure how much of a cheat this would be. I recently read about the Rosetta spacecraft "waking up" after 957 days and this is the behavior I'm looking to model. Maybe a manual edit of the persistence.sfs file to remove a little bit of the overall electrical supply for the "trickle" that was used to keep track of the days leading to the automatic wake-up cycle.

No problem! Still a great little mod

any harm in the following ERR reports from my KSP.log file? [LOG 15:16:14.276] PartLoader: Compiling Part 'RealChute/Parts/cone_chute/RC_cone' [ERR 15:16:14.307] Invalid integer value [ERR 15:16:14.307] Invalid integer value [ERR 15:16:14.308] Invalid integer value [ERR 15:16:14.308] Invalid integer value [ERR 15:16:14.308] Invalid integer value [LOG 15:16:14.321] PartLoader: Compiling Part 'RealChute/Parts/cone_double_chute/RC_cone_double' [ERR 15:16:14.329] Invalid integer value [ERR 15:16:14.329] Invalid integer value [ERR 15:16:14.329] Invalid integer value [ERR 15:16:14.329] Invalid integer value [ERR 15:16:14.329] Invalid integer value [LOG 15:16:14.340] PartLoader: Compiling Part 'RealChute/Parts/radial_chute/RC_radial' [ERR 15:16:14.352] Invalid integer value [ERR 15:16:14.352] Invalid integer value [ERR 15:16:14.352] Invalid integer value [LOG 15:16:14.379] PartLoader: Compiling Part 'RealChute/Parts/stack_chute/RC_stack' [ERR 15:16:14.388] Invalid integer value [ERR 15:16:14.388] Invalid integer value [ERR 15:16:14.388] Invalid integer value [ERR 15:16:14.388] Invalid integer value [ERR 15:16:14.388] Invalid integer value

tl/dr - is there not a way to get rid of the original resource panel as well? It seems this should be replacing it but appears to be supplementing?

I agree with Taki117 but if you want to try it here is mine. I mapped the Abort key directly to the Fire button (the one under the cover) within the game. I also have the new X-55 Rhino which is awesome but unfortunately no longer a single throttle/stick unit when plugged in - you have to plug in two USB cables. This means KSP can't differentiate between them because they use the same axis assignments (for example the 1 axis on the throttle is the same as the 1 axis on the stick and you end up controlling the throttle and pitch at the same time by moving the throttle). This is a Unity limitation I've been told by the devs. Hopefully that gets fixed with an update sometime

(Cartman voice) God dammit!!

The following mission report comes from the public relations account of the Kerbal Space Agency, detailing the fourth mission - a repeat flight (Flight 2) of Kerbal III commanded by a second astronaut, Bill Kerman. It is hoped that improvements to the Kerbal III rocket design will result in a more successful flight. These are only the tweets related directly to the mission on launch day. For more reports on the status of the KSA between missions, tune in to @KSA_MissionCtrl. Previous Mission Reports Mission001: Rocket Test Mission002: Recovery Test Mission003: Chimps are for Wimps - F1 Catch up on what happened next over at @KSA_MissionCtrl!

I went searching around for this through Google (pointed at this site for results after a general web search) and pretty much all the results came up with met for Mission Elapsed Time and lct as ??? - although one person did correctly guess LaunCh Time. Regardless, none of the posts explained exactly how KSP uses these elements so I did some quick experiments to find out. Hopefully this'll come up for anyone else searching about these in the future. lct (LaunCh Time) - this is the number of seconds that have elapsed in the game up to the launch of the mission. In other words it is equal to the UT parameter at the time of launch. So if you launch your mission on Day 2 at 12:30:06, the lct for the mission will be 131406.xxxxxxxx (the x's being the floating point precision, which you can ignore and just change the integer portion). The game uses this value to calculate the MET you see displayed in the Tracking Station. met (Mission Elapsed Time) - this is the number of seconds the mission has been ongoing, and is only updated and used when you have actually loaded the craft in question. This is important to understand, as if you want to change the MET for your craft you should only edit the lct value for the vessel as the met value will then be updated when you next load the craft. Note that changing the LaunCh Time will not affect the position of your craft's orbit, just your MET. However changing the UT value will.

Jeb is highly photogenic. I'm using SweetFX to bring out the colors a lot more.