Lisias

I think it is, but I can't promise you a deadline for it! https://github.com/net-lisias-ksp/DistantObject/issues/26

Yep. The Italians also operated the F114, with way less accidents. About 155 from 1964 to 2002, from a total of 359. About 4 per year in average. The Germans lost 298 from 1961 to 1989. About 10 per year in average. More than twice. But the Italians operated way less airframes than Germany, so the loss rate was sensibly higher - ~43.17% for Italians and ~32.52 for the Germans. About casualties, 69 Italian pilots were lost, or 69/155 = ~44.15% of the crashes killed the pilot. For Germans, the rate is ~39.38%. So even with corruption and all the lack of training documented over the Net, the germans managed to do a bit better than the Italians overall. So, yeah… It was a dangerous plane. Still a formidable one, but dangerous nevertheless. A fart detector using sound waves?

I would like to have any potentially prone to litigation technics away from this thread. We already had this discussion before. I would prefer you would talk about these matter in PVT messages or other threads, please.

Got a little break while paying some bills, and made a quick test. It's still too premature to be absolutely sure, but apparently the error on TweakScale is mangling the buoyancy attribute from PartModule. So, my previous statement are still valid: TweakScale is scaling the dragCubes the right way, and mangling with them in order to force a desired behaviour will mostly certainly screw up something else. What doesn't means that we should not toy with the idea. While thinking in what you had proposed, I came to the conclusion that even by not pushing it into the mainstream, there's no reason to do not allow a configuration to change the scaling of the dragCubes in the same way there's a configuration option to mangle the buoyancy. It's a mistake to use it if you want stock like behaviour, but hell - why prevent people from doing crazy things if this is what they would want? @ColdJ add'ons may be directly beneficed by it, as it appears. humm… I just called @ColdJcrazy!!! It was not my intention… This time. I understood. My point is that without knowing exactly how all the aspects of the DragCubes affect the game's physics engine, mangling them to induce a behaviour will fatally create undesired side effects somewhere else, usually on something you will not detect immediately. Been there, done that - and not only on TweakScale (I'm not new on this modding thingy). I have a Beta version of TweakScale running for two years exactly because of that - most features on Beta I wrote 1 year ago is only now reaching mainstream. It's perfectly possible that you are not wrong on assuming you can mangle the two or single dimensional attributes from the DragCube in order to induce a new behaviour - and, in fact, this idea appears to be too damn good to let it pass without a try first on the Beta program. But I'm extremely reluctant on shove this thing into mainstream without a lot of testings - and, most of all, will not do it as a regular feature on the standard patches without an absolutely compelling reason (like someone pointing a gun on my head). I stand corrected at the same time I still withhold what I said. For @ColdJ I think things would not gone south that way under a buoyancy equal to 1. See the exponent as the how many dimensions you want to scale: 0 = No Scaleing, 1 = Linear Scaling, 2 = Quadratic Scaling, 3 = Cubic Scaling, anything else = going extraterrestrial, metaphysical or doing a Leap of Faith without a hailstack downthere. But you are also correct : an exponent == 0 will effectively disable scaling the attribute, and this is apparently the correct way of fixing the buoyancy of the scaled parts! I have no problem on doing crazy (and sometimes stupid) things. I'm only reticent on pushing them into mainstream without some time on QAS first - and even by doing that, I got bitten in the SAS more than once. The idea of mangling the dragcubes by TweakScale is not bad, not bad at all. Using it to solve a problem that I think should be fixed in an orthodox way is the problem on my book. I think @ColdJ was bitten in the SAS due the way he mangles the dragcubes on the new parts - in order to force the buoyancy he needs, he gone the dragCube way. Since he is going nautical and/or subnautic (is there such world in English?), the stunt worked fine for him - and nobody is going to make a flying Titanic anyw… Hummm… belay that, this is KSP, of course someone will try to make a flying Titanic, Doctor Who style!!! Allons-y, Alonzo!!! Ahhh, that's the point!! I wasn't willing to use your idea to fix the part's buoyancy (unless not other alternative was possible), but I liked the idea of allowing users to mess with the dragcubes scalings! I just will not use it on the standard patches but, hell, someone will have fun mangling them once I implement it somehow, I'm absolutely sure! In a way or another: https://github.com/net-lisias-ksp/TweakScale/issues/267 https://github.com/net-lisias-ksp/TweakScale/issues/252 Cheers!

