Lisias

I think you missed the point. :-) In the 90's, Lucas Arts created the SCUMVM - Script Creation Utility for Maniac Mansion Virtual Machine, and a lot of LA's games were then made over it. Better, by porting SCUMVM to different platforms, most (if not all) games were automatically ported. Before them, Infocom did the same with Zork with ZIL/ZIP - with the same results: I can play the 1979's Zork on my modern Unix machine, as someone kindly ported the ZIP to it. ID Software did it again with Doom and Quake - the original Quake Engine was a marvelous at the time, we could literally switch the rendering subsystem to anything we want! OpenGL? Ha. This guy used a Oscilloscope as 3D engine! :-) And so on. There's no "Space Exploration Engines" around, as far as I know. Perhaps this can be a new niche to be explored.

I don't know about Squad, but I like the sound of "KSP Engine". :-)

Easy! Perhaps the crash is not a symptom, but the root cause. I am having some serious crashing on my KSP this week. Trying to pinpoint the reason, I already "accused" 4 different mods of being the root cause, when actually they were just the "first victim". I'm now on a situation where the crash is happening even on a configuration that was working 2 hours ago : i figured out a working status quo, then added a suspect, the crash happened, then I deleted the suspect and the crash are still there since! =D Don't ask. I don't understand either - but I'm still fighting. :-)

Sometimes, you must choose between "respecting" the author, and respecting the users. (please note the quotes). Once the license allows something, the authorization is already granted. So I don't see "disrespect" on using such authorization. Publishing recompiled binaries - mainly if the distributor states clearly that it's only a recompiling, and the original author still "owns" the project, should not be seen as disrespectful. Hostile take-over of the project, mainly with the current owner actively maintaining it, is disrespectful. Forking is encouraged in Open Source - you must remember that when doing it [open source].

By Kerbol's sake! :-) Excellent! :-) I want to suggest to include scientific bases too. From Kerbin Side Classic, I remember at least one in A with a small steel (WW2 style) airstrip, and at least one base on a mountain with helipads only. I don't think they should be mapped as local airports (perhaps the Antarctic one).

Besides showing the status quo on the screen, how about a way to log the data? Into a file, or even to a socket or named pipe and it's up to the user to provide a way to store the thing. I'm facing some hard to crack issue inside Unity, and cross referencing the GC activities would be of a great help.

"You all"? I wish! :-) I'm probably so lost in this mess as you. :-) From your log, i found: NullReferenceException: Object reference not set to an instance of an object at scatterer.SkyNode.RestoreStockAtmos[UIApp] OnDestroy: MessageSystem (Filename: /Users/builduser/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) NullReferenceException: Object reference not set to an instance of an object at scatterer.SkyNode.RestoreStockAtmosphere () [0x00000] in <filename unknown>:0 at scatterer.SkyNode.Cleanup () [0x00000] in <filename unknown>:0 at scatterer.Manager.OnDestroy () [0x00000] in <filename unknown>:0 at scatterer.Core.OnDestroy () [0x00000] in <filename unknown>:0 What led me to the conclusion that Scatterer is the Victim, not the culprit. Open the "Console" application, look for the Unity's Player.log, and post it too. My guess is that your Mac's integrated GPU doesn't support something Scatterer needs, fails silently (or Scatterer ignores the Exception) and then Scatterer get lost. Try not loading SVE. Perhaps you had run out of VRAM. EDIT: How many monitors you have? There's a not so well known issue on Unity while running on multi-headed Macs!

Check the github's page. It appears to be being actively developed.

I just found this. I think it fulfils the OP's request.

Well, it's is being developed as SXT Continued. Go there, download it and see if you find what you want.

Obligatory XKCD mention: https://xkcd.com/1356/

Don't need to be manual - at least, not all of them. There's kRPC available - go DEVOPS!

is totally unrelated

IMO Kerbals being green is not related to Chlorophyll. They would had not survived underground if that would be the case. I think they use copper as oxigen-carriers (Hemocyanin), and the green color is the result from the blue blood colour on a yellow flesh.

This music is stuck in my mind since I realized how Unity handles memory. =/

Both. =D A "clean boot" for my KSP installment takes 6GB of Mono code allocated memory, and about 1G for the heap - before loading any vessel. My usual memory footprint is 10G of allocated RAM when I'm playing my biggest vessel at the moment. You are just delaying the crash. I don't remember who had said before that the MemGraph stunt was allowing him to have some minutes of stutterless playing, but then the thing halts and then crashed - I'm guessing that the GC took too long to do his job, and some other thread panicked and aborted due the apparent halt. Mono is a problem, but the Unity's posture about memory is worse. Even Java, that have a excellent state of the art Garbage Collector, is helpless when a dumb programmer decides it's a good idea never release back the memory it gets. Frankly, I hate Mono. But it is one of the reasons KSP is where it is now, I have to give it that. I seriously doubt we would have so many (good) plugins, in three desktop platforms (and 2 videogaming ones) if everybody had to deal with C++. Been there, done that. I did this in Orbiter. It's faster, it's more efficient. But very few guys can handle this. Due the way Unity keeps stomping on our feet, I wonder if it's time to ditch Unity itself, not exactly Mono.

