Lisias

On a wild guess, perhaps Planet Shine? I'm guessing that they had to do something similar as what DOE does in order to achieve the effect, and so we can be seeing both add'ons trying to do similar things and clashing on each other. Can you check if by removing Planet Shine the problem goes away? Or perhaps making a full duplicate of your KSP and, on the duplicate, starting remove things until you detect the point in which the problem is not there? That would help me a lot, as I would , so, use my (unfortunately scarce) time on trying to figure out what's happening instead of doing the search myself... Cheers!

Yep. The information density of that thing is pretty high! It's the problem with large streams of numbers, humans are not trained to handle them. I will try to highlight the affected numbers: cube = Default, 4.031,0.7793,11.34, 4.031,0.2816,11.34, 4.736,0.5131,7.268, 4.736,0.3404,6.481, 29.19,0.9493,0.5587, 29.19,0.9497,0.5587, -5.512,0.125,-7.448E-08,11.33,7.823,0.9217 cube = BuoyancyDragCube, 4.031,7.793,11.34, 4.031,2.816,11.34, 4.736,5.131,7.268, 4.736,3.404,6.481, 29.19,9.493,0.5587, 29.19,0.9497,0.5587, -5.512,0.125,-7.448E-08,11.33,7.823,0.9217 O broke the line to separated the dragcubes from the Bounds ones. Try to mentally group the numbers in "arrays" of elements, and name them [A, d, D] where A = Area, d = dragness, D = Depth. On the code above, all the dragness (d) are in red. To create a dragcube to be used under water, essentially duplicate the dragcube used on atmosphere, change de dragness of each "array of 3" to the number that satisfy you and set buoyancyUseCubeNamed = BuoyancyDragCube where the value is the name of the dragcube you created. The first dragcube (labeled Default above) are always used on Atmospheric flight - unless I find some more info telling me how to customise it. I can think on a part with many dragcubes definitions and some code selecting the one depending of the environment the craft is travelling. Or even specialised dragcubes to change the drag based on the mach number the part is travelling. Yep. But by doing that you are also changing how the part is behaving on the atmosphere. By using two sets of dragcubes, you can trimm the water one without changing the atmospheric one. It will be also the key to scaling parts without changing the buoyancy, as it's happening on TweakScale (remember that video on TS thread?).