I will try to find it out. TweakScale only mangles the PartModule's "this.part.DragCubes.Cubes" thingy, if there's more to be scaled, I need to know! (not, it was not me - or I need to see a geriatrician! ). Cheers!

Setting the buoyancy to 0 is the same as removing the buoyancy from the ScaleExponent. Once I confirm the information from my side, the fix appears to be pretty obvious - don't touch the thing! Exactly. The dragcubes is used to help infer approximated volume, not the buoyancy value! Thus buoyancy thing plays a role, but not on volume! I think we are clashing on nomenclatures! I will try to graphically differentiate the real life concept "buoyancy" from the PartModule's buoyancy atribute from now on. Anyway, by mangling the dragcubes, we will be mangling the volume of the scaled part - something that by all effects, appears to be being done right. One way to confirm this is to brute force scale a part into a new part by hand, and let KSP automatically compute the dragcubes of that part, then scale the original part the same using TweakScale, and then launch a craft with both parts and compare the dragcubes. I think ObjectInspector may be of help on this task. Whatever KSP does to compute the dragcubes of the handmade part, TweakScale needs to follows suit on the scaled part. Point. Doing it differently will make the part misbehave once scaled. — — — I'm not dismissing the remaining of your post, I just don't have time right now to further explore it - so I rushed some thoughts that I wanted to highlight in advance in the hopes of saving some time in the mean time. Cheers!

