Lisias

Huge mistake as it appears. Another one, by the way. We are coming to a point in which we will probably need to replace most of the stock Modules in order to get a decent KSP experience…

If you are doing manual installing, I reccomend you to read the INSTALL.md instructions!

Ugh. Another one. Found it on your Player log: ADDON BINDER: Cannot resolve assembly: KonstructionUI, Culture=neutral, PublicKeyToken=null (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) AssemblyLoader: Exception loading 'Konstruction': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 01000066 (from typeref, class/assembly USITools.UI.Window, USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) assembly:USITools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null type:USITools.UI.Window member:(null) signature:<none> It's a problem with Konstruction, it has a problem with one of its dependencies, USI.Tools. The USI.Tools was refactored and lost some calls that the version of Konstruction needs. I don't know if the USI.Tools you have is too "new" or too "old", you will need to reach Konstruction's Maintainer for further help. This problem is affecting TweakScale because KSP has a very nasty bug on a thingy called "Assembly Loader/Resolver" that once a problem like this one happens, everything and the kitchen's sink borks too after it, and since TweakScale is loaded after Konstruction, the triggered bug prevents TS to be loaded. Fix or remove Konstruction and things will be fine.

Junkers G-28. Passengers on the same cabin as the navigator, passengers on the wings, passengers everywhere!!! The best pictures I found, however, are from this video below:

Not yet, AFAIK.

Yep. This was diagnosed by a fellow Kerbonaut and posted on the KSP 1.12.2 release thread:

Danm, Dude! TweakScale being used by the Pentagon was supposed to be a secret!!!!!!

As long you never unlock them (what kinda defeats their purpose at first place). Everytime you unlock something, they will start to drift a bit until locked again - and these small drifts are permanent once happened, so they are cumulative. For the most simple use cases, this appears to be enough - but on really Kerbal designs, the drift sooner or later will hurt the craft: you are only postponing the unavoidable.

I do not agree that it's a Q/A problem (using the strict definition of the term Quality Assurance). Let me explain: Q/A is not about "finding bugs", it's about non-compliances. A bug is a bug if and only if there's a Requirement (being it functional or non-functional) that it's not being satisfied by the artefact. Of course, there're many ways for handling Requirements (formally or informally), but in essence, if there's not a Requirement for something, Q/A has their hands tied. The Q/A guy can report (usually internally, as formal Requirements are not usually published) any perceived non-compliance ad nauseam, the report can be easily dismissed by the Product Owner (or whatever they name the guy that call the shots on the product) as "works as specified" - and end of the history. Of course, the Q/A guy can try to file a "bug" against the Requirement itself, but not rarely this is out of scope for him - as I said above, Q/A are not the one calling the shots. And when the Project doesn't have a formal tracking for the Requirements, it's even hard to blame the Q/A for the product going downhill: without a clear and detailed list of Requirements, their calls can be easily dismissed by the Product Owner without hope of appeal. Worst, the P.O. can easily second thought things later, and this makes the Q/A guys tipping on their toes all the time: they never know for sure when they will be blamed for wasting time reporting some things and when they will be blamed by not reporting them. IMHO, the whole Development Process is flawed beyound measure, and your perception about Q/A is nothing but the most visible symptom of the real, inherent and subjacent problem.

I highly recommend Private Division to do so. I'm just the messenger, I'm not the one selling KSP1.

This is not exactly the most desirable of explanations, as this means that Squad/TT2 were deceiving us all this time. What may make them liable to a class action, more or less the same as happened to CD Projekt RED due Cyberpunk: they are intentionally selling us a flawed product. Perhaps. But this doesn't changes my previous statement - if KSP1 is flawed beyound fix, keeping them on sales are not exactly the best of the moves - at least under the legislation of some USA states. I bought KSP on the 1.3.1 era, but only started to play with it about 1.4.1 - and until 1.4.3, I was pretty happy with the product (being the reason I'm playing on this version nowadays). So I'm one customer that, well, is not really affected by current KSP problems. But anyone that bought the game recently may not think the same. IMHO, Private Division should spend a little more money with at least one good developer to tackle down the worst problems on the bug track - taking advantage that some skilled 3rd parties had even posted the solution for some of the problems there, and issue a KSP 1.12.3 release the fast as it's possible. This can be cheaper than trying to clean up the stain later, if by any reason KSP2 is launched with some bugs (and it's almost surely it will - the tracked record of the development doesn't inspire too much optimism). Actions have consequences. Lack of actions too.

Request recorded: https://github.com/net-lisias-ksp/DistantObject/issues/17 Yep, this is going to need a "new engine" for it. Asteroids, as far as I know, are a special kind of "vessel" - AFAIK it's like a debris from the physics point of view. What means it goes to rails and from it - what can make things a bit easier with a bit of luck. On a superficial analysis, it can make my life a bit easier as I think I can use the OnRails and OffRails events to detect when DOE should draw the blinking lights and when it does not. It's an issue on github now: https://github.com/net-lisias-ksp/DistantObject/issues/17 Cheers!

Yep. Known issue as explained by @Krazy1. I will tell you the true: it's a low priority for now, as we have two very nice alternatives to stock plumes: Waterfall (and you need to install TweakScale Companion for Frameworks to have it work with TweakScale) SmokeScreen and Real Plumes, if Waterfall is too heavy for your rig, (SmokeScreen has TweakScale support embedded) It worths to mention that Stock Plumes never scaled correctly on TweakScale, at least since KSP 1.2.2 IIRC (the oldest that I had tinkered with) - so supporting Stock Plumes will demand a lot of research and clean-room-reverse-engineering - and with the huge backlog for more serious and immediate problems (being the increasing KSP regressions since KSP 1.8 some of the worst…), I really can't make any promises about when I will be able to tackle this down. The easiest way out is to use one of the alternatives above - they are huge improvement over Stock Plumes anyway! Cheers!

