Lisias

By building a testbed: take a KSP clean install, put the two mods you want to check and run the thing.

Keep in mind that there's a limit on the height you can reach relying only on buoyancy. I found basically two ways to reach orbit on this "blimp": Going ballistic: Turn on the Reactor, set the HLAirships plugin to "Altitude Control On", set it to 1.00m/s Set all KDM drives to 100% (hit "0" many times) Once the "Buoyancy - Heght" gauge reaches a positive value, release the clamps Wait the airship to climb 10 or 15 meters, then engage the KMD ("1") Set the buoyancy to 100%, disengaging the "Altitude Control On". Allow her to keep her nose up - otherwise the drag will impair your speed Watch the Apoapsis (use KER). Stop the drives when the apoapsis is about 70% to 80% the desired orbit Drop her nose to horizon level. Engage the drives and go for the horizontal speed. Stop when your periapsis reach the desired orbit. Drop her nose below the horizon to drain vertical speed and avoid exceeding the desired orbit at apoapsis while gaining horizontal speed. Cannonical Spaceplane approach: Almost the same, but do not disengage "Altitude Control On". Do not allow her nose to go higher than 5 to 15° Once she reaches her maximum buoyancy altitude, engage SAS and raise her nose a bit until you have some lift again. From now on, she is a lifting body Use F-12 to enable the Aerodynamic Forces Overlay. It helps. Once at 50.000 more or less, drop her nose a bit and go for the horizontal speed. Do not raise the horizontal speed above Mach 6 until you reach at least 55.000 Meters High. She will overheat. Use SAS to Prograde as soon as you loose lift for good. Watch the Apoapsis (use KER). Stop the drives when the apoapsis reaches the desired orbit At apoapsis, go Prograde and start a "burn" until the periapsis is at desired level. Using ballistic, you reach space pretty fast! (boy, she flies fast!). But is pretty hard to control the orbit's inclination and eccentricity. The Cannonical way is less fun, but give you far more control about the orbit parameters. :-)

Uploaded a space able version on kerbal x,

YES! :-) But it needed MOAR BOOS.. I mean MOAR KRAKENS. :-)

I made a blimp break the sound barrier, reached over MACH 2, and then put the damn thing in orbit!

I needed a rest, found this, so I did this:

I had to do this... I simply had! =D https://kerbalx.com/Lisias/Krakenlin-Mk1