Hummm… Interesting. Thanks for the trials! Hum… now you caught me with my pants down. What's `buoyancyUseSine` ? Sinking while setting it to zero makes sense, anything elevated to the 0 power is 1.0 and this is too low for the part. Setting it to 0.1 , on the other hand, surprised me. That part must be really huge to such a difference in the behaviour. Humm.. They should, as negative exponents are, in effect, roots. x**-2 is the same as the sqrt(x) . As a general rule I tell people to avoid negative exponents because small enough numbers can lead to a 0 after rounding, and you don't want it on calculating mass, for example! (been there, done that!! ), but in some other atributes is can make sense. So @damerell appears to have a point! Thanks! As soon as I have one, you will be one of the first to know! Hummm, ok. I had misunderstood you. Sorry for that. I think I'm seeing your point, but your point assumes that buoyancy is related to volume, and we don't have evidences that this is how KSP works. The @ColdJexperiments appears to suggest that, in fact, it's not. Jumping into conclusions is not something we want to do, it's something we unattendedly do sometimes. Kraken knows how many times I had done it on TweakScale in the past! I'm not trying to dismiss you, I'm trying to alert you from doing the same mistakes I did in the past! But you are not wrong, anyway. Changing the drag cubes will affect the flight behaviour for sure. You can hit F-12 to show you the force vectors then you can check the red vectors comparing between scaled and uscaled parts! Blue vectors will show you the lift. Yellow will show you the control surfaces forces (you will find that some parts don't give you lift, only "control surface forces"). I wish I had hit F-12 when I made this test, so I could better demonstrate the feature to you! Sure thing! But first I will need to know if you will be able to interpret the results, because otherwise I would be digging deeper the hole instead of working to fix it. There're a lot of experiments I think you need to do in order to be able to compare the results later, otherwise you would be too much prone into jumping into conclusions without being aware of that. As i did in the past. To tell you the true, I had completely missed this one. Really, I never really noticed this exponent before - I'm usually chasing game breaking problems, and these small details usually pass trough. It's the reason I usually try to reserve some quality free time to be pure R&D, without worrying about bugs or anything else - of course, always pending RealLife™ agreement. Anyway, @ColdJdid some pretty interesting test in advance, and they appears to suggest the buoyancy is not related to volume - things would not had gone south otherwise when using a buoyancy exponent 1 (or just removing it from the ScaleExponent). An interesting information is wheels floating even when using a 0 on the exponent (what would force the buoyancy to 1.0), so there's something else being used to calculate the "effective buoyancy", and you may have a point on suspecting the dragCubes. But even by being right, we need to balance the consequences. DragCubes are pivotal on atmospheric flights, and we may screw things badly by trying to mangle them to force a behaviour on a secondary feature. In the end, I really think the best approach is indeed took by Firespitter - just get rid of stock buoyancy and apply your own solution - that will work perfectly fine with TweakScale by installing TweakScale Companion for Firespitter.

Welcome! Don't mind, it was not a problem. I had assumed you wanted to automate your installation somehow - some add'ons use to have a "DLL only" distribution file, and by the description of you problem it made sense to build one. Automated tools rarely are smart enough to allow you to remove parts of the package, they usually just unpack the ZIP over the GameData and call it a day. "Float safe". Cheers!

We are not scaling blocks of concrete. We are scaling Parts, complex things with many different components with different "densities" (in quotes, as this is not really how KSP works). We don't take a part half-wood and half-iron and scale it as it was made only on iron. The way you can simulate such scalings are by (ab)using the Scale Exponents. KSP doesn't simulate the (hypothetical) internal components of a part, anyway. Take a Crew Cabin: it have lots os empty spaces, some seats, a bit of glass, lots of structs made of light material, etc. So we can't just scale everything up to the power of 3 and have something that could be used to build things more or less similar to something on real life. The same for engines: an airplane cabin does not have the same average density as a turbo-fan engine (besides both of them floating on KSP - with or without TweakScale). So we use a 2.5 Exponent to engines and a 2 Exponent for crewed parts and call it a day. The values are approximations far from the real life, but they are good enough for the purposes of this game. So the Exponents are used to scale the part's characteristics in order to have some resemblance with the real life counterparts. For simplicity, we have essentially free, free_square, stack and stack_square scale types with predefined Exponents. The *_square ones use a 2 Exponent, the other ones use a 3. Scale Behaviours are used to force a different exponent when applicable (as engines that are scaled on a 2.5 Exponent). Please note that the Exponent used to scale mass don't need to be the same one used to scale thrust, or ISP, or even toughness. You can tinker with different exponents on different attributes to make scaling relevant and challenging - you earn something but also lose something by scaling, what would be the best compromise for a given design? Way more challenging that just dumbly scale everything up or down using the same factor - life doesn't works this way. And there's nothing blocking you from toying with different ones to see what you get, as 3.5 or 1.75 - including values under 1.0 (but always above 0). You will have some fun toying these values - I surely did! On the stock patches, Aero parts and Cabins are usually scaled with the 2 Exponent because it was found that using 3 made the parts (excessively) unrealistic heavy (let's ignore the whole game physics is anything by realistic! ). Same for engines, that as I said are scaled by a 2.5 Exponent. Science also have a specific Scale Behaviour for them, as well Resource Converters and Decouplers. You may want to toy with the ScaleExponents instead of compiling TweakScale to meet your needs, you can toy this file https://github.com/net-lisias-ksp/TweakScale/blob/master/GameData/TweakScale/patches/020_ScaleExponents.cfg You will find some needed information on the files on this directory: https://github.com/net-lisias-ksp/TweakScale/tree/master/GameData/TweakScale/Docs I think it's too soon to jump into conclusions, you merely scratched the surface of the problem. There's a lot of scale factors to toy with before breaking scalings by removing code. See the links I posted above. I also ask to pay some attention to the thread I linked on my previous post, this is hot information from the game developers themselves, it may be of use while wondering why things works the way they works. In fact, while inspecting the files in order to suggest something to you, I think I had may found why you concluded that the buoyancy is being scaled to a factor of 16! Try the following patch and see if things change to you: @TWEAKSCALEEXPONENTS[Part] { %buoyancy = 1 } If it works the way I think it works, we may have found the problem for the crazy buoyancy on TweakScale! You may also want to try something pretty near 0 on it (something like 0.0001) to see what happens. I found that the buoyancy's exponent was set to 3 on a pretty anciant commit, from 2014 (0.23.5!!) and was never touched again since then... Well, you may had leaded me to the right path after all! I have a proposal for you: toy with the exponents I explained above (and with the buoyancy one above all) and see how things behave for you. I will do it from my side as time allows. In the weekend we try to find a way to chat about our findings and see if mangling with the drag scaling is really needed - I'm suspecting it is not, but if I'm wrong, I will cook a specific exponent to be applied to the drag cubes and so people can make their own choices about it.