Hi. Humm… I didn't tested subassemblies, my bad. I will try to reproduce this on my test rigs and see what I get. From the TS's icon, I see AutoScale and Chain Scaling are disabled, so this narrows a bit the possibilities. Don't bother. I reproduced it here. Hint: it only happens on KSP 1.9 and newer (KSP 1.8 and older don't present the problem). So, it's a missed used case to be handler by KSP-Recall's AttachedOnEditor. This will be tackled-down by https://github.com/net-lisias-ksp/KSP-Recall/issues/35

Yep. As a matter of fact the first jet engines were exactly like that! (the comparison sticks because a combustion chamber is a combustion chamber - what the engine does with the thrust after it another problem). Complexity and failure rates. The more combustion chambers you have, more ducts and pumps you need to keep everybody fed and happy, and the more mechanical parts you have moving, the more mechanical parts prone to jamming you have. The jet engines of that era were terribly unreliable due exactly this. There's also weight: more ducts + more chambers == more weight. One big duct/chamber is usually lighter than many smaller ones for the same job.

I feel your pain, bro… I once screwed up one of the scale exponents of TweakScale on my development branch - I changed the whole freaking game without being aware (I think it was mass, but I'm not sure…). Only realised the mistake after a whole night of playing Career ("eat your own dogfood!"), when I tried an already proved Lander from another savegame on Mün and the damned thing touched down as a dino killer asteroid. I ditched the whole savegame.

Whoops…. Sorry, it was late night and it was immediately before going to bed (for forum compliant practices, unfortunately!!! ) Shove this patch on a file on your GameData (I suggest GameData/__LOCAL/TweakScale.cfg): @SCALETYPE[stack]:NEEDS[TweakScale]:FINAL { %scaleFactors = 0.1 , 0.3125 , 0.625 , 0.9375 , 1.25 , 1.875 , 2.5 , 3.125 , 3.75 , 5.0 , 7.5 , 10 , 20 %incrementSlide = 0.01 , 0.025 , 0.025 , 0.025 , 0.05 , 0.05 , 0.05 , 0.05 , 0.05 , 0.1 , 0.25 , 0.5 , 0.5 } @SCALETYPE[stack_square]:NEEDS[TweakScale]:FINAL { %scaleFactors = 0.1 , 0.3125 , 0.625 , 0.9375 , 1.25 , 1.875 , 2.5 , 3.125 , 3.75 , 5.0 , 7.5 , 10 , 20 %incrementSlide = 0.01 , 0.025 , 0.025 , 0.025 , 0.05 , 0.05 , 0.05 , 0.05 , 0.05 , 0.1 , 0.25 , 0.5 , 0.5 } This will add the desired "scaling slot" to everything using the standard scale factors. Cheers! — — POST EDIT — — In a way or another, the Auto Scale and the Scale Chaining works as intended even without the patch!

The 3.125m is a default "scale factor" : [Whoops…. the dude was meaning 3 meters and 125 mm, not 3 hundred and 25mm… See the post below for the correct answer] scaleFactors = 0.1 , 0.3125 , 0.625 , 0.9375 , 1.25 , 1.875 , 2.5 , 3.75 , 5.0 , 7.5 , 10 , 20 ^^^^^^^ You should be able to set the scale to it by clicking on the outer "arrows" (<< and >>) on blue buttons on the scaling bar: Additionally, there's a "new old" feature on TweakScale called "Scale Chaining" (CTRL-K) and another called "Auto Scale" (CTRL-L) that will help you a lot (most of the time ) on your designs, as they will try to scale the part being attached to match the size of the part in which it is being attached. Since some newer Add'Ons ended up taking these shortcuts, there's also a simple GUI accessible by this button where you can enable and disable these features using the mouse. Cheers!

When I was younger, there's was a place called SENAC where professional classes were available. It's a mixed government/private company dedicated to teaching things needed by the local Commerce. One of that classes was electronics, and visiting the place I noted the roof of that room was littered with small roles. I asked why, and before my friend (the instructor) could answer me something blew up behind me, on a student's workbench. Very didactic.

Bisnovat Mk1. Source: http://www.aviastar.org/air/russia/bisnovat_sk-1.php Source: https://www.armedconflicts.com/Bisnovat-SK-1-t43529 I don't have the slightest idea how in hell the pilot would see the runway on landing - but, again, 90% of my KSP airplanes have the same problem so…. Artistical Rendering: Source: https://www.scalemates.com/pt/kits/prop-and-jet-7229-bisnovat-sk-1--1048675

Kerbal proposes, Kraken disposes! (You should see my face when I realised the problem had fixed itself!) Apparently, it was something about a device driver conflict somewhere - or perhaps a mere configuration. I think a silent Windows Updated ended up fixing that somehow.

Found this one by accident today! (Earth Wind and Fire - Let's Groove). Boy… How colourful!

The Flying Pinto. (to bad it ended in tragedy - but…)

And the funny thingy about the @Noobi's problem is that, besides all our efforts, the problem just solved by itself (probably a Windows automatic update). This was one of the most Kerbal threads in the last few months!!

Not willing to be a…. hum… SAS Mohole . but I think Private Division needs to rethink their Store policy pretty fast. U.S.A. is one of the largest markets in the World, not doubt, but there's life (and money ) on the rest of the World too! And 3rd parties are already exploiting this market, as the link above clearly demonstrates. There's shipito, there's paypal - you don't need to handle the mess yourselves.