Lisias

I have absolutely no problem on sticking with 1.3, but... had you tried 1.7.3? It's my main gaming rig until now, and it's working pretty fine to me. There're some good parts on the Making History, and perhaps Serenity would allow you do do some interesting stunts on the plot? In a way or another, I have a lot of add'ons backported down to 1.3 if you need something with bug fixes (under the KSPU hierarchy - no official support, but yet it's more support than you have now, so...), and I have no problem on backporting something else to 1.3 if there's a demand. TweakScale, in particular, is way more robust on 2.4.4.x series, and backporting it to 1.3 is a breeze now after the last batch of refactoring. Cheers!

ANNOUNCE Release 2.4.4.5 is available for downloading, with a last minute fix. This build fixes some embarrassing borks on the default patching. Special thanks to @AccidentalDisassemblyfor detecting them! (this time I reacted fast! ) See OP for download links. 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) - Right now. Being another important bug fix, and being it the only change from the last version, I shoved the release everywhere at once.

I understand your objections, but this solution aims to prevent unattended people of running the game on a probable inconsistent and dangerous state. Most people just click on the "OK" button without caring, and your description of your objections just comproves the thesis! Yes, I want people to pesky me here in order to get rid of that FATALities, and if they choose no to do so, I need to be absolutely sure it's a conscious choice, and not some automatic reflex on clicking on "OK". I do not want, never more, under no circumstances, to have again users here complaining because "TweakScale ruined his 3 years old savegame". If this is so much a problem for you, I can compile for you a version without any warnings - but, by then, I will not provide support neither accept responsibilities (i.e., no bug reports) on what can happen on your rig. You will be on your own. Good for you, you survived the Russian Roulette. But not because the problem was imaginary, but because I (and/or Squad) cooked a lot more safeties on TweakScale (and/or KSP) that apparently is working most of the time. At least for while - anything changes, even a new mishap of mine, and weird things that was working by plain luck start to bite your SAS. A Russian Roulette with a 100 bullets capacity on the cylinder and only one bullet on it it's still a Russian Roulette. The name for what you want me to do is Normalization of Deviance. Sorry, I will not do it. Again, I can compile a specialised version of TweakScale for you, without any of the peskiness you don't like as long you agree that I will not provide any kind of support for you.

If you compare it with bigger and more complex games yes. On the other hand, comparing to some others, not that much... Different teams, different scopes, different models of revenue. It's hard to draw a parallel. Perhaps with Space Engineers or Empyrion? Utterly needed. Launching vehicle with some older parts leads to Instantaneous Craft Annihilation (from now on, ICA) due heat (!!!). This can't be worked around with cheats, but KSP Recall 0.0.6 (currently beta) fixes it. Launching pretty heavy vehicles (above 120 tons, my test bed uses a 500tons one) shoves the craft below any colliders on the launch point, placing it directly on the PQS ground level - also inducing ICAs. Worst, by switching scenes (or, better yet, by doing something that packs the craft), when you switch back and the craft is unpack, if there's anything with a collider under the craft and on the ground, the craft is placed inside it and you have ICA again. This can be worked around with the Indestructible Cheat, but this is annoying on switching crafts. World Stabiliser cannot help on this, as it tries to fix another problem and not this new one. Besides the panels, the landing lights on my crafts are always "lit" - but they only casts light with the lights on (U key). All of these hints me they are failing in properly initialise something on craft launch (and/or on the unpack) what suggests a common root cause. I hope they find and fix the root cause, instead of patching the effects where they we find them, what IMHO is the current M.O. around here and the underlying reason by so many bugs keep resurrecting on every new release, as well some clearly related new ones being spawning when new features are created.