All parts are scaled the same. What changes are the exponent (**3, **2, **1.5 - yes, you are not limited to 2 or 3!). The 4th item appears to be the faulty one. There's also this buoyancy attribute on the PartModule (not sure since when), but I don't know anything about it - not even if it really works. You may also be interested in seeing how Firespitter implemented buoyancy to see how it was implemented, it virtually destroyed the stock Buoyancy in order to do its business. You may also want to see this thread: In special the quote below:

Can't open this one. Damn. These are not ordinary tires, these heavy cars of that past were heavy as a truck - that tires need to withhold a lot more of abuse than the tires of nowadays cars! Yep. A friend of mine used to own a Landau : And dude… That car WAS HEAVY. His worst problem wasn't the fuel consumption (he owned a gas station IIRC - or perhaps a relative, I don't remember), it was to find tires for the damned thing. My truck used tires with a similar certified load, by the way. And, yeah, that truck had the very same dry weight as the landau above!

I could not explain it better! That's the thing: there's a value on the PartModule that I found but didn't understood yet, "buoyancy". I hope it is used somehow together the drag curves to calculate the buoyancy - but I need time to do some R&R, I mean, R&D on the matter. The time we realise how (or if) this "buoyancy" thingy works, will the time (assuming it works…) we will be able to do proper ship parts - and to scale parts without messing up the buoyancy!!!

Because Buoyancy is related to density, not volume. And the drag curves are scaled as the volume scales. For example, 1m³ of wood will float but 1cm³ of lead will sink. However, on KSP, there's no density on the parts - just the drag curves being reused to define how the part will float over water (and only over water - different liquids would give you different buoyancy for the same part, but on KSP we are all locked into water to handle Buoyancy). Since TweskScale needs to scale the drag cubes, otherwise you would have drones with the drag of a Boeing, and Jumbos with the drag of a Cesna, the currently unavoidable side effect is the buoyancy being completely screwed up as the video I post demonstrates. I need to find a way to compensate the Buoyancy as the part is scaled up and down in order to keep the same Buoyancy of the default part as the part scales. So I need to understand how the drag cubes feeds the Buoyancy calculation so I can compensate it on the other side - and using the weight is not an option.

1978 Star Streak Motor Home. I still trying to figure out what to think about this… More info here: https://www.autoevolution.com/news/the-star-streak-is-how-you-turn-a-cadillac-eldorado-into-a-fancy-motorhome-181778.html#

Good! PatchManager (and, most of the time, everybody else) was probably just the trigger. If you really want to use it, I suggest to temporarily uninstall MJ2 (so the diagnosing is easier), install PatchManager, make it work and then install MJ2 back. It's how I managed to diagnose weird things when MJ2 is installed (again, not because MJ2 is the troublemaker, but because somehow I changes how things are logged and this affects negatively my diagnosing). Well… This is another long story. So TweakScale now only officially supports Stock and (most of) Expansions. Everything else is now (or hopefully will be Soon® ), officially, on a Companion. You will find the current ones here: https://github.com/net-lisias-ksp/TweakScaleCompanion Currently, only manual installation. Add'Ons that rely purely on stock PartModules will work fine with a few lines of code on a MM Patch. The hard part is doing things in a way that make sense and it's useful - just shoving type = free on everything is a useful hack most of the time, but having proper ScaleTypes that makes sense does a better user experience, so it worths the trouble to make good patches. Please check the Companions, I like to think I did a good job on the Patches for the SCME one by way. In the mean time, All Tweak is a nice workaround while I don't provide the patches you want for the add'ons you use. And a new bonus on the more recent TweakScale releases is that I finally understood where KSP had changed on some primordial levels and could resurrect some very nice features that you probably had used on 1.3.x era, but I had to deactivate since 1.4.x - and this includes the ability to seamlessly adapt the scaling if a part when you change the patches. So using All Tweak is not only a convenient workaround, but also safe nowadays (some time ago I had to tell people using All Tweak that they could not install new patches on ongoing savegames - pretty annoying). Check all the Companions and install the ones that provides the support you need. And you can file suggestions on this link: https://github.com/net-lisias-ksp/TweakScaleCompanion/issues Don't bother trying to guess in which Companion you should file the suggestion - I will sort it out later this year when I will have another time window for coding on KSP again! Easy, yes. Convenient and useful, not always. Try All Tweak above for parts relying solely on Stock PartModules (or PartModules that I have already wrote a ScaleType) - don't use it on add'ons with custom PartModules (or without proper ScaleTypes), they will not scale correctly and sometimes will even break. On the bright side, once proper TweakScale support is added, AllTweak automatically steps aside for the new patch and things will usually work fine with the resurrected patch migration - at least, I didn't found any problem with it yet. There're some Stock Parts that I'm struggling to support due a lot of bugs they have - Robotics, to be more specific. The Serenity's Robotics are very nice parts, but unfortunately they are pretty buggy too. But you can try your luck with the TweakScale Beta and, if you are really, really brave , you can activate the Experimental patches on Beta by creating a Directory called "TweakScaleExperimental" on GameData. I don't know how Infernal Robotics are behaving nowadays - proceed with caution. I know that without Breaking Ground the IR/Next fork worked fine some few KSP versions ago. You will probably want to check KerbalJointReinforcement/Next too. Let me know if you need any assistance. Jumping from KSP 1.3 to 1.12.3 is a hell of a Endeavour , and since I still do support everything down to KSP 1.3.1 (and one or two things even on KSP 1.2.2!!!) I'm pretty sure I can be of some help on this Enterprise . (late night, infamous jokes can't be contained anymore!!) Cheers!

Yes, this is an issue indeed: you need to delete the doppelgänger DLL to prevent trouble (my last post explains in details why this is terrible). The only Scale_Redist.dll that should be allowed to be loaded by KSP is the GameData/999_Scale_Redist.dll one. Cheers!

Oukey, I'm finding my way on the mess. For starters, I need to do a better job on reporting problems o MMWD, a few more line of code and you could be able to help yourself on this one. Delete this file: [LOG 14:17:14.323] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\MagicSmokeIndustries\Plugins\Scale_Redist.dll The only "good" file is the "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\999_Scale_Redist.dll" . Let me explain to you and everybody else why this is happening nowadays (on a spoiler if you don't want to read it): Your second problem appears to be PatchManager: [LOG 14:17:14.378] AssemblyLoader: Loading assemblies [WRN 14:17:14.380] AssemblyLoader: Assembly 'PatchManager' has not met dependency 'ClickThroughBlocker' V1.0.0 [WRN 14:17:14.380] AssemblyLoader: Assembly 'PatchManager' has not met dependency 'ToolbarController' V1.0.0 [WRN 14:17:14.380] AssemblyLoader: Assembly 'PatchManager' is missing 2 dependencies It is triggering that Assembly Loader/Resolver bug on KSP I mentioned above. Remove PatchManager and see if it solves the problem. If not, send me a new KSP.log and I will keep digging - you have MechJeb2 installed and it somehow mangles a bit how things are loaded, and then my diagnosing tools are not reliable. Usually , the first DLL to throw a ReflectionException are the trigger of the problem, but when MechJeb2 is installed this is not always true anymore. Additionally, your KSP.log was truncated before the Main Menu being shown. This happens because KSP has an internal buffer to avoid hitting the hard disk all the time (what would make things slower), but the price we pay for it is that it takes some time until the internal buffer is flushed into the file. Usually it's better to quit KSP before copying the files - or alternativelly starting some disposable savegame (or just a new bogus one) and then copy the KSP.log file later, as by then the new log entries had already forced the ones I'm interested to be flushed into the file! Cheers!

I had put it on the backlog, unfortunately pending Real Life™ agreement. https://github.com/net-lisias-ksp/TweakScaleCompanion_FuelSwitches/issues/5 I completely understand you. I'm still playing on 1.4.3 on some savegames… Well.. The mess is not from TweakScale. It happens that KSP has some internal bugs that, unfortunately, were being downplayed by the developers and also by some relevant add'on authors, and when some of these bugs bites TweakScale, it is rendered ineffective. And when this happens, all your scaled parts are screwed on savegame loading - for good. If you are on the gory details mood, search for "Assembly Resolver/Loader". Please note that this affects EVERYTHING, not only TweakScale. Anyone, absolutely anyone that have a custom data into the PART gets screwed when it's bitten by these KSP bug. It only happens that TweakScale is checking for the problem and yelling when it detects it, preventing you from loading and corrupting your savegames. Humm… There's a bug on ZeroMiniAVC (I think) where it's checking for duplicated DLLs where it should not - anything inside a directory called PluginData is plain ignored by KSP, and I use this place for integrity checks and seamless updates. This is unfortunate, because the alternative will be to obfuscate these DLLS, and this is really bad because it's how viruses work and I don't want to risk being flagged as one. Please send me the KSP.log so I can check this for you. I think you have multiple problems happening at once. Please send me your KSP.log using dropbox or similar service - don't try to copy & paste it here, it will screw up Forum, and it will be truncated anyway, rendering it useless. Yep. I know of some users that install TweakScale only for the safety checks, completely ignoring the feature itself (I think one of them even deleted the patches… ). KSP is being plagued by multiple bugs for years - did you know that if you have more than one ModuleManager installed, the oldest one is used instead of the newer one since KSP 1.8? This are that bad, and it's the reason WatchDog and TweakScale are extremely picky about things. There's no "simple solutions" anymore, people going to the easiest path are making things worse. Many things had changed. Some tricks that used to work in the past now cause problems - it's five years of piling changes to cope with…. If you have a somewhat older rig, I suggest you read these two threads two: Buoyancy apparently was an afterthought on KSP, as the drag cubes were used to simulate it. Problem: I need to scale the drag cubes, otherwise the parts will have a very unfair drag, so it's a catch22 situation for now. I demonstrated the problem on this video: I have a task for it here: https://github.com/net-lisias-ksp/TweakScale/issues/252 (pending Real Life™ agreement, unfortunately…) You are right in the sense it's not (at 99.99% of the time at least) a problem on TweakScale, however TweakScale is deadly affected by it, so I had to code that "Houston" thingy to prevent users from losing the savegames. (again, I want to stress out that TS is not the only one suffering - but it's the only one complaining about, as it appears). Publish your KSP.log on dropbox or something, please. I think I need to inspect this one. There're safeties coded on MMWD that may be at jeopardy due this, and if this is the case, I unfortunately will be forced to code a less than sympathetic counter-measure - or hell will be unleashed on me again!

@JonnyOThan nailed it. Thanks dude! Well… yes, there's. On older computers with GPUs with 1G RAM (or even less), KSP 1.7.3 is the last one that runs reasonably fine. From KSP1.8 to KSP 1.11.x we had a lot of new bugs that may hinder the gameplay for some people, but the real problem is the textures. On KSP 1.12.3 the textures are so too big for anything using a shared memory GPU with less than 2GB of VRAM (my case, by the way), so you need to lower the Texture Quality to a point that the part of the User Interface become ridiculous - not to mention that all the textures will be downscaled, not only Squad's - and so all your perfectly fine add'ons will be ugly as hell. I talked about the issue here. And this is the reason I'm still using KSP 1.7.3 on some of my savegames, and - try to to laugh - 1.4.3 on some others. KSP 1.4.3 is simply the best somewhat modern KSP that runs perfectly on my i7 MacMini with Intel HD4000 GPU. From KSP 1.8. things just got downhill for me.

I see no reason for me not doing it, but it's up to @JewelShisen the decision of how to distribute it officially - what do you think, @JewelShisen? In the mean time, on this link you will find a "NoParts" zip file that you can download and install. It's not different from manually delete the GameData/HLAirshipsCore/Parts folder on your rig, but having it available on my github allows you to automate the installation somehow. I fired it up on a clean 1.12.3 and checked if by some reason it would not bork due the absence of the parts (to tell you the true, I never tried it before, shame on me!) and found no obvious problems - if by any reason you find something wrong on using the "partless" together Heisenberg, yell here and I check it (pending Real Life™ agreement… ). Cheers!

Someone on Curseforge unadrevtidly made me remember this one (Dragostea Din Tei - O-Zone, about 2005, I think): Additionally, the singers supposedly taking a ride on a flying cargo plane on the wings is something incredibly Kerbal!!)

