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

Well, depends on what they look like: a typical 2D supersonic intake (like one from Concorde) would push the ramp fully down to close, and I'd be surprised if that wouldn't be any less draggy than windmilling the engine.

Nice: so LiquidFuel/Oxidizer could be just an alias for RP-1/LOX or RP-1/H2O2, whatever the densities? Then MonoPropellant could also be an alias for Hydrazine or, if you want to aggravate people, H2O2 Jokes aside, H2O2 was the earliest RCS fuel and it would make the upgrade to N2H4 very desirable.

It's not so mad, it's British (The tiny launcher that the UK built alone in the late sixties was based on that). I didn't think about the mixture ratio though, you are right - and it's totally different from the stock propellant, something like 7:1 (!) So a if a "backwards compatible" mixture has to exist that's a problem.

I think that adding H2O2, if not just replacing storable oxidizer with it, would help a lot in emphasizing the differences: H2O2/RP-1 is very dense and with a ultimate Isp similar to N2O4/UDMH, giving the option of very heavy but very high mass-ratio storable stages (or boosters). Monoprop H2O2 has very bad Isp but could be a nice low-tech/very low-cost choice also.

Actually, after checking, I see that Ike is so huge that not even L4 and L5 are stable around Duna! (The mass ratio must be greater than 25, Ike is only 16 times lighter). The Kerbin/Mun ratio is above 50 on the other hand. For some reason I expect the steeper gravitational gradients (compared to reality) to yield more binding potentials in the two points, but it's probably more complicated than that. EDIT: well, according to this document (http://wmap.gsfc.nasa.gov/media/ContentMedia/lagrange.pdf) the curvature near the points depends almost only on angular velocity squared: so a more compact system like Kerbin/Mun should have steeper wells (but it's too late to think really straight I suppose)

Very interesting man, I hope we will see the results soon I have been thinking that not only Kerbin-Mun L4 and L5 should be much stabler than the real ones, but on Duna it's likely that no synchronous orbit is stable Would any GEO satellite eventually fall into either L4 or L5? (It'll be interesting to try) I remember you were thinking about various visualizations of gravitational potential, did you experiment with that?

Well, the size -1 aerospike seems to be THE engine for a Eve sample return mission

All solids have the same low-ish Isp in the pre-release; I suppose this is a mistake. (380 all the way for the aerospike, OTOH, isn't it a tad high?)

True... but... why would they WANT to?

Unless I got a DOA Macbook Pro one week ago, I don't think so. What happened to me was the whole VAB scene replaced by a color gradient like those forming subdivision 0 of the Mun there. It was bizarre (and didn't get in a screenshot)