In the end, it's a Garbage Collector problem. Mono is a dog blessed half baked of a VM - it's at at least 6 to 10 years behind Java in everything (but syntax - but hey, we have foreach and ? null operators...=/). Added to that, we have a nasty practice on Unity (and granted, not just them) where once memory is allocated, it is not given back to system. They said that there's a reasonable expectative that if a memory was needed, it will be needed again - totally ignoring that the memory will be needed by everybody else in the system. This used to work when just one or two clowns guys were doing it - but nowadays, everybody is doing this stunt. So we never have enough memory. We are again using "single-tasked" systems. Swapping memory make the switching context slower? Of course it does. But it's faster than restarting the program (mainly KSP), god damnit. It's better to send KSP to swap when I have to do something else and then wait 3 or 4 minutes to it came back to RAM, than to close the damned thing and then have to wait FIFTEEN MINUTES (or more) to reload it from scratch. Adding offense to the injury, it appears that they "solved" the stuttering on the stock game by delaying the GC - so, more and more trash would be left in memory before the GC is called to clean the house. Since now there would be a ton more of trash to be cleaned, the stuttering, when it happens, is heavier. It takes more time to happen, but when it happens, boy... it does happen. Now put this two things together (Unity never returning memory, and Mono literally trashing the memory) and... =/ Sometimes, putting more memory into the equation makes things worse. It's better to halt 0.5secs each 2, than to halt 4 secs each 10. Memory Garbaging are algorithms that scales exponentially, not linearly. Even the ones that manages to escalate logarithmically needs a sweet spot to be useful, behaving worse than linear ones before that.

And.... yes. There's a memory leak on 1.4.3 . =/ Mine is heavily modded, so that bunch of mods is "helping" the problem, but the memory leak is there - the plugins just make it happen sooner! By leaving KSP running alone by the night, it always crashes by SIGABRT on MacOS. On the Activities, the process had almost 1T allocated (god damned memory compression used by Apple! =P) on machine that has only 16Gb. :-) In a way or another, i think they trimmed the garbage collector to be less intrusive. Unfortunately, it appears that they made it less active in the process.

Better! Getting airborne in just one piece (and not scattered over the skies!) However, this is just a fraction of she. The other 4 hulls are still work in progress! =D But at least, I know what to do now. This is getting interesting!

YES! After days and days of blood (Kerbal's, not mine), sweat (mine, not Kerbal's) and tears (both), I manager to tame the infamous krakenwobbling! :-) I had to rebuilt the whole shebang from the ground due a wobbling that started to happen when I added the lateral gondolas. One way to overcome this is autostruting everything into the root (the Cockpit), but this has some drawbacks: I feel more or less cheating - there's no real life parallel to autostruting EVERYTHING into a single light part. This would invoke the krakenwoobling when docking another heavy vessel (planned). A way to solve this dilemma is to make root a docking port, and then another heavy vessel those root is also the docking port would cause minimal stress while docking (docking is a traumatic event when you use heaviest and root autostruting, as a dock would reconfigure everything). But that also sounded like "cheating". In the real life, we would use some serious steel I-Beams as a spine, but there's no way to do this without mesh clipping (something usually used in Kerbal dark masses to invoke the kraken). Another real life solution is use the I-beams traversing vertically the center o mass, and then using long flexible struts tying various parts of the vessel to the beam's extreme (as a suspension bridge). But that would derail the airstrip. So 4 I-beans in "X", at 45°, would do the trick. But then I realized that the stock AES struts can stretch to 10 meters max, and then a lot of struts and I-beams would be necessary to cover all the ship - and since I didn't found any mod with long, strong struts (well, there's ShipStuts from 77 Industries, but this relies on KerbPaint that don't work on 1.4.x), I scratched the idea. (making mods myself to solve my problems is also cheating, no?) So I given up, and came back to autostruts. But on a "less cheating" way: the central part of the vessel is the root, and all the heavy parts are autostruted to the root. That would simulate the central spine. Everything else is autotruted to the grandparent (or simply not autostruted), and tied up to the main body using girders, Netherdyne Jumbo Trusses or AES struts in "X". Since we can only use one attachment point per subassembly (the data structure of a vessel is a tree, not a graph), some Jumbo Truss have no effective structural function. Struts in "X" are used to do the job, and the Jumbo Truss "hide" the struts, pretending to do the job. And the thing flies well, besides the weight! 4 heavy duty propellers: two WB-50 Jet Streams and two F-12 Hurricane (and 4 Gas turbines to keep that power hungry engines happy) moves this monster to 54 m/s (195Km/h, ~105knots). :-) I'm still "cheating" on launch, however. I will end up using Kerbal Joint Reinforcements only due the launch clamps exploding everything instead of doing their jobs. :-) One thing that would help a lot is a new auto-strut option: pivot. You would mark one part of your vessel as pivot and then you could use it as target for autostrutting. And once a part is autostrutted to his pivot, it would not change target no matter what (but the pivot being destroyed in a crash). That would prevent Unplanned Slow and Painful Deconstructions =P on large vessels when docking - a situation where the root and heaviest part of the vessels changes, and them at least one vessel have all his auto-struts reassigned.

Here. 100% Unofficial. 200% Untested. =P Please report any issues.

Flying. Landing... Crashed.

Implementing such constrains would be easy on a user interface: once the user selects the "dit" length, the other lengths are calculated and the fields updated - and then the user can overwrite them at will. The framerate can be monitored, and a "correction factor" be used on the timings to guarantee that the "dit" length is no smaller than one frame. It's bit laborious to be implemented, but it's all - testing it will be more work than doing it. :-) Once the code I already made is revised and eventually merged, we can think about implementing it if Li0n is ok with the idea.

Yes! I tested it only with Heisenberg, but I don't see a reason it would not work fine with Hooligan's parts too. No. You will need Air Park or equivalent. Without this, you need to land it in ground or water.

Welcome. :-) Take your time, and please don't hesitate in asking for any changes you need - including code style and whitespacing (I think I messed up the tabs vs spaces, I will check it on my next time window).