thorfinn

....why? Do you mean, to fly horizontally? What do you need that huge TWR for?

Interesting, I'll try If these things can be repacked, motherships don't need anything more than slowing down below escape velocity; the rest just takes patience

When you say "2.5m for 30 tons", do you mean that you don't expect that huge ballute to get a heavier ship below escape velocity from interplanetary speed? Also, how do they behave under rails-warp? If I were to make a 2 or 3 pass aerobrake to circularize, would I have problems as I wait to come back in the atmosphere?

Oh dear. You actually got this working! I really have to reinstall KSP now (Yes, I threw the towel because of the horror that is OSX KSP right now. Hopefully 1.1 will solve the RAM problems). And you even implemented the multipolar expansion of gravity fields, man you are crazy What does it look like around Gilly? (By the way, since you are talking about precession etc., is automatic stationkeeping still on the cards for someday?)

I almost expected you to do a toss bombing on the KSC Speaking of limiters, actual TFR systems had a "soft/medium/hard ride" knob: maybe you could duplicate that? (IIRC on the F111 "hard" ride meant +2G/0G and "soft" was +2/+0.75) I suppose you can steer laterally without disturbing the TFR?

Could you post some details? I'm pretty sure that this is the problem that's making the OSX version horribly unstable (and it crashes always on a scene change): if you can replicate it also in Windows then we might be able to show them where the problem exactly lies...

So guys, how much of a trouble is the area ruling? I like the idea in principle but I'm quite worried it will be a pain to respect area ruling in KSP with the limited choices we have, what's the experience up to now?

One more thing: I left open the info tab in Activity Monitor for the KSP process while I tried another simple launch (13 part ship, suborbital 10 minute flight) and took a screenshot right after the crash, which happened as I pressed the "recover vessel" button. My resolution was 1280x800 by the way, full screen, no external monitor. I haven't yet tried to use resolution change utilities, outside of KSP's settings. I translated the entries from the Italian: as you can see, the virtual memory was almost completely full at the last update of that window - I suppose that whatever was generated to handle the "vessel recovery" action pushed it over the 4GB edge. I had visited pretty much all the buildings (SPH, admin, astronaut complex, VAB) briefly before the launch. This time the crash happened after the first flight, with no graphics degradation before it for what I've seen. I'm not a programmer, but it looks like a GC problem or something similar to me: there is no way an unmodded KSP image is really filling 4 GB after a single flight in a new world. Also there's the fact that it takes a variable time to happen, and reducing texture quality buys time but does not avoid the issue in the end.

I remember discussing a similar situation (framerate going down the drain when Kerbin was in the viewport) when I still was on the experimentals team, and that was, like... three years ago.

These are my system specs: Late 2014 13" Macbook Pro, 8GB RAM, Yosemite 10.10.3, 2.6GHz Core i5, Iris graphics The crashes happen on a scene change, after a few of them have already taken place. It is preceded by graphical corruption such as what you see below, usually you can fly one more mission with these "shadows" present and the game will crash on craft recovery, or in the VAB slightly later. Reducing graphics quality appears to delay the inevitable, but crashes happen nonetheless. Sorry, but I have to work and I won't be able to play bug hunter anymore for a while. I am quite disappointed that this hasn't improved a bit since 0.90.

What I can see is the usual stark difference in FPS between looking into space (timer solidly in the green) and looking at the ground (yellow shows up even with a 10 part ship). This has existed for a very long time, I can't really tell if it got even worse because the memory leaks on OSX are making my game crash evey 20 minutes. I am seriously disappointed with this update.

