Lisias

Publish your KSP.log . The answer is usually there. In the mean time, from where did you downloaded it? The latest version I found is here: https://github.com/Kopernicus/KittopiaTech/releases

For aircraft landings, you don't want to get the distance between your cockpit and the ground exactly below you. That piece of ground is not a threat to you anymore (unless you are in free fall). You are worried about the distance you are from the ground ahead of you, as there is the rock that can kill you. It's useful on the final approach, but by then you know there're not obstacles ahead as no one use to put airstrips behind a hill. The ASL altimeter will be useful for suicide burn landings. I found some didactic material on Radar Tilting here. Look for "paint the ground". GPWS is the thingy that yells TERRAIN on the movies.

Because they are not brave. They are "righteous". Some people, by having had a hard life, ends up believing that the World owns them compensation, and so everybody should comply with their wishes. Some other, by having a very easy and unchallenging life, ends up believing that they are "better", so they deserve "better", and so everybody should comply with their wishes. In a way or another, the aftermath is exactly that: people thinking that hey can do whatever their want in disregard for everybody else, and becoming angry and revengeful to anyone and anything that challenges that.

And this is why we are call our galaxy The Milky way!

The Earth is a Donut. And I'm hungry.

Nowadays, they have the Betas - Squad uses it to allow users to easily "stick" to a specific KSP Version. Open the Properties for the game, look for the Beta tab. I think this is on TweakScale shoulder. Check this bugtrack, I included your issue there to check as time allows. https://github.com/net-lisias-ksp/TweakScale/issues/27

With additional code by Rudolf Meyer merged up, so it's not exactly the Ferram's "stock' code. (on a personal note, it's better) On page 89 (if memory serves me right), there's a recompile made by a fellow Kerbonaut (and the memory DOES NOT serves me on his name) that is the Ferram's code untouched, except by being able to run on any KSP version.

Ow. This is my favorite kind of issues! The ones that doesn't exist, so I don't have anything to fix! Not a problem. It just happened that I'm working on some issues on TweakScale, and by "luck" (I hate you, Murphy!) what you described fit perfectly on the potential colateral effects I'm worrying about. The thing is deeply buried on some site, and then, zipped together a lot of other patches: https://www.dropbox.com/sh/wrjma4jq9gu0frj/AACUNwRheKYoUULqeEhC_0cha?dl=0 Unzip the thing somewhere, and move what you want to your GameData. (and thanks, by the way! I had forgot about this, and it's interesting to have it along to include on the testing! So, this ended up being useful! )

I'm not sure that the crappy performance on clouds is on Unity or KSP shoulders this time (and coming from me, this is something). The Add'Ons I looked inside bypassed everybody entirely and hit OpenGL or DirectX directly. So, for this, the bottleneck is the GPU (or the graphics driver). By directly supporting the feature you would make it easier to cope with the rest of the program, and perhaps saving some context switch . But I don't think this alone is enough to make things run faster in a perceptive way. ----------------- I'm wrong. I just remembered that the effects are rendered again over a already rendered artifact . You can see this on the main menu, on slower or overloaded machines, it's possible to see the stock drawings being overwritten by the enhanced one for one frame. So the work apparently is done twice . So I stand corrected. The thing can bring some significant performance enhancement by being natively supported by KSP.

Sometimes I wonder if this is not one of their worst problems . Too much information is as good as no information at all, as it usually lead to the same results. Survivorship bias. Making a poll with people that already had bought the game is not going to increase their revenue, that it's what we need them to get in order to keep KSP (and Forum, and everything else) being funded - you know, these guys need to eat. :-) They need to make polls for people that are considering buying the game .

That's another new. My understanding was the exactly the other way around! Mangling with the DLLs on the System32 will cause you trouble with the remaining of the games. There is a system wide access place for DLLs. Put that DLL in the same directory where your .EXE is. The current directory is (or, at least, it used to be…) the first place where Windows looks for the DLLs.

It will be KAX, no mater the version or the fork's name. Think of 'KAX" as the Brand Name, and "KAX/L" the current implementation filling the Brand.