Excellent! But so I don't understand why the patch above failed, because TS does kinda the same, but using introspection... Anyway, by night I will check this - I must had done something stupid on that patch... Welcome. I understand this solution is less than desirable, but there're so much time available to check and pursue every new change (and bug introduced) on each new KSP version, so Authors need some time to understand what's happening to cope with - for example, I managed to understand why some old parts are blowing up due heat on launch, but now I realised that heavy crafts are blowing up too!! (and heavy crafts are one of the reaons people use TweakScale...). All of this can easily overwhelm our free time - yet more to who works on this time of the year, as me... I'm pretty sure these parts are suffering something near the heat problem I think I solved on KSP Recall 0.0.6 (beta!!!), so there's a good chance I can manage to cook a workaround (if someone else don't do it first!). But for now.... Humm... When you rolled back, you did the installing one by one, or just moved the GameData's folder contents (except Squad and SquadExpansion, of course) to the 1.10.1 one? These errors should had happened on 1.11 too. In a way or another, I found the problem - such a amount of FATALities are usually related to installing something twice on the system. Essentially what's happened on you rig: [LOG 18:05:46.140] Config(@PART[Tube1p5]) TweakscaleMakingHistoryConfigs/Structural/@PART[Tube1p5] TweakScaleMakingHistoryConfig was an old add'on that was retired (and I think incorporated into TweakScale - that was before my time here), and since now TweakScale is the canon patches for Making History, there's no need for this add'on anymore. Frankly, I can tell you you don't want it, because TweakScale's patches were revamped and some little details fixed. Remove TweakScaleMakingHistoryConfig from your GameData and everything will be fine. In time, can you check the licensing terms of the TweakScaleMakingHistoryConfig and, if the license allows it, can you pack it and send me a copy? I can't find a pristine copy of it anywhere in the Web (it was distributed once on SpaceDock, but as I said, it was withdrawn...) I need to check if TweakScale original MH parches came from it and, if yes, I need to proper acknowledge it - current patches are a complete rework from scratch, but until 2.4.3, that patches were the canon and I think that guy deserve the credit for the work.

Because you would ended up with 9 times more storage than the original part, not 3! Suppose you have a container 3 meters by 3 meters, with slots with 1m³ each. So you have 9 slots, and the container has 9 m³. By scaling the container to twice the size, you till have a container with 6 meters by 6 meters, or 36m³. BUT, by scaling the slot's size and the quantity of slots on the container, you will end with 36 slots with 3m³ each = 108m³ - the numbers don't fit. (unless you are a fan of Doctor Who, of course! ) Damn. Or I did something wrong on the patch, or I will have to follow suit with you and brute force my way into the problem. I will give it a shot by the night, stay tuned!

This explains your interest on support for ModuleCargoPart and ModuleInventoryPart. What I plan to do is to support these things the same way I did on KIS: allowing the user to choose to scale the quantity of slots, or the size of each slot (those quantity remains the same). It's essentially what I'm working on now, and I expect a new TS release (or, at least, a new 2.5 Beta with it) in a couple weeks. But since this is not necessarily what you may want to do with your part, and since TweakScale will provide Exponents aiming to support the stunt I mentioned in the previous paragraph, there's a chance you would prefer something else. I think that, so, the solution for you is the SCALEBEHAVIOR. Behaviours are a way to override the Exponents when needed. For example. there's a Behaviour for Engines because their weight scale at 2.5, and not 3 as (almost) all the other parts. And since TweakScale nowadays just don't touch anything non Stock or DLC, you can rest assured that TweakScale will never touch any of your parts, so anything you do will be preserved now and in the future. Third parties, however, may be a problem on it. In a way or another, your SCALEBEHAVIOR should be something like this: TWEAKSCALEBEHAVIOR { name = KSPIE-ModuleInventoryPart MODULE { name = TweakScale TWEAKSCALEEXPONENTS { name = ModuleInventoryPart InventorySlots = 3 # Use this one //packedVolumeLimit = 3 # OR this one. NOT BOTH! } } } and then @PART[KSPIE-RadialCargoContainer]:AFTER[TweakScale] { #@TWEAKSCALEBEHAVIOR[KSPIE-ModuleInventoryPart]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free # for radial parts, usually free is the choice } } I agree this is a bit convoluted, but I could not think on anything so better than could worth changing years of already made patches, so... Of course, you may want to customise the numbers above. Perhaps you would like 2.95 as the InventorySlots exponent (for any reason you could think of, as the need to cope with the extra mass needed by the extra slot's walls), or perhaps 3.1 on the packedVolumeLimit (idem). You can tinker with the mass exponent too, crewed parts on TweakScale patches has a mass exponent of 2.5. Toy with the numbers if you are in the mood, sometimes we get results more related to real life (as someone did in the past by using 2.5 with the engines) playing "what if". (boy, I miss the times in which I could tinker with the parts by mangling the craft files, now I need to restart KSP...)