I have the same problem. Same graphical corruption followed by CTD as previously experienced with 0.90 on OSX, 0.25 was much less affected. Fresh download, no imported save, no mods, no nothing. The Player.log file is here. Here is some information from the OSX core dump: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 ===================================================== VM Region Summary: ReadOnly portion of Libraries: Total=205.0M resident=61.7M(30%) swapped_out_or_unallocated=143.3M(70%) Writable regions: Total=3.3G written=111.7M(3%) resident=2.7G(82%) swapped_out=81.2M(2%) unallocated=617.3M(18%) REGION TYPE VIRTUAL =========== ======= CG backing stores 20.7M CG image 124K CG raster data 39.6M CG shared images 368K CoreAnimation 24K CoreUI image data 132K Foundation 4K IOKit 1.4G Kernel Alloc Once 4K MALLOC 1.3G MALLOC (admin) 48K Memory Tag 242 12K OpenCL 16K OpenGL GLSL 128K Stack 70.3M VM_ALLOCATE 517.2M VM_ALLOCATE (reserved) 4K reserved VM address space (unallocated) __DATA 9244K __GLSLBUILTINS 2588K __IMAGE 528K __LINKEDIT 50.0M __OBJC 2500K __TEXT 155.0M __UNICODE 552K mapped file 136.6M shared memory 68K =========== ======= TOTAL 3.7G [FONT=Helvetica]Thread 0 Crashed:: Dispatch queue: com.apple.main-thread[/FONT][FONT=Helvetica]0 libsystem_kernel.dylib 0x9660369a __pthread_kill + 10[/FONT] [FONT=Helvetica]1 libsystem_pthread.dylib 0x93345f19 pthread_kill + 101[/FONT] [FONT=Helvetica]2 libsystem_c.dylib 0x9af60eee abort + 156[/FONT] [FONT=Helvetica]3 libmono.0.dylib 0x0131051d mono_handle_native_sigsegv + 881[/FONT] [FONT=Helvetica]4 libmono.0.dylib 0x01349c3a sigabrt_signal_handler + 99[/FONT] [FONT=Helvetica]5 libsystem_platform.dylib 0x9333f03b _sigtramp + 43[/FONT] [FONT=Helvetica]6 ??? 0xffffffff 0 + 4294967295[/FONT] [FONT=Helvetica]7 libmono.0.dylib 0x01349bd7 sigusr1_signal_handler + 159[/FONT] [FONT=Helvetica]8 libsystem_c.dylib 0x9af60eee abort + 156[/FONT] [FONT=Helvetica]9 unity.Squad.Kerbal Space Program 0x0034a822 HandleSignal(int, __siginfo*, void*) + 34[/FONT] [FONT=Helvetica]10 libmono.0.dylib 0x0134981a mono_chain_signal + 76[/FONT] [FONT=Helvetica]11 libmono.0.dylib 0x01293ae2 mono_sigsegv_signal_handler + 234[/FONT] [FONT=Helvetica]12 libsystem_platform.dylib 0x9333f03b _sigtramp + 43[/FONT] [FONT=Helvetica]13 ??? 0xffffffff 0 + 4294967295[/FONT] [FONT=Helvetica]14 libmono.0.dylib 0x012939f8 mono_sigill_signal_handler + 59[/FONT] [FONT=Helvetica]15 libmono.0.dylib 0x0134b651 mono_add_process_object + 115[/FONT] [FONT=Helvetica]16 libmono.0.dylib 0x0134b28b mono_unity_liveness_calculation_from_statics + 516[/FONT] [FONT=Helvetica]17 unity.Squad.Kerbal Space Program 0x002ea948 GarbageCollectSharedAssets(bool) + 3128[/FONT] [FONT=Helvetica]18 unity.Squad.Kerbal Space Program 0x0030b902 CleanupAfterLoad() + 18[/FONT] [FONT=Helvetica]19 unity.Squad.Kerbal Space Program 0x002efe45 LevelLoading::LoadLevel(int, std::string const&, AwakeFromLoadQueue&) + 869[/FONT] [FONT=Helvetica]20 unity.Squad.Kerbal Space Program 0x002efad7 PlayerLoadLevelFromThread(int, std::string const&, AwakeFromLoadQueue&) + 39[/FONT] [FONT=Helvetica]21 unity.Squad.Kerbal Space Program 0x002f4c91 PreloadLevelOperation::IntegrateMainThread() + 65[/FONT] [FONT=Helvetica]22 unity.Squad.Kerbal Space Program 0x002f3cdb PreloadManager::UpdatePreloadingSingleStep(bool) + 299[/FONT] [FONT=Helvetica]23 unity.Squad.Kerbal Space Program 0x002f4308 PreloadManager::WaitForAllAsyncOperationsToComplete() + 136[/FONT] [FONT=Helvetica]24 unity.Squad.Kerbal Space Program 0x002f1e14 PlayerLoop(bool, bool, IHookEvent*) + 708[/FONT] [FONT=Helvetica]25 unity.Squad.Kerbal Space Program 0x0065e65c -[PlayerAppDelegate UpdatePlayer] + 252[/FONT] [FONT=Helvetica]26 com.apple.Foundation 0x956ad6cf __NSFireTimer + 119[/FONT] [FONT=Helvetica]27 com.apple.CoreFoundation 0x9be36006 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22[/FONT] [FONT=Helvetica]28 com.apple.CoreFoundation 0x9be35ab4 __CFRunLoopDoTimer + 1316[/FONT] [FONT=Helvetica]29 com.apple.CoreFoundation 0x9beb154f __CFRunLoopDoTimers + 351[/FONT] [FONT=Helvetica]30 com.apple.CoreFoundation 0x9bded531 __CFRunLoopRun + 2081[/FONT] [FONT=Helvetica]31 com.apple.CoreFoundation 0x9bdecaa6 CFRunLoopRunSpecific + 390[/FONT] [FONT=Helvetica]32 com.apple.CoreFoundation 0x9bdec90b CFRunLoopRunInMode + 123[/FONT] [FONT=Helvetica]33 com.apple.HIToolbox 0x9623e8f8 RunCurrentEventLoopInMode + 262[/FONT] [FONT=Helvetica]34 com.apple.HIToolbox 0x9623e631 ReceiveNextEventCommon + 494[/FONT] [FONT=Helvetica]35 com.apple.HIToolbox 0x9623e42c _BlockUntilNextEventMatchingListInModeWithFilter + 99[/FONT] [FONT=Helvetica]36 com.apple.AppKit 0x93f07721 _DPSNextEvent + 742[/FONT] [FONT=Helvetica]37 com.apple.AppKit 0x93f06dc5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 350[/FONT] [FONT=Helvetica]38 com.apple.AppKit 0x93efb77c -[NSApplication run] + 907[/FONT] [FONT=Helvetica]39 com.apple.AppKit 0x93e70bc0 NSApplicationMain + 2082[/FONT] [FONT=Helvetica]40 unity.Squad.Kerbal Space Program 0x0065e3ab PlayerMain(int, char const**) + 731[/FONT] [FONT=Helvetica]41 unity.Squad.Kerbal Space Program[/FONT][FONT=Helvetica]0x00003095 start + 53[/FONT] From the Player.log, the root cause seems to be [COLOR=#000000]KSP(383,0xa09221d4) malloc: *** mach_vm_map(size=4194304) failed (error code=3) which is an out of memory error. Looks like it's running out of virtual memory (definitely not of real memory, my machine has 8GB and the "memory pressure" stays in the green all the time). It's on a latest model 13" Macbook Pro.

"Supermaneuverable" usually means controllability at high AoA, these planes are flying awfully fast but at a moderate AoA... I have seen people flying in very unusual attitudes though. There is the %AoA deflection setting for control surfaces which is the poor man's stability enhancer, some people used it to good effect (I haven't tried it personally, I'm waiting for 1.0 to restart everything)

The matter is quite complicated... here is a document I found that I don't have time to read in full at the moment: http://www.dept.aoe.vt.edu/~lutze/AOE3104/climb.pdf It seems that the exact solution depends on the characteristics of engines and wings. What I know is that there are two different attitudes for best rate of climb and best angle of climb: the second condition happens at a slower speed, but how much slower I don't know in general (All I remember is that for light planes at takeoff there can be a very significant difference)

If you have both canards and conventional tailplanes they can be all lifting - provided that the tailplane surface is fairly bigger than the canards, for stability. Strange things might happen at high angles of attack, but if you ensure that the tailplane stalls last (by amgling it the least), the behaviour should be benign