What I had read is that the problem they were trying to solve if that cargo planes are sitting ducks when being loaded and unloaded. By having the whole cargo bay unloaded and ferried to a safer location for loading and unloading they would minimize the risk of the plane and the cargo from being blow up into the skies on a raid. — — — Do you like Humvees? Do you like boats? Some people like them both!!! WaterCar H1 Panther.

Fairchild XC-120 Packplane . Incredibly Kerbal!!! - including on how the cargopod is attached to the main fuselage! (stack separators anyone?) More info: https://en.wikipedia.org/wiki/Fairchild_XC-120_Packplane Of course, the germans also had a similar concept, but this one never materialised: More info: https://en.wikipedia.org/wiki/Fieseler_Fi_333

Try this thing: https://github.com/net-lisias-ksp/TweakScaleCompanion_SMCE/releases It fixes some of the problems I diagnosed in the past relate to some SMCE add'ons. READ THE INSTALL INSTRUCTIONS, I had to overwrite some files from LShipParts as I couldn't find a way to fix them. It will work for the meshes for sure, and perhaps to some stock modules (assuming they look into it, of course). But it will probably not work for custom modules. TweakScale works because I write "receipts" for scaling each known PartModule in the game (it's the reason you need to write patches!). For example, I don't know if a Stock Part will have the Resources it withholds correctly scaled up, but I know for sure that Custom Fuel Switches will not - not to mention the PartModuleVariant stunt...