This one took me some blood, sweat and tears. I mistakenly diagnosed this as being run out of VRAM, and then deleted lots and lots of AddOns without success. Then I thought it could be a unholy interaction between some Plug-Ins, and took a lot of time playing combinatorial analysis with my installed plugins. No pattern detected. Just then I though on really looking into that report again: Process: KSP [21826] Path: /Users/USER/*/KSP.app/Contents/MacOS/KSP Identifier: unity.Squad.Kerbal Space Program Version: 1.4.3 (0) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: KSP [21826] User ID: 505 Date/Time: 2018-05-11 07:30:21.553 -0300 OS Version: Mac OS X 10.12.6 (16G1314) Report Version: 12 Anonymous UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Time Awake Since Boot: 65000 seconds System Integrity Protection: enabled Crashed Thread: 0 MainThrd Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY VM Regions Near 0: And voilà. New issue. :-( It ended up being a issue with a old copy of "000_USITools", more specifically, USITools.dll . I probably had a VRAM issue before, but while trying to figure out what AddOn I would delete and which one I need to keep due my vessels, I probably reinstalled a Add On with a old USITools.dll that, by some reason I just could not figure out, crashed my machine. Such old version of USITools.dll may be not the cause, just one (of possible many) trigger - but nevertheless, I solved my problem this time by installing the newest release of USITools. So, if you ever get this SIGABRT from com.apple.main-thread, first check the 000_USITools subdir to see if you have the most recent one. If not, update to the newest one for your KSP installment (I'm using 1.4.3). If after updating the USITools you still have the issue, make a copy of your installment and start to delete AddOns one by one until the crash is gone, and then install back all the others. If success, please report on this thread so others can save their time! :-)

On my MacMini mid 2011 (a very expensive potato machine!), I'm constantly running out of VRAM (or something similar). Since my box is dual headed (two monitors), this issues appears to be happens more to me than on a single head setup. The way to diagnose this is asking for the report once the crash happens, and see where the crash happened. On the resport itself, check if a SIGABRT were issued from the UnityGfxDeviceWorker thread as the example: If it's your case, there's a very good chance that you overrun the VRAM limits. The solution for this problem is to reduce your texturing footprint. Usually, by deleting the last AddOn you installed but I also solved this by deleting visual enhancements Plug In, mainly the ones that adds or switches textures on the game. It's a choice you must make: more parts with small textures or keeping large textures used on skies, planets, etc.

Well... The last few days I got somewhat overwhelmed by a series of crashes on my MacOS box that I didn't diagnosed correctly, and found myself chasing ghosts. =/ Not one of my brightest times. =P This thread is my attempt to gather together a knowledge base of MacOS specific issues and, with luck, minimize the time spent on crashing KSP and maximize the time spent crashing crafts on KSP. :-) The proposed "rules" are simple: a post per 'problem x solution'. I don't plan to use this as a generic support thread - I think that help for unknown problems should be get in dedicated threads. My plan for this one is to be a place where one can try to find a solution for a MacOS specific problem before asking for help. So, let the games begin. :-)

Unfortunately, it isn't working for me (1.4.3 heavily modded). I didn't researched the cause, but eventually I will need it and then I will find the time to do so - unless someone does it first. :-)

Nops. You are the one not understanding mine. :-) No arguing about this point. What I think of Unity is irrelevant - what's matter is what it had done to the game (good and evil), and if the net value of it is positive. There's no way to prove you (or me) right or wrong without effectively trying the stunt. So, all we can do is propose facts and arguments in the hope that from the discussion something minimally realistic could be extracted. :-) I think that you think that I'm proposing that Squad would create their own 3D Engine, or their own Physics Engine, or whatever. Nops, far from it. There's no point on investing R&D money on commodities, and these things are commodities nowadays. "KSP" engine is, in my mind, what's Quake Engine was in the nineties. A (relatively) stable API to build things - anyone here remembers AirQuake? ;-) Such "KSP Engine" already exists (well, sort of). And we are already building content for it, in the exact same way people did in the nineties for Quake 1. And later, for Quake 2. And then Quake 3 and Quake Arena came - and the rest is history. Money is a scarce resource - but engaged eco-systems are scarcer. Quake managed to accomplish that in the past, and I have absolutely no doubt this was the main (if not sorely) reason they managed to beat Unreal on the short run, and probably the cornerstone to what is Id Tech nowadays. I agree that there's no certain gain on trying the stunt. But it's certain that there's no gain on no trying it. Well, the rest of my arguing will hardly be different from anything I already said - so if I didn't made me understood by this point, I don't think I'll manage to accomplish that from here. Business Strategy are beyond technicians anyway. :-) POST-EDIT 2018/05/18: It came to my attention that the phrase I used to finish my post (currently in strikethrough) can be seen as a subtle and indirect attack. My apologies - my English can be technically good (sort of), but I don't manage the language subtleties. Well, I am a technician. So I'm included on the statement, being (or intended to) be implicit on the statement.

Exactly as KSP - even some refinement are there. I'm using 1.4.3 now, and I'm still using some plugins compiled to 1.3.1, and some parts made for 1.2 - a lot of things changed since 1.2, but some add-ons managed to survive the changes. Mainly, what didn't had to deal with Unity directly had a nice change to survive new releases - even one that switched Unity itself. Almost 10 years ago. A lot of water had crossed under the bridge. A lot of lessons learnt. You have a point here. However, KSP have one thing that Eve-Online doesn't: a lot of people writing plugins, effectively changing the (or even almost creating a new) game. And all these plugins had broken in the past on each new release. What had broken and what had to be done to fix them created a very nice knowledge base that, correctly consolidated and used, can mitigate such risks. The only thing better than that would be having such knowledge base hosted on KSP's premises, as it's done by Mozilla. KSP is more like Quake I or Unreal I than Eve-Online. For a mile, IMHO. Online gaming is being added to it by third-parties very similarly as it was added to Quake I (man, I remember playing Q1 Team Fortress on a US-Robotics 33.6K). Developing an Open "World" Space Exploration with Tech Evolution was also a very risky adventure. It's no secret that TTI is changing the KSP business model to better cope with such risks. A "KSP engine" can be an additional way to do that (but granted, can be not - you can be right, I'm not denying it. But my argument is that some facts appears to say that perhaps you are not). I'm not saying it will be easy. I'm not saying that they will manage to easily switch (or even get rid of) Unity or something like that (the marriage to Mono appears to be solid at this point). I'm saying that they are, now, in a good position to seriously think about the possibility. As ID was in the past, some point between Quake II and Quake Arena.

Well... Another hard nut to crack - preferably, without loosing some teeth :-) I planned and built this huge vessel with real life engineering concerns in mind (not that I know too much - I'm just a smart ass that likes engineering). But... Kerbal physics can have some resemblance with real-life physics, but... That's it! Just some resemblance! =D First things first: since not all parts of the vessel have the same buoyancy, you can end up with some variation of the two extremes below: Two common "fixes" for this problem are using i-beams and struts, as follows: Since my vessel has a very long hangar in the center, the model that it follows are the top one: light extremes, heavy belly. And since I decided to add some more functionalities, more buoyancy will be needed, but I wisely decided that the vessel is long enough :-) so I decided to expand it laterally - what would eliminate the need for a I-Beam and struts - what would seriously impair my airstrip and/or my landing capabilities! So, the top view of my vessel is something like this: What would solve the problem: I added buoyancy to the center of mass, so the vessel is now almost equilibrate. Autostruts to the Root part (that is also the CoM) would solve the slightly heavier belly (autostruts to the CoM would cause KrakenWobbling when docking vessels!) However.... KSP doesn't works like that. :-) Buoyancy appears to be implemented as merely subtracting weight from the CoM. So the parts itself doesn't have a Buoyancy exactly, but a "weight inverting factor". And since all parts have a weight, what I did accomplish was a huge vessel that follows the "belly light" model, with the extremes pending down due the force of Gravity! #facePalm If I try that stunt again, and add yet more buoyancy in a third hull (each side), what I would accomplish would be a even heavier nose and tail due adding mass to CoM that is "inverted" by the sum of the "buoyancy factor" of the parts. Exactly the opposite from what happens in reality. =D So... Now I have to cook a way to strut my vessel nevertheless my "clever" design. Worst, now I have more functionalities the would be impaired by such strutting. =D =D Yes, I foreseeing a very interesting Weekend. =P

I have this mysterious and unexplainable urge to use this on blimps....

Indeed, I was so sure about Scatterer that didn't bothered to check your logs! :-) So it must be something else that also needs that missing thing. Perhaps JSIAdvTransparentPods?

Scatterer. Your Videocard doesn't support something Scatterer needs - I never figured out exactly what it was, but since I'm running KSP on a crapy MacMini, I can't expect too much from the setup, so I just deleted Scatterer and moved on.

Try TakeCommand. It's a mod that would allow what you want.

On a system I'm implementing, the files are actually classified by subdir in the file-system - this make file management a lot easier outside the system. But inside the system, the file list is linear, and the subdir names became tags itself. Paralel to that, there's some more use defined tags too. The solutions are not mutually exclusive. (of course, I'm solemnly ignoring if KSP would allow further subdirs on Ships/VAB and Ships/SPH or not)

Oh, now I see. Well, I can think of a quick & dirty solution - a weightless and dragless "part" to be attached to the craft, and this part always 'break' on launch, and need time (and money) to be rebuilt before reuse. This would simulate the maintenance time/cost without having to change working code. What do you think?

How about ScrapYard? With Kerbal Konstruction Time, it appears to satisfy your requirements. And perhaps you would be interested in Oh Scrap! too.

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].