Lisias

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.

News from the Front. For who is not following what I'm doing ("todo mundo menos uns 3 ou 4 gatos pingados" ), I'm hunting down and closing issues about patches for the next minor release, what I wanted to put on the wild this week but... This is the problem, and it's not a unexpected one. After adding ":FOR" on every patch, things works fine as much as everybody uses :AFTER , :BEFORE or :NEEDS . This will work for new patches (or for KSP installments with only Stock parts and TweakScale). But older patches, now, have precedence as legacy patches are applied first by Module Manager.. And then my patches bork due other Add'On "taking over" the parts: [LOG 19:19:18.920] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] [LOG 19:19:18.921] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale] [LOG 19:19:18.921] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] [LOG 19:19:18.921] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale] [LOG 19:19:18.929] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] [LOG 19:19:18.929] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale] [LOG 19:19:18.929] [ModuleManager] ERROR: Error - paste command (#) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/#@TWEAKSCALEBEHAVIOR[Science]/MODULE[TweakScale] [LOG 19:19:18.929] [ModuleManager] ERROR: Error - replace command (%) is not valid on a root node: TweakScale/patches/Squad/Squad_CmdCtrl/%MODULE[TweakScale] These are not parts from another Add'Ons. The parts borking are Stock ones. There're random patches "taking over" the control of Stock parts, and this will break everybody once I publish this next Release that would be relying on default TweakScale behaviour. There're no easy way out of this. Well. Bug fixes are in hold while I enumerate the Add'On(s) that are doing this. Definitively, not fun. — — — — POST EDIT — — — — I was wrong! The problem is not with the :FOR thingy, it is with the parts themselves!! At this point, this can be even a bug on MM or in any other Add'On that mangles GameData as it appears - the problem is not deterministic anymore: the same installed Add'Ons are not causing the trouble anymore for 'reasons', and now I'm trying to make the problem happens again... Oh, joy ! — — — — POST POST EDIT — — — — This Kraken food freaking problem has vanished. I, indeed, did updated some Add'Ons on the installment where that happens and had forgot about - just remembered now that I was updating some more and realized the timestamps of some directories. Duh.. Never mix fun and business, they say. In a way or another, it was indeed a patch related problem and so, it will probably happen again. But at least, now I know in advance about the issue, so I will respond to it way faster in the future.

Had you asked yourself why such Add'Ons are slow? What make you think that it wouldn't be slow too if such feature is incorporated on KSP? There's no free lunch. You need to write code for doing things, and then this code uses CPU time at the expense of other code.

Dude, I was in a hurry and hit Save too soon. The FS3WL is from FireSpitter. It's a part that once you launch the craft, teleport it to any place in the current body. It's very handy when you don't want KK neither MakingHistory. I used to use VeselMover to put the craft where I want for the first time. Then took note from the position, and then create a ".pos" file with it on the FIrespitter folder. Then I just strap the FS3WL part, select the .por file I want and then voilá.

It's not a CKAN issue. At least, no directly. The "remote site" (i.e., the place where your running CKAN is trying to fetch data) just closed the connection on the CKAN's face. Only the remote site owner can tell you whey this happened. Usually, this happens when the remote is overloaded and have to make harsh decisions about who to serve and who not. There're other situations when this happens, but, really, only the remote site's owner can tell for sure.

Install Kerbal Konstructs, and not Kerbin Side. KK is the one allowing to select launch sites. If you ara on KSP 1.4, you can use the "FS3WL Water Launch System". It's working for sure (I fixed it and made the push request to maintainer's). The .pos files need to be updated, however. I don't know about 1.5, but on 1.6 the thing is not working perfectly again (some small glitch, but I didn't found the time to figure out it yet)

Hey! This would make me jobless! On a side note, perhaps not the "full tweakscale". Trying to figure out a way to scale every single part that any crazy Add'On author could create would drive the guys nuts. But a stock interface to be realized by people willing to scale his parts would be interesting - so they withhold control on scaling critical datum (as mass), and don't have to bother trying to cope with crazy Add'On authors.