Yes. It doesn't helps on KSP 1.11 . The craft already spawns under the runway. Interestingly, I spawned that 500 tons rover using Vessel Mover and let it place it gently into the ground.. .Dude, that thing moved up the rover to 300 meters, and started to down it to the ground at less than 0.5M per second! It took minutes to lay the craft on the ground! This hints me that the weight is the key. I think that something on spawning the craft is placing the rover on the PQS ground level, instead of firing a ray from the skies into the ground to find the runway collider. Then, before the physics kicks in, something else finds the nearest collider and moves the craft there - but the routine used, by some reason, uses the weight of the craft to decide the speed the thing will move into the proper place (as it happened with Vessel Mover!), and with very heavy crafts, things ends up too slow and the physics kicks before the craft is on the right place... In time, I just checked. It's not on spawning the craft, it's on unpacking the craft! I just tricked KSP into spawning the 500tons rover (using the cheat), then I unchecked the cheat, then I moved to the Space Center. Then I moved back to the craft, and it exploded too. Then I respawned the rover using the cheat (again), drove it to the grass (on the PQS ground level), unchecked the cheat (again) and moved to the Space Centre. Now, by going back to the rover, it didn't exploded! So I have confirmation for my thesis - the craft is being spawned on the PQS ground level, and heavy crafts are failing to be placed over the neared collider on unpacking. Well, another confirmation for the craft's weight thesis. :)

Now you lose me, I think I need further information about what you need to do - otherwise I may be only making things worse... About extending stock classes, I tried it some time ago and got some unwanted misbehaviours... Once you extend a stock Module, every single instance of the original module will be replaced by yours instead - no matter what you call it. I was trying to extent the ModuleControlSurface (to tell you the true, I was trying to tinker with Atmospheric Autopilot that does that), don't remember the details, but let's call this new class ModuleControlSurfaceHacked. Well, every single part on the game ended up instantiating the ModuleControlSufaceHacked, and not only the parts I created using explicitly this Module. Worst, on saving the craft (and the savegame), every part is serialized using the ModuleControlSurfaceHacked. And so you can't export crafts or remove the add'on without needing to manually edit every single craft and savegame to rename ModuleControlSurfaceHacled back to ModuleControlSurface. I found, some time ago, a post on this forum explaining something that leaded me to conclude that in some previous KSP version (older than 1.4 for sure), you could do this stunt because KSP would load the Module by the name you used on the ConfigNode, and not by the topmost extending class. On that times, what you want to do would be safe, but nowadays, I think you are going to have more problems than the one you want so solve worths. What I would do instead is creating a "Helper" Module that would monitor your Module of Interest and then call TweakScale to do what you need when something happens - it's essentially how I implemented support for FSBuoyance for Firespitter, and also how I implemented that fancy scaling on KIS (you can scale the number of slots, or you can scale the size of each slot). I think this way is safer nowadays.

Can't really tell. I had had problems in the past on editing root nodes using MM, and didn't found a way to workaround it and what you asks implies on creating a new root node. I didn't managed to do it (what's different of not being possible however). It's the reason I gave up and just allowed some ScaleExponents on TweakScale Companion for Firespitter to duplicate the deprecating ones on TweakScale "core" for while - I'm going to get rid of anything non stock/DLC on the main TweakScale, and replacing them with optional Companions - what will prevent a lot of problems TweakScale had in the past to happen again. IMHO, if you have some disagreement about how TweakScale scale things, the best line of action is to create a new ScaleExponent for you and then apply them on the parts you want it (after removing any previous TweakScale patches on that part). I remember you asking in the past about the Converters, for example. I could not fulfil your request because that would break some assumptions that every TweakScale user have about the Converters, breaking savegames. But this doesn't means you had a bad idea, au contraire - I just could not fulfil it on the Stock TweakScale without an extended behaviour, otherwise every station already made will unexpectedly run out or resources. And so on. That can create some situations nearly impossible to detect without a lot of hard digging (and lot of wasted time). But if you create your own customised Exponents and apply them using your patches, this will keep things easy to track on the MM log. I got good results with 120tons, a hacked Driftless and Wheels without auto dampers. Less than 40 to 50 tons worked well without Driftless. So what we need is somehting that would turn off the Spring/Damper Auto on rest, and restore them when moving. That made the trick for me, at least. 500 tons, however... I made a Ore Train using Serenity hinges as connectors. Even driftless didn't helped on it. I'm trying that Ore Train on KSP 1.10.1, and is just became a fur-ball after less than an hour. So I'm not really sure if Driftless is really helping at all on KSP 1.11 - it surely didn't helped on 1.10.1. On the other hand, that monster didn't exploded on launch on KSP 1.10.1, so we definitively have a new misbehaviour on KSP 1.11.0 . Squad forgot some initialisation procedure for sure, probably the same procedure those absense is exploding some old parts due pornographic amounts of heat (the thing ChillingOut from Recall 0.0.6 is trying to overcome) coming from nowhere at launch. Interesting enough, my laggy rig can be useful sometimes - I noticed that by one or two frames the craft was below the runway before exploding - I think KSP is spawning the craft on the ground level, instead of spawning it over the runway and due the extreme weight of the craft, whatever is pushing up the craft is not being able to do so fast enough.... What hints me that perhaps the problem is the CPU load. The PIDs that controls the Wheel's dampers and springs may be skipping some frames due CPU overload, and then they start to overshoot themselves. That would explain why Driftless didn't helped at all on KSP 1.10.1, but apparently did some good on KSP 1.11 - on 1.11, Squad implemented something called "Anchoring", and Driftless may be doing some weight lifting on the problem, making things easier to that Anchoring.