(sigh). Of course it's something right now on the KSP, otherwise it would be working! What's matter is what!!!! One of the problems I already had found, you have BDArmory installed twice! [LOG 12:38:41.324] Duplicate DLLs found: C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/BDArmory.dll : C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_x64_Data/../GameData/BDArmory\Plugins\BDArmory.dll And, yeah, you managed to install BDArmory directly into the GameData, instead of a BDArmory inside the GameData…. Oukey, we need to go nuclear on this one. Remove everything from GameData, except by "Squad" and "SquadExpansion". If you are willing to retry installing things manually, do not install all at once - this will make things harder as you won't know when it's something you did wrong, or when it's something someone else did wrong. Install 4 or 5 add'ons you want more. Run KSP, see if everything is fine. Then install more, rinse repeat. Once you find something wrong, you have only up to 5 suspects to check them out - way easier than all at once as we have now. Even if you choose to use CKAN, do this way: install only up to 5 add'ons at once, and roll back in the exact instant things get broken. When KSP gets broken, all you have to do is to uninstall the last 5 you installed one by one until the problem goes away. The last add'on you uninstalled before making KSP work again was the trigger (not always the culprit). Now, you can send us the KSP.log telling exactly what was the add'on that triggered the problem, and things will be way easier to diagnose! To learn how to use CKAN, try youtube (I can't suggest a video, as I don't use ckan myself). You can also look for support on the CKAN's thread.