Well.. mangling with the drag curves can be made extremely easy by using TweakScale to handle the mess for you. You can create a parte with "premade" TweakScale data with the TS's UI turned off, something like: PART { name = FancyPartsSize1 bulkheadProfiles = size1, srf <lots of more stuff> TweakScale { type = stack_square defaltScale = 1.5 available = false } } +PART[FancyPartsSize1] { name = FancyPartsSize2 %bulkheadProfiles = size2, srf @TweakScale { %currentScale = 2.5 } } +PART[FancyPartsSize1] { name = FancyPartsSize3 %bulkheadProfiles = size3, srf @TweakScale { %currentScale = 3.75 } } That code above mocks the definition of a part with the Size 1 bulkhead, then define two more similar parts but with 2.5 and 3.75 sizes. On all of them, TweakScale will be made unavailable (besides being active), meaning that the part is not user scalable and will behave forever as it would be a "stock defined" part. You can even go Infernal Robotics style, and use only one part with the predefined sizes (as they would be variants): SCALETYPE { name = FancyScale_stacked freeScale = false scaleFactors = 1.5, 2.5, 3.75 scaleNames = Mk1, Mk2, Mk3 defaultScale = 1.5 } PART { name = FancyPartsMultiSize bulkheadProfiles = size1, size2, size3, srf <lots of more stuff> TweakScale { type = FancyScale_stacked defaultScale = 1.5 } } The code above will create a PAW with the options "Mk1", "Mk2" and "Mk3" instead of the classic, free style scaling bar used normally by TweakScale. Advantages: No fuss, no buzz. Just define the new size of the thing, and you are done! TweakScale handles any kind of KSP idiosyncrasy for you. You don't need to learn how to scale 3rd party Modules - TweakScale does everything for you. If something goes wrong, you have someone else to blame! Disadvantages: You will create a dependency to TweakScale. But… This may not be what you want. So, if you want to scale the drag cubes yourself, you need to understand what they are. First, some needed background: there're 6 freedoms of movements - 3 linear, 3 angular: But we don't handle the angular ones on drag cubes, only the linear ones: On KSP, this translates: Forward => +X Back => -X Left => -Y Right => +Y Up => +Z Down => -Z On VAB, +X points into the sky. On SPH, +X points into the hangar's door. On KSP, the drag is not calculated using the surface's polygon hitting the airflow as one would expect. Instead, some arbitrary values (inferred by the surfaces when you let KSP do the job for you) are defined and these values are used by the Physics Engine to calculate the drag of the part when moving on that direction. The vector formed by the sum of all the 6 possible drag vectors (into Z+, into Z-, into X+, into X-, into Y+, into Y-) are the drag we see in red when we hit F12 while flying. A mesh of a cube will have the same drag definition on all its 3 possible freedoms of movement. A rectangular pyramid those top vertex is pointed into +Z will not. The +Z may have some drag (at the thing is somewhat aerodynamic), the -Z will have a huge drag (as the flat face is hitting the airstream), the +/-X and the +/-Y would have ~1/3 the -Z drag, because they are smaller than it and a little bit inclined, favouring some aerodynamics. Now, a triangular pyramid will be yet more different. Let's suppose the top vertex is pointed into +Z, and one of the edges is pointed into +X: The +Z and the -Z will be similar as the previous example, but the -X will be, let's guess, ⅔ of the -Z one (due the inclination) and the +X will be ⅓ of the -X one (as it's edge is facing the airstream and is way more aerodynamic than the -X one). Both +Y and -Y will have slightly less drag than -X, as these two faces are inclined in relation to the airstream. Great. We now have the needed background to understand what the heck is a drag cube. Now let's discuss what the heck is a drag cube for KSP. A drag cube definition is a tuple with 3 elemens, where the first element is the area, the second is the "dragness" and the third is the depth (since the name "cube"): [A, d, D]. Each value is a float. The Area is straightforward, it is how much surface is hitting the airflow. The drag defines the "dragness" of the material - smooth surfaces will induce less parasitic drag than a rough one. I didn't figure out exactly what Depths models on this thing. The drag is nice because you can reuse values from parts with similar sizes but different surfaces, and then you just change de drag to reflect the surface's smoothness (or the medium in which its flowing). @ColdJ, this is also interesting to define hydrodynamics. You can create drag cubes to be used under water, so you don't screw up the definition for the atmospheric flight. Essentially, you just copy&paste the dragcubes for atmosphere and change the dragness on each dragcube to reflect the viscosity of the water! (more later). Somehow, KSP takes these 3 values, apply them into the current airflow and atmosphere density, and from this hat KSP gets the Drag being applied to the part on that direction of movement related to the airflow. Oukey. Now we learnt how to define the DragCube for a single direction of movement. But we have another 5 to cope with. How we write it into a config file? Well, this way: DRAG_CUBE { cube = <NAME>, <+X cube>, <-X cube>, <+Y cube>, <-Y cube>, <+Z cube>, <-Z cube>, <BOUNDS_CENTER>, <BOUNDS_EXTEND> } Since each cube is a tuple with 3 elements, you will see something like: DRAG_CUBE { cube = <NAME>, +XA, +Xd, +XD, -XA, -Xd, -XD, +YA, +Yd, +YD, +YA, +Yd, +YD, +ZA, +Zd, +ZD, -ZA, -Zd, -ZD, <BOUNDS_CENTER>, <BOUNDS_EXTEND> } Nice. But what the heck is the BOUNDS thingies? There are more 2 tuples with 3 elements (X,Y,Z) where you define where is the center of the object and how long it extends from the center - i.e, you are defining the smallest cube what could fit the part's mesh inside. In essence, it's a "collider" cube that's used to see if the airflow will hit the part. Bounds Center is a X,Y,Z coordinate related to the origin of the part (think of it as the CoD - Center of Drag). Bounds Extend are sizes. Practical example: PART { url = Squad/Parts/Aero/airlinerWings/MainWing/airlinerMainWing DRAG_CUBE { cube = Default, 4.031,0.7793,11.34, 4.031,0.2816,11.34, 4.736,0.5131,7.268, 4.736,0.3404,6.481, 29.19,0.9493,0.5587, 29.19,0.9497,0.5587, -5.512,0.125,-7.448E-08,11.33,7.823,0.9217 } } Gave us: Name : Default +X A = 4.031 d = 0.7793 D = 11.34 -X A = 4.031 d = 0.2816 D = 11.34 +Y A = 4.736 d = 0.5131 D = 7.268 -Y A = 4.736 d = 0.3404 D = 6.481 +Z A = 29.19 d = 0.9493 D = 0.5587 -Z A = 29.19 d = 0.9497 D = 0.5587 Bounds Center X = -5.512 Y = 0.125 Z = -7.448E-08 Bounds Extend X = 11.33 Y = 7.823 Z = 0.9217 Since this is a wing, consider that the drag will be very different depending the face that it's hitting the airflow (as we intuitively would presume). Great, now we know how to read and write dragcubes. But how in hell we scale that damned thing? Well, it's more or less intuitive. If I have a part with 3 times the size of the reference one, we need to scale the dragcube accordingly. For a part with 3 times the size, we have a factor of 3. All unidimentional values are multiplied by 3, all bidimensional values are multiplied by 3**2 = 9. So, all Areas should be multplied by 9. All Depths by 3. The Bounds Center and the dragness are not changed, and the Bounds Extends dimensions are multiplied by 3 too: Name : Default_times_3 +X A = 4.031 * 9 d = 0.7793 D = 11.34 * 3 -X A = 4.031 * 9 d = 0.2816 D = 11.34 * 3 +Y A = 4.736 * 9 d = 0.5131 D = 7.268 * 3 -Y A = 4.736 * 9 d = 0.3404 D = 6.481 * 3 +Z A = 29.19 * 3 d = 0.9493 D = 0.5587 * 3 -Z A = 29.19 * 9 d = 0.9497 D = 0.5587 * 3 Bounds Center X = -5.512 Y = 0.125 Z = -7.448E-08 Bounds Extend X = 11.33 * 3 Y = 7.823 * 3 Z = 0.9217 * 3 or: Name : Default_times_3 +X A = 36.279 d = 0.7793 D = 34.02 -X A = 36.279 d = 0.2816 D = 34.02 +Y A = 69.624 d = 0.5131 D = 21.804 -Y A =69.624 d = 0.3404 D = 19.443 +Z A = 262.71 d = 0.9493 D = 1.6761 -Z A = 262.71 d = 0.9497 D = 1.6761 Bounds Center X = -5.512 Y = 0.125 Z = -7.448E-08 Bounds Extend X = 33.99 Y = 23769 Z = 2.7651 Shoving these wall of numbers into a config: PART { url = Squad/Parts/Aero/airlinerWings/MainWing/airlinerMainWing_times_3 DRAG_CUBE { cube = Default, 36.279,0.7793,34.02 36.279, 0.2816, 34.02 69.624, 0.5131 21.804, 69.624,0.3404,19.443, 262.71,0.9493,1.6761, 262.71,0.9497,1.6761, -5.512,0.125,-7.448E-08, 33.99,23769,2.7651 } } As we can see, all of this is very simple, straightforward and intuitive. In time, this is for @ColdJ: You can define a dragcube to be used under water. From the part I used as example above: PART { name = airlinerMainWing module = Part // Yada yada yada MODEL { model = Squad/Parts/Aero/airlinerWings/MainWing } DRAG_CUBE { cube = Default, 4.031,0.7793,11.34, 4.031,0.2816,11.34, 4.736,0.5131,7.268, 4.736,0.3404,6.481, 29.19,0.9493,0.5587, 29.19,0.9497,0.5587, -5.512,0.125,-7.448E-08,11.33,7.823,0.9217 cube = BuoyancyDragCube, 4.031,7.793,11.34, 4.031,2.816,11.34, 4.736,5.131,7.268, 4.736,3.404,6.481, 29.19,9.493,0.5587, 29.19,0.9497,0.5587, -5.512,0.125,-7.448E-08,11.33,7.823,0.9217 } buoyancyUseCubeNamed = BuoyancyDragCube // Yada yada yada } Note that BuoyanceDragCube is the exact Default one, but with the dragness multiplied by 10 (number pulled from my hat, just to make a point). Your main problem is that you will need to have the DragCubes precalculated on the part config itself, as when you define the DRAG_CUBE KSP will not do it for you, and you don't want the dragcube used for water to be used on the atmosphere. Cheers!

This is happening due some DLL borking into an Exception while loading the craft. This kills the thread prematurely, lefting behind a lot of unfinished business. Sometimes one of these unfinished business is something you can see (as not loading the craft partially or completely). There're a lot of Exceptions scattered on your KSP.log, but the following ones are the my current suspects for your problems: Uploading Crash Report NullReferenceException: Object reference not set to an instance of an object at UIPartActionControllerInventory.UpdateCursorOverPAWs () [0x00082] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 at UIPartActionController.Update () [0x00000] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) (Filename: <39c0323fb6b449a4aaf3465c00ed3c8d> Line: 0) Unloading 6 Unused Serialized files (Serialized files now loaded: 10) KerbalEngineer -> Exception SimManager.StartSimulation() // System.NullReferenceException: Object reference not s at KerbalEngineer.VesselSimulator.SimManager.StartSimulation () [0x00054] in <134deb60e87843589b7ea1a020650b28> (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) And also, besides I thinking not being directly related to your problem, you appears to have Scatterer installed twice on your rig: [Scatterer][Error] Destroying duplicate instance, check your install for duplicate scatterer folders, or nested G (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) But it's a guess, I'm just taking the hint of the message as real. It may be a false alarm. Problem : I didn't ever had any of the first two exceptions above, and I don't have the slightest idea about what can be happening. In special, the PAWs one is puzzling. So what follows is a bunch of educated guesses, that may or may not help on diagnosing the problem. 1) The PAWS problem may be relate to KSPCommunityFixes. I remember reading that they was changing things on the PAWS, and so a borderline situation that was being tolerated before may be being missed at all on the new code, and it may explain this problem. 2) Something is screwing up Kerbal Engineer (probably due the previous Exception). So, in order to realise what's happening in fact, we will go to a UNINSTALL fest. But to do it safely, you need to fully backup everything (do a CTRL-C + CTRL-V on the KSP root folder) and then mangle only the backup. On every test, you remove the backup and do it again from scratch - and you never touch the original KSP. Ok? So: Attempt 1: Remove KSPCommunityFixes Remove Kerbal Engineeer Fire up the backup KSP and try to reproduce the problem If the problem happens again, then that two guesses of mine above are wrong, and so I will need the new full KSP.log (Player.log doesn't have all the information I need easily findable!) to inspect it again and try to find new suspects. Good hunting!

It's work in progress - Real Life™ is bitting everybody's SASes lately. We have a pre-release available here: https://github.com/net-lisias-ksp/AirplanePlus/releases Both!

These are not mutually exclusive choices! I can be right without necessarily meaning he's wrong - and vice versa! It's a follow up, being advertising as a follow up and intrinsically tied to it. There would be no KSP2 without KSP1 - for the best and for the worst. But someone will lose. People working on it will be reallocated or perhaps fired. Investors will pretty angry by losing the money invested. Carers may be tainted. And so goes on. KSP (being 1 or 2) got a lot of visibility on the STEM world - lots of people telling us that they choose STEM because KSP. Some of them on Boeing, do you wanna bet? Exactly my point - these things are rare, it's very difficult to get this kind of traction on any industry. You can't assume you will manage to do the trick again on your next franchise (ask John Romero about Daikatana). And, as always in life, things can be a bless and also a curse. You screw it up, lots of people will be less than pleasant with you (as the investors I talked about previously).

"That's was a thunder, an avalanche or did you farted again on the open mic, Jeb?" https://mars.nasa.gov/mars2020/participate/sounds/

It's not "just a game". It's a cultural phenomena. Additionally, it's the source of incoming for a lot of people, there're people feeding their families with the incoming from this product. There're investors betting big money on it - lots and lots of people that are expecting to make a living with this "just a game". Things will get a lot better when the "it's just a game" downplaying ceases and people start to realize that this is a real product, with a big budget and a lot of money invested on it. Just like Starliner, by the way (save the budget, of course! ).

"bada-been, bada-boom!" Incredible hand made machine, a big rig camper with 9 wheels and 4,000 pounds - build around a Harley-Davidson! For more information: https://jalopnik.com/this-harley-davidson-big-rig-camper-has-9-wheels-and-we-1848309413

Looks more as none of them, to tell you the true. On Stock parts (and most add'ons), this doesn't happens. On a wild guess, I think you may have a similar problem as this one: Procedural Parts and (IRRC) BlueDogBureau also have similar problems. Procedural Parts have a fix currently under validation (see this post for a beta release of the patch), but Tantares and BDB are too big for me solving their problems by myself. In a way or another, for the problem on VAB: It may be related to the first time AttachedOnEditor is run on the part - when it needs to initialise its data structures. However, when this is happens inside Editor, the Editor bug have precedence. By manually fixing the craft and saving it, things will be fixed forever (unless you uninstall AttachedOnEditor and install it again later, when the process needs to be redone) It may be related to one of the add'ons I mentioned above (or perhaps a new one?) I will need a minimal craft where the problem happens and your KSP.log for further inspection. About your second problem, I think it may be related to installing AttachedOnEditor on a living part - but I remember testing this use case before. So it also may be related to one of that add'ons (or a new one) I mentioned above. I will do a quick test here and edit this post with my findings. ---- POST EDIT ---- NOPE. I had removed AttachedOnEditor DLL (essentially forcing its removal from anything being loaded), fired up a potentially affected vessel into Launchpad directly (to avoid being screwed up by Editor), saved the game and quit it. Then I restored KSP-Recall integrity, fired up KSP, loaded that save game (what would shove clean, uninitiated AttachedOnEditor modules on everything) and could play it normally. No misbehaviour found on a Stock only game. I think it's reasonable to conclude we have a misbehaving add'on on your rig, being it PP, Tantares, BDB or perhaps a new one. Send me a craft file with the problem and your KSP.log. Cheers! — — NOTE TO MY FUTURE SELF — — This case was handled on PVT and the case is closed.

I remembered playing this game as young, I loved this OST. (Batman Returns - Sega-CD)

You can edit the savegame directly- it's what I do, by the way. I described how to do it on this post: Remember to make backups!

Nope, the dimming is only applied to the skybox. Planet blinking and skybox dimming are, currently, completely different and independent modules. In a way or another, I opened a issue so I don't forget to look on it when I (finally) have time again for development. Feel free to add any considerations (as space photographs with the phenomena) to it! https://github.com/net-lisias-ksp/DistantObject/issues/20 Cheers!

There's nothing I can add to this picture!! https://www.motor1.com/news/588343/classic-volkswagen-bus-half-track-monster/

ANNOUNCE Release 2.4.6.15 is available for downloading, with the following changes: Well, it’s a bit embarrassing but I finally detected and fixed a regression on legacy support I inadvertently did when I removed the kludges I made on TweakScale when KSP 1.9.0 was launched. Long history made short, when I added that kludge, I broke support for [1.4.4 <= KSP <= 1.7.3] and then added another kludge to counter act the first kludge. Once I removed the 1.9.x kludge and moved it as a proper work around into KSP-Recall, I forgot to remove the second kludge… As a side effect, less Scaling Engines are needed now, so we have one less DLL to worry about. Additionally, yet another stupidity was detected and fixed on handling Variants (and this one was pretty old…) Closes Issues: #249 Reorganize the Scaling Engines See OP for the links. This is a follow up for the latest NOTAM, so I will not copy&paste all that wall of text here. This release mainstreams the fix published on the latest TweakScale Beta. Additionally, I found a new misbehaviour from KSP Editor while handling Variants - the GameEvents.onEditorVariantApplied callback is being called more the once, and apparently the first time it's called after attaching a part, both part and partVariant parameters are being sent as null!!!! (I didn't bored to verify exactly when this misbehaviour started to happen, I will let this to be done some other day). As nothing is so embarrassing that could not be more embarrassing, while checking this new misbehaviour I found a fishy code that at the time I wrote it it looked like a good idea, but right now it is only adding a failure point without a real benefit (it intended to save some processing, but this is not really needed on Editor). So I removed that check and now you don't need to select the Variant before scaling to have the right attachment points available anymore - or switch variants to something else and back just to get the nodes fixed. On the bright side, this time I detected the problem myself. Disclaimer By last, but not the least... — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users).

I just can't believe they really did it!!! Source. Okey, it's a model kit. But they kinda did it… https://www.fliskits.com/WPRESS/product/acme-spitfire/

Hi! I think the problem is a missing dependency: [ERR 20:21:21.501] [AssemblyLoader] Exception when getting assembly attributes: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. Additional information about this exception: System.TypeLoadException: Could not load type of field 'JanitorsCloset.JanitorsClosetLoader:Log' (0) due to: Could not load file or assembly 'KSP_Log, Version=0.1.1.7, Culture=neutral, PublicKeyToken=null' or one of its dependencies. assembly:KSP_Log, Version=0.1.1.7, Culture=neutral, PublicKeyToken=null type:<unknown type> member:(null) signature:<none> Janitor's Closed need a thingy called KSP_log, but it's not installed. Reach Janitor's Closet for more information, he is the one that can pinpoint exactly what's missing on your rig. Link this post to him to save him some time. Cheers!

You were bitten by a nasty KSP bug on the Assembler Resolver thingy yada yada yada . TL;DR. when something borks being loaded due a faulty dependence, everything else trying to load something (or to use a thingy called Reflection) borks relentlessly due the bug. And since TweakScale makes heavy and critical use of exactly these two things. TweakScale yells when it detects this happened (because a faulty TweakScale will ruin your whole savegame). Publish your full KSP.log (see the Spoiler at the end of the OP for instructions) on dropbox, google drive or something. By inspecting it I will be able to pinpoint who is the troublemaker on your case. Cheers.

Nice catch - kinda obvious, but I missed that! Neither the U2, by the way - for similar reasons, that huge wingspan (and the need to fly near the coffin's corner) Being the reason I think this craft may be a R&D for some military/strategical purposes. On a blind guess, I think they need enough solar panels for both charge the internal batteries to keep it flying without direct Sun light for some time and also to power the engines at the same time. Humm, reading again the article, I found that it circumnavigated the globe in 2015… So it had to fly at night, only on batteries. I think this explains the size of the thing, it's all batteries!

Publish your KSP.log (you will find this file on the same place KSP.exe is) on dropbox, googledrive or something and I will inspect it. 99% of chances that you were bitten by a nasty KSP bug on the Assembler Resolver thingy yada yada yada . TL;DR. when something borks being loaded due a faulty dependence, everything else trying to load something (or to use a thingy called Reflection) borks relentlessly due the bug. And since TweakScale makes heavy and critical use of exactly these two things. TweakScale yells when it detects this happened (because a faulty TweakScale will ruin your whole savegame). There're 1% of chance that you forgot to copy a file, and at least once I published a package with a DLL missing (shame on me), so it costs nothing to check for the mentioned file on GameData/TweakScale/Plugins/PluginData folder. See if the new patch I'm beta testing does a better job: https://github.com/net-lisias-ksp/KSP-Recall/blob/master/GameData/999_KSP-Recall/patches/101_ProceduralPartsAttachmentNodesFix.cfg Hummm… better. Let's simplify that a bit: @PART[*]:HAS[@MODULE[ProceduralShape*]]:FINAL { @node_stack_top = 0, 1, 0, 0, 1, 0, 1 @node_stack_bottom = 0, -1, 0, 0, -1, 0, 1 %xxxValue = #$MODULE[ProceduralShape*],0/length$ @xxxValue /= 2 @node_stack_top,0[1] = #$xxxValue$ @xxxValue *= -1 @node_stack_bottom,0[1] = #$xxxValue$ -xxxValue = dummy } This generic patch should work on any part based on Procedural Parts that are stackable (I just found like these until the moment). If it doesn't works, ping me here again and I will eyeball the problem As Soon As Possible®

Well… I came from the car industry too (after jumping ship from the Mobile). And I know something for sure - anyone on the* team being caught mistreating a potential customer the way I saw happening on this thread would have some serious problems on his/her employability. You just can't point your finger into your customer's nose yelling "I'm a professional on this field and you are not" and expect to keep their money - even when you are right, what's (frankly) not too common: the customers know their problems better than you, they have problems on communicating them to you. Boeing is giving us a hell of a lesson about how to cope with criticism. I suggest we listen to these guys, they are the real deal.

A fantastic real-life use for Infernal Robotics! Ping @Ben J. Kerman !!

Hail Boeing, uh… Probe! Jebediah finally gone to Space! In one piece! https://www.engadget.com/boeing-starliner-kerbal-space-program-jeb-212326380.html Congratulations, dude! Jeb is on ISS now! (skip to 4:06)

So it was organic and expontaneous? I'm impressed!

Believe me, I know! Believe me, I don't care!!! It's funny to remember now, but at that time I got sick with the motion. It's like sailing on rough seas!