HI. In the next minor release (hopefully) TweakScale default patches are planned to have the :FOR clausule, what will allow you to use :AFTER and :BEFORE on yours. This way you can safely redefine the patches as you want. Deleting the default patches to ensure that yours is "The One" is also an option (your game, your rules - just remember what you did while reporting issues!). You will need to do the same with every Add'On that provides its own Tweakscale patches (as most of them relies on the default ones), but without support for :AFTER and :BEFORE this would be probably the safest approach for now. However, I don't test TweakScale without the default patches - this is kind of uncharted waters. Feel free to play with the idea - but keep in mind that savegames and crafts may be not interchangeable with default TweakScale installments (I never tested this, and there are small differences on how different versions of KSP handle the prefab - it's really uncharted waters). TweakScale will continue to withdraw support for problematic parts normally (it does it even for default patches), so your patches will be as safe as they are now. Keep an eye on KSP.log before reporting problems. if you find a message from TweakScale about the part you have problems, there's a good chance that I should be involved too.

As far as I know, TweakScale is "not working" for some very specific cases, most of them due wrongly applied patches. TweakScale logs on KSP.log every problematic part it detects, pinpointing to an URL explaining the bug. Publish your KSP.log so we can diagnose your problem. — — — — — @Rattana, could you please provide your KSP.log and more information? I didn't found anything (new) wrong with TweakScale and Airplane Plus (or any other AddOn). https://github.com/net-lisias-ksp/TweakScale/issues/28

Well.. Talking about Hot Blondes again...

Well… You have a point. So, let me correct myself: "mirroring is not possible using control surfaces on a node" But yet, give a look on @JadeOfMaar's post above. Perhaps you would get better results doing what he suggests.

It's always this way. First, you experiment with small things. Then you feel the need to experiment stronger sensations - and then you are addicted. Welcome aboard. You are not alone.

Can be a debug release. At that time, the MFC had the nasty feature of 'swallowing" Exceptions on the debugging linkage. A lot, and I mean A AWFUL LOT of software developers at that time just linked their products on the debugging version instead of fixing the code. You need a tool called PE-Explorer to see exactly what such DLL is.

Check if if the DLL being used is a 32 or 64 bit one. God known what WinSXS did on your rig, I wish I could check it myself, but my Win rig is without a GPU for some months already.

Green Jelly ha also some wonderful videos. Unfortunately, some of the best cannot be published here due Forum Rules.

I'm moving this here, as the subject is way offtopic on the original Thread, and besides not being exactly about TweakScale, it's what I had to cope on TweakScale, so it's kind of on-topic here. — — — — — - Interesting, Maby a way to override the pervious mass? I don't know I don't code just an idea. It's not what happens (overriding the mass), but how. The mass must be overwritten, that's simple. But where is the mass of that part? On a data structure. Now let's suppose we have TWO different codes, running in TWO different threads willing to overwrite the same mass, or one of them willing to overwrite another datum on the same data structure. What will happens? Nobody knows. We have a problem here called "race condition" - the result will depend of which code reaches there first, and by the nature of multi-threading and multi-processing, this is non-deterministic. On the parts borking on TweakScale, what was happening is that on the prefab working phase (when TweakScale oversees every part instrumented by MM to guarantee the dry-mass is correctly calculated), some other Add'Ons were also mangling that data structures too (the GameData). These Add'Ons were reading the Node, creating another one with custom data, and putting it back. Since this was happening at the same time TweakScale was doing its business, it was usual that other Add'Ons were destroying the TweakScale data after the correction (as their Node were replacing the one TweakScale fixed), and by the nature of the ConfigNode's API, absent data can be defaulted to zero.This explains why some parts had negative mass: a Zero_Mass minus Dry_Mass == -Dry_Mass. Things get really hairy when by similar reasons we end up with Zero Mass and Zero Dry_Mass. The resulting mass is now Zero. And since in Physics a lot of formulae uses Mass on multiplies that are later used as divisor, we end up with Division by Zero exceptions everywhere on the physics and 3D engine. When such exceptions are not handled (i.e., empty try-catch, unfortunately a common practice on Add'On authoring in KSP), the data is stored as "NaN" (Not A Number), a special flag used by the math routines to flag when things goes through the tubes on the calculations, or "Inf" (Infinity), a special flag to allow some calculations to go on. From that point on, every calculation with some variable with that flags ends themselves resulting in "Inf" or "NaN" or even another Zero, propagating the mishap to the whole memory structures. If you know anything about Bresenham or Gourad, you will start to foresee where things will end even by not understanding orbital mechanics - sooner or later, something will blow up into the Infinity (hehehe) And it did a lot.

Use a octogonal strut to hang the wings. As it was said before, mirroring is not possible on parts attached to nodes, only on surfaces. And this includes the parts you are using to attach more parts - the thing cascades. (I don't know the reason why this happens - perhaps can be something we could work around on custom parts, but I don't see a point on doing that without the Stock parts jumping suit on it)

Nice! And since we are here, this is what I like to play just to listen to the music!

It's cheap to call people "murderer" due a single reason: real murderers usually murders people calling them murderer - so by keeping calling someone a murderer usually is evidence that the guy is not.

It's not so simple "downthere" on the CPU. This subject is way off topic, so ping me here if you are interested.