The last one on the GameDatabase will prevail. The ScaleExponents are stored on a dict, so any duplicate will overwrite the previous one. You raised a very good question - such a stunt can potentially ruin the savegame - next release of TweakScale will have a Sanity Check for it! The code uses introspection to check the type of the atribute being scaled, and apply the correct operation. floats are operanted with float operators, etc. It's not different from using a variable, standard C# coercion applies. Still about this behaviour, follow some findings on KSP 1.11: 1) Light crafts with scale up wheels drifts a lot, unless you deactivate the Spring/Damper Auto setting. 2) Somewhat heavier crafts with scaled up wheels don't drift too much, if at all. 3) Really heavy crafts with scaled up wheels drifts heavily no matter the Spring/Damper settings. 4) Using Drifitless from KSP Recall solves the drifting in all cases, as long the Spring/Damper is deactivated. With the Spring/Damper Auto activate, there's a very tiny [the drift is proportional to the weight and/or part count!] drift even with Driftless installed. Your mileage should vary, as I'm convinced that this is related to how much the physics engine taxes the CPU - my heavier designs were yellowing the M.E.T. display all the time, so perhaps the problem could not be exactly weight, but part count. Really heavy rovers are blowing up on launch, unless you activate the No Crash Damage cheat. Yep, you read it right, the problem is not the joints, the problem is that KSP is "crashing" the heavy crafts on the runway at launch. You can deactivate the cheat after launch, the cheat is only needed on launch. Spawning the crafts with Vessel Mover also works, what hints me that this is not a physics engine problem, but again something not being initialised soon enough while launching crafts (the same problem with some older parts, burning up instantly - the reason for the ChillingOut module from KSP Recall 0.0.6.0 Beta).

Yes. Work in Progress at this time. There are 2 new modules and 24 new parts I need to map and support, but since KSP 1.11 release date I only had time to work on it this weekend! Version | ReleaseDt | ∑Modules | ∑AllParts | ∑AllDeprecated | ∑Stock | ∑MH | ∑Serenity ------------+----------------+------------+------------+----------------+----------+--------+------------ 0.22| 2013-10-16 | 31| 156| 0| 156| 0| 0 0.23.0| 2013-12-17 | 36| 157| 0| 157| 0| 0 0.23.5| 2014-04-01 | 37| 157| 0| 157| 0| 0 0.24.0| 2014-07-17 | 38| 158| 0| 158| 0| 0 0.24.1| 2014-07-24 | 38| 158| 0| 158| 0| 0 0.24.2| 2014-07-25 | 38| 158| 0| 158| 0| 0 0.25| 2014-10-07 | 38| 153| 0| 153| 0| 0 0.90| 2014-12-15 | 41| 168| 0| 168| 0| 0 1.0.0| 2015-04-27 | 69| 245| 1| 245| 0| 0 1.0.1| 2015-05-01 | 69| 246| 1| 246| 0| 0 1.0.2| 2015-05-01 | 69| 246| 1| 246| 0| 0 1.0.3| 2015-06-22 | 71| 250| 1| 250| 0| 0 1.0.4| 2015-06-23 | 71| 250| 1| 250| 0| 0 1.0.5| 2015-11-09 | 74| 263| 1| 263| 0| 0 1.1.0| 2016-04-18 | 80| 267| 0| 267| 0| 0 1.1.1| 2016-04-29 | 80| 267| 0| 267| 0| 0 1.1.2| 2016-04-30 | 80| 267| 0| 267| 0| 0 1.1.3| 2016-06-21 | 80| 267| 0| 267| 0| 0 1.2.0| 2016-10-11 | 89| 275| 0| 275| 0| 0 1.2.1| 2016-11-01 | 89| 275| 0| 275| 0| 0 1.2.2| 2016-12-06 | 89| 275| 0| 275| 0| 0 1.3.0| 2017-05-25 | 90| 276| 0| 276| 0| 0 1.3.1| 2017-10-05 | 90| 276| 0| 276| 0| 0 1.4.0| 2018-03-06 | 92| 279| 12| 279| 0| 0 1.4.1| 2018-03-13 | 94| 340| 12| 279| 61| 0 1.4.2| 2018-03-28 | 94| 340| 12| 279| 61| 0 1.4.3| 2018-04-27 | 94| 340| 12| 279| 61| 0 1.4.4| 2018-06-21 | 94| 340| 12| 279| 61| 0 1.4.5| 2018-06-26 | 94| 340| 12| 279| 61| 0 1.5.0| 2018-10-15 | 94| 340| 19| 279| 61| 0 1.5.1| 2018-10-17 | 94| 340| 19| 279| 61| 0 1.6.0| 2018-12-19 | 94| 340| 27| 279| 61| 0 1.6.1| 2019-01-09 | 94| 340| 27| 279| 61| 0 1.7.0| 2019-04-10 | 95| 342| 19| 280| 62| 0 1.7.1| 2019-04-30 | 106| 371| 19| 280| 62| 29 1.7.2| 2019-06-12 | 106| 371| 19| 280| 62| 29 1.7.3| 2019-07-11 | 107| 388| 19| 280| 62| 46 1.8.0| 2019-10-16 | 108| 398| 20| 283| 64| 51 1.8.1| 2019-10-29 | 108| 398| 20| 283| 64| 51 1.9.0| 2020-02-12 | 109| 399| 22| 284| 64| 51 1.9.1| 2020-02-27 | 109| 399| 22| 284| 64| 51 1.10.0| 2020-07-01 | 117| 409| 22| 292| 66| 51 1.10.1| 2020-07-28 | 117| 409| 22| 292| 66| 51 1.11.0| 2020-12-17 | 119| 423| 24| 308| 66| 49 On a side note, or I have a bug on my "database builder", or Serenity lose 2 parts on KSP 1.11..... About this drifting, I found that turning off the Spring/Damper Auto eliminated the drift on KSP 1.11 and KSP-Recall (instrumented to shove Driftless on KSP 1.11). I let the computer running with the craft sitting on the runway with brakes applied for 1:30 hours, and the craft didn't drifted a single degree. I'm repeating the test without KSP Recall to see what I get, but in a way or another, I found the root cause of your problem. A new module for KSP Recall will be created to handle the wheels. I just need to know if Driftless helped on the issue, or it's just placebo on it.

Humm... You should not be drifting on KSP 1.11, they implemented that "anchoring" stunt exactly to prevent that. I tried KSP Recall on KSP 1.11, but it apparently didn't made (good) differences on me - but it screwed up the "anchoring" when the craft is not visible by camera, and so I decided to withdraw Driftless from 1.11 . I wonder if it would not make a difference here, since even the anchoring is failing on your wheels. What is the weight of your craft? I'm trying to reproduce the problem here, but no dice . [edit: I reproduced the problem on a 120ton rover using 240% scaled up wheels. I will give KSP Recall a try on it.] Thanks! What you are describing happens when an exception is thrown when KSP runs the code that "attaches" a part into the vessel. Of course, this doesn't happens on a "vanilla" instalment, otherwise I would not had released the thing, what implies there's something on your rig causing it. Since 2.4.3 works, I'm guessing it's something on the Variant support. And the parts being affected supports this thesis. I'm investigating it. At the time the latest 2.4.3.x release was issued, it was not known if KSP 1.11 would change something that could render TweakScale playing havoc on the crafts, as it did on KSP 1.9. The bad side of TweakScale misbehaving is that things that were scaled before are bluntly descaled - or, worse, badly scaled with some non visible problems being applied to the craft - and then you save it, launch it and just then you realise the part's resources were not scaled at all. The same also happens on every living craft on the savegame you load, so this is the reason I used that scaring message on TweakScale: when things go bad, boy, they really go down through the tubes. Nowadays it's known that KSP 1.11 didn't changed anything on TweajScale, so you can ignore the message for now. -- -- -- POST EDIT -- -- -- DUDE, your player log is scattered with Exceptions. Really, there are about 3016 of them. 2727 are NullReferenceExceptions. TweakScale is not the only victim of the problem, it's the only one suffering visible effects. It's borking while creating the internal structures needed to scale things - what implies that such data is unavailable by some reason. At the point in which TweakScale is borking, the problem is on the prefab - something on the prefab is corrupted, and TweakScale trusts that prefact is upright. It worths to mention that KSP itself is borking due the problem: liquidEngineMainsail.v2 added to ship - part count: 10 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) NullReferenceException: Object reference not set to an instance of an object at PartModule.get_HasAdjusters () [0x00006] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at PartModule.Save (ConfigNode node) [0x0005c] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at ShipConstruct.SaveShip () [0x00949] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at ShipConstruction.CreateBackup (ShipConstruct ship) [0x00000] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at EditorLogic.SetBackup () [0x0012a] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at EditorLogic.<SetupFSM>b__190_29 () [0x000f2] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at KerbalFSM.RunEvent (KFSMEvent evt) [0x0007b] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at KerbalFSM.updateFSM (KFSMUpdateMode mode) [0x00080] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at KerbalFSM.UpdateFSM () [0x00057] in <f8bc9e2b903e48a5b248ab0083c07c62>:0 at EditorLogic.Update () [0x00022] in <f8bc9e2b903e48a5b248ab0083c07c62>: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) So, in essence, your savegames may be being silently corruped as you play, because things are borking while being saved (to a craftfile, to a savegame, you name it), and Kraken knowns what is not being saved that it should. Without the full KSP.log I cannot further help - the KSP.log has a lot of information that is not logged on the Player.log. My best guess is a borked PartModule being shoved on some parts, as the Mainsail, and the KSP.log will tell me who is patching it, so I can try to pinpoint a suspect. In a way or another, I would rollback to KSP 1.10.1 on your place. Whatever is borking on KSP 1.11, is borking on the worst place possible!

As long no one shoves more that one fuel switch on the same part, B9PWS is fully supported as long as I know - I have no reports of problems, at least, and my sporadic tests didn't raised any problems: If you are unsure, build a mockup of what you are planning to do and then check if anything goes wrong - be advised that everything non-stock (or DLCs) is being gradually deprecated on TweakScale "core", with fresh support being implemented on the TweakScale Companion Program. -- POST EDIT -- Talked too soon. B9PS per appears to do not be a problem, but some parts using it are triggering some NRE on TweakScale. I will not list the problematic parts because this may be realted to some new features on KSP 1.11 that are in need to be initialised, but obviously old parts cannot initialise what they don't know that exists and KSP itself appears to fail to proper initialise some things (see KSP Recall 0.0.6.0 beta for info). In time, this finding can be related to this problem reported early.

God bless the Users - without them, developers would not have reasons to be blessed! It's more complicated. There's not a hardcoded rule for scaling things, each part can have it's own scaling receipt - but virtually all of them are classified into "categories", and the receipts are cooked for each category. For example, the weight of most parts are scaled cubicly, but engines and crewed parts are scaled by 2.5 (yeah, fractions!) - it was realised that this scaling is kinda more related to real life. Engines's thrust are usually scaled by 2.5 too (bigger engines has bigger moving parts, and this taxes the net result), but SRBs are scaled cubicly!!! So, SCALE THAT Clydesdale, BABY!!! Cheers! Near enough for most applications!

In the dark ages of 2.4.3.x , yes. But that was less than optimal - smaller wheels got incredibly strong by their size, and bigger wheels terribly weak and fragile. Scaling wheels now has a functional purpose, not only cosmetic anymore - and without nasty collateral effects! However, there're still some work to do.

Kinda of. That thing behave relatively well while flying, but it was somewhat over reacting on rolling - I usually need to trim down the Authority Limit of the control surfaces at flight to cope with the flight regime at the moment. What I think it's happening is that with radial symmetry, the code that control the control surfaces is not doing a good job on distributing the forces equally on every control surface. This is happening on odd and even number of control surfaces, but on even numbers, there's a immediate counterpart to keep things... hum... more controllable. By some reason, the code that works fine with an even number of control surfaces is not doing a good job ob odd ones - one of the control surfaces ends up "overloaded", carrying on almost all the work - and this exacerbate a lot the authority of that control surface. I did some tests on a light craft using the TR-2L at 240%, and it didn't drifted. However, when using time acceleration the damn thing started to jump around like a frog on a hot plate. So I remembered when I shrunk OPT and ended up with the craft doing similar things - what I solved by turning off the Spring/Dump:Auto thingy. And this solved the problem for me. I'm guessing that this could help you too. I'm wondering I need to find a way to interfere with the wheels PIDs while scaling. Adjusting a PID is essentially black magic, and these numbers are highly tied to a specific situation over some assumptions. By scaling the wheels up or down, I'm guessing we break these assumptions.

So you found a new launch problem! "Congrats"!! Please send me your KSP.log **AND** the craft that it's blowing up into space on the most unpleasant way. With a bit of luck, I will identify exactly why it's exploding and so I could inprove the 0.0.6.0 beta work around to include your case!

You may have found a new misbehaviour on Launch (like the stunt KSP Recall Beta is "fixing"). Press F3 as soon as your rocket start to blow up (without cheats). Then publish that screenshot here so I can give a peek. KSP Recall 0.0.6.0 Beta may solve your problem, but it would be wiser to check that F3 first.

Yes. By fixing the patches with errors. I don't know of any other way. This is something you will need help from the SXT's maintainer - but asking help from the Kerbalism guys should help too, as something on Kerbalism could had changed and nobody remembered to update the SXT's support for it.

From a dude that had some heat in the past (and, frankly, didn't restraint himself from giving the heat back), I can say that this less than desirable problem you had will happen again. However, by staying here, you will "risk" getting some good times too. There're SAS Moholes everywhere, and this Forum have its share of it, for sure. However, most of the good guys (or the not so bad ones) usually sticks around way more than the bad ones for a reason: bad people usually gets isolated, because no one likes bad people - including theirselves. And even these "bad people" not rarely has something to share, besides not on an ideal format - searching for the forum, you will realise that some jerks ends up doing good things, and just leaving because of one jerkiness or two ends up preventing you from enjoying the good things he did. What implies that "bad people" is not the best way of calling them - but give me some slack, it's late hours and my English skills not that best possible There was one guy, John Nash (you may want to watch this movie, by the way, if you like histories about Science and Scientists), and this guy came with a thing called Game Theory. It's not exactly about gaming, but about "negotiation" - that can be seen as a game, after all. From his many works, one of the most interesting for me is how to cope with a "game" where the gamers don't know each other and, so, can't really establish a reputation, what's essentially what we have here - you don't really know if I'm a guy called Lisias or a dog that learnt to type and impersonated its owner, after all. And the best strategy for a game with tons of gamers that can't establish a consistent and reliable reputation policy is what is called "Retribution with Forgiveness". Instead of going bird-for-Tat, where everybody loses the "game", or just being "nice" no matter what they do with you (and so, you always lose), this strategy says that you start playing nice until someone is nasty to you, when you so give him retribution for some time (while retribution is not necessarily doing to him the same they did to you, remember forum rules, ok?), and you keep doing it until he plays nice to you again. This is the bird-For-Tat. BUT... If the other guy ended up being nasty to you by accident, or by a temporary bad moody, once you play nasty to him he can go for bird-for-Tat with you too, and so everybody ends up on a race to the bottom where everybody looses. And leaving the forum is kinda loosing this game, in a sense. There's a "solution" for this problem, but I think that the link below explains it so beautifully that I just can't find the spirit to try do to it myself. Find 30 minutes to watch this animation, it really worths it. https://ncase.me/trust/

I'm assuming you are on KSP 1.11.0 and that you scaled up the control surfaces. I made some test runs and published the results on the Issue #92 (general support issue) from TweakScale's github, but the TL;DR follows: The behaviour exists, and it's consistent most of the time. Scaling up not always made it evident: But scaling down made it more visible: However, this is happening on ALL Control Surfaces, including the unscaled ones (where TweakScale disables itself to save some CPU): Note how the Big-S Spaceplane Tail Fin is behaving differently. Exactly like the Av-R8 ones. To be absolutely sure, I removed TweakScale and tried that same test from last image again: Since TweakScale was removed from the installment, there's no way TweakScale could be causing this, This probably is not even a bug, it may be something on how KSP handles the Control Surfaces - it should be handling each lifting surface independently, and so when the second Control Surface kicks in, it has way less work to do as the first one did almost all the heavy lifting. (pun not intended! ) I hope your kid gets well soon. Cheers!

Optimism is a luxury I can't afford on my life. We build software on a quicksand. Anything moves unexpectedly, and your code is swallowed down. A typo on a config, the order in which two consecutive events happens, anything like this can bork your code beautifully. (I know of disasters that happened because one part of the code assumed that Event B always come after Event A, and then after a code revision of something else, Event B came first and the FSM got into a inconsistent state and the inputs went ignored, as the breaks). This "Jack Sparrow" way of doing things is a way to cope with frustration and stress. It works. (and Murphy was a prophet) Yeah, it was a typo on the post only. The logs would be printing "Code" instead of "Core" if not. I had a hell of a week, and when I get too much time under-sleeping, my dyslexia kicks in for some days. Ideally, not even a warning IMHO. Someone asking if something exists should not had any kind of attention. On the code in question from TweakScale: tfInterface = Type.GetType("TestFlightCore.TestFlightInterface, TestFlightCore", false); The second operand, 'false', says to GetType to do not throw errors if the Assembly is not found, returning a NULL instead. So I'm aware that the Assembly may not exist, and I will handle the mishap by checking the tfInterface against null before using it: private void updateTestFlight() { if (null == tfInterface) return; The GetType without the second parameter (or giving a true on it) will raise an exception with a full stack trace, so an entry on the log when someone asks if something exists appears to be useless to me.

Please check if it would not break TechTree first. [There should be a reason for the Physics Database and the TechTree being loaded (and reloaded) every time you enter in the Space Centre scene]

Some of these days, I will start to stream these diggings. But I need to open an account on some pr0n site, because on YouTube I will be banned for sure (I swear as a pirate on a sinking ship...) That is not an error, or better, it's an error but on KSP's Assembly Resolver. Every time you ASK the Resolver for an Assembly, it prints this line if the Aseembly was not loaded yet, even if it finds it and load it later. So what's happening is that TweakScale is asking the Assmbly Resolver if it knows about the TestFlightCore. The Resolver answer "No" to TweakScale and so TweakScale do its business without TestFlightCore. The problem is that the Loader written by Squad always prints that message when asked for an Assembly that does not exists, and not only when you try to load that absent Assembly. And that's one of the reasons I choose to write my own Assembly Resolver on KSPe. Look on the logs KSPe spits while electively loading DLLs: [LOG 12:30:06.329] [AddonLoader]: Instantiating addon 'Startup' from assembly 'KSPe' [LOG 12:30:07.205] [KSPe Binder] Hooked. [ERR 12:30:07.210] ADDON BINDER: Cannot resolve assembly: KSPe.Unity.2019 [LOG 12:30:07.212] [KSPe Binder] Looking for KSPe.Unity.2019.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.212] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.Unity.2019.dll. [LOG 12:30:07.213] [KSPe.Unity2019] Version 2.2.2.1 /L [ERR 12:30:07.222] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.111 [LOG 12:30:07.226] [KSPe Binder] Looking for KSPe.KSP.111.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.226] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.111.dll. [LOG 12:30:07.227] [KSPe.KSP111] Version 2.2.2.1 /L [ERR 12:30:07.227] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.110 [LOG 12:30:07.228] [KSPe Binder] Looking for KSPe.KSP.110.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.228] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.110.dll. [LOG 12:30:07.229] [KSPe.KSP110] Version 2.2.2.1 /L [ERR 12:30:07.229] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.19 [LOG 12:30:07.230] [KSPe Binder] Looking for KSPe.KSP.19.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.230] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.19.dll. [LOG 12:30:07.231] [KSPe.KSP19] Version 2.2.2.1 /L [ERR 12:30:07.231] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.18 [LOG 12:30:07.232] [KSPe Binder] Looking for KSPe.KSP.18.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.232] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.18.dll. [LOG 12:30:07.232] [KSPe.KSP18] Version 2.2.2.1 /L [ERR 12:30:07.233] ADDON BINDER: Cannot resolve assembly: KSPe.KSP.17 Pretty cluttered, uh? Now lets edit it and get rid of the wrongly emiited errors: [LOG 12:30:06.329] [AddonLoader]: Instantiating addon 'Startup' from assembly 'KSPe' [LOG 12:30:07.205] [KSPe Binder] Hooked. [LOG 12:30:07.212] [KSPe Binder] Looking for KSPe.Unity.2019.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.212] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.Unity.2019.dll. [LOG 12:30:07.213] [KSPe.Unity2019] Version 2.2.2.1 /L [LOG 12:30:07.226] [KSPe Binder] Looking for KSPe.KSP.111.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.226] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.111.dll. [LOG 12:30:07.227] [KSPe.KSP111] Version 2.2.2.1 /L [LOG 12:30:07.228] [KSPe Binder] Looking for KSPe.KSP.110.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.228] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.110.dll. [LOG 12:30:07.229] [KSPe.KSP110] Version 2.2.2.1 /L [LOG 12:30:07.230] [KSPe Binder] Looking for KSPe.KSP.19.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.230] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.19.dll. [LOG 12:30:07.231] [KSPe.KSP19] Version 2.2.2.1 /L [LOG 12:30:07.232] [KSPe Binder] Looking for KSPe.KSP.18.dll on GameData/000_KSPAPIExtensions/Plugins/PluginData... [LOG 12:30:07.232] [KSPe Binder] Found it on GameData/000_KSPAPIExtensions/Plugins/PluginData/KSPe.KSP.18.dll. [LOG 12:30:07.232] [KSPe.KSP18] Version 2.2.2.1 /L See how things make a lot of more sense now? The guy/gal that wrote the KSP's Assembly Resolver got a serious "brain fart" on the job, he/she never considered the hypothesis of someone ASKING if an Assembly is loaded or not, so he/she just spit an ERROR every time someone mention an absent Assembly, no matter the caller is just asking if it exists or if it's, indeed, trying to load it. You can safely ignore these messages. They are bogus. (and I can only imagine the headaches a lot of add'on's authors got on this issue, it was one of my first issues on TweakScale)