Lisias

It's something else (perhaps TweakScale is the trigger?). O installed OPT, OPT Legacy and OPT Reconfig, and I didn't managed to reproduce the issue on my side. However, I got something new now, after scaling up the SAGE: (Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 35) Uploading Crash Report NullReferenceException at (wrapper managed-to-native) UnityEngine.Component.GetComponentFastPath(UnityEngine.Component,System.Type,intptr) at UnityEngine.Component.GetComponent[T] () [0x00020] in <7d9ec060e791409ab3eb85c61e312ed6>:0 at DialogCanvasUtil.get_DialogCanvasRect () [0x00027] in <610de40702034962a21710e37d23e4e7>:0 at CrewHatchController.get_CrewHatchTooltip () [0x00065] in <610de40702034962a21710e37d23e4e7>:0 at CrewHatchController.HideTooltip () [0x00000] in <610de40702034962a21710e37d23e4e7>:0 at CrewHatchController.DespawnUIs () [0x00006] in <610de40702034962a21710e37d23e4e7>:0 at CrewHatchController.OnDestroy () [0x00058] in <610de40702034962a21710e37d23e4e7>:0 But it's certain that on the test craft, no crewed parts was scaled (so TweakScale can't be causing this one directly). I'm building a clean KSP to test it again, and until further evidences, I think it's better to switch this troubleshooting to a private conversation to avoid polluting this thread - it's not related for sure to OPT, it's some Add'On (or a mix of them). I will edit this post later with any findings of mine! -- -- -- POST EDIT -- -- -- The crash is unrelated. OPT 2.0.1 has an old Firespitter DLL on it, and I installed it by accident on KSP 1.10.1 - removing the old DLL fixed the crashes, at least, no more crashes happened since them!

IIRRC... I forgot the % on ratio and DrawGauge on the PROPELLANT thingy, and also the :FINAL. But that would not had helped. I didn't knew OPT Legacy has B9PartSwitch as dependency, so anything I did on that hack was ruled out. I'm trying to workout a patch for this. B9PSW does not help by using nameless sections, so patching it is a bit different from what I'm used to do. I will edit this thing with a working patch as soon as I have one. -- POST EDIT -- This patch did what I wanted. I'm currently firing up KSP to see if it solves something on the Sage @PART[opt_sage]:FINAL { %RESOURCE[LiquidFuel] { %amount = 1 %maxAmount = 1 } @MODULE[ModuleEnginesFX] { %PROPELLANT[LiquidFuel] { %ratio = 0 %DrawGauge = False } } @MODULE[ModuleB9PartSwitch] { @SUBTYPE,* { @MODULE,* { @DATA,* { %PROPELLANT[LiquidFuel] { %ratio = 0 %DrawGauge = False } } } } } } -- -- POST POST EDIT -- -- I didn't found any exception on my KSP.log, but didn't checked if it would have some without the hack (working time, I can come back to this at lunch if needed). @pmborg, let me know if something changed on your rig. Cheers!

Hi! You are right, however, not that right yet. This engine has two propellants: IntakeAir and ElectricityCharge. So I could think of two possibilites (what's different of existing only two of them): The ModuleEngines is looking for a specific propellant, and failing because this engine doesn't have or use it. The ModuleEngines is looking for something that ElectricCharge doesn't have it, but LiquidFuel et all always have it On both possibilities, the code fails to cope with the absent datum. (it happens 60 times per second because the FixedUpdate thingy). Looking into the RESOURCE_DEFINITION for ElectricityCharge and LiquidFuel, the only thing I saw that could fire a NRE is the drainFXDefinition - the other values would fire a DivisionByZero or shoving NaNs and INFs, I think. But I don't think the ModuleEngines would need something like this, so it must be the other one. So let's try a stunt to see what we get. Save this file somewhere on your GameData (as GameData/__LOCAL/Hacks - you need to remember this to get rid of the stunts later). @PART[opt_sage] { %RESOURCE[LiquidFuel] { %amount = 1 %maxAmount = 1 } @MODULE[ModuleEngineFX] { %PROPELLANT[LiquidFuel] { ratio = 0 DrawGauge = False } } } This will inject 1 unit of LiquidFuel to the part and tells the ModuleEngine to consume 0 units of it per quantum (the minimal unit of time of the simulation). I hope that borking code will find them and be happy from now.

Easy. Give me some time, I will come with something sooner or later.

On a side note, KSP-Recall kill itself when not needed, so no harm is done if you forget it there. BUT Why waste memory and CPU cycles?

Ah! Now I understood where the lines got crossed! You were talking about NOT having TweakScale installed, I was talking about "co-patching" when TweakScale IS installed!

I think we are not on the same page anymore, we lost the thread of the discussion somehow. I just tested :FOR[TweakScale]:NEEDS[TweakScale] and it worked (and, yeah, I used the Official MM on this test): [LOG 10:00:55.709] :BEFORE[TWEAKSCALE] pass [LOG 10:00:55.709] :FOR[TWEAKSCALE] pass [LOG 10:00:55.749] Applying update TyBarneyBlobs/Stunt/@PART[mk1-3pod]:FOR[TweakScale]:NEEDS[TweakScale] to Squad/Parts/Command/Mk1-3Pod/mk1-3.cfg/PART[mk1-3pod] [LOG 10:00:55.750] :AFTER[TWEAKSCALE] pass [LOG 10:00:55.750] :BEFORE[TYBARNEYBLOBS] pass [LOG 10:00:55.750] :FOR[TYBARNEYBLOBS] pass [LOG 10:00:55.750] :AFTER[TYBARNEYBLOBS] pass [LOG 10:00:55.752] :FINAL pass And the patch I used to test this is: @PART[mk1-3pod]:FOR[TweakScale]:NEEDS[TweakScale] { %title = This is impossible. Or not? } And, of course, the MM cache for the mk1-3pod has: UrlConfig { parentUrl = Squad/Parts/Command/Mk1-3Pod/mk1-3.cfg PART { name = mk1-3pod module = Part author = RoverDude scale = 1 <cut!!!> bulkheadProfiles = size2, size1 tags = capsule cmg control ?eva fly gyro ?iva moment pilot react rocket space stab steer torque title = This is impossible. Or not? What happened is exactly what you described, MM scanned for every patch, created the tags, get rid of the unsatisfied :NEEDS and applied the patches. The only thing that happened differently is that since TweakScale was tagged, the TyBarneyBlobs "add'on" had the patch applied together the ones from TweakScale - exactly as I talked about on my last post. What I think is not exactly ideal. IMHO Add'On tags should be directory agnostic - or, at least, should exist a way to overrule this (like that :THIS of mine). However, I'm not talking about end-users. I was talking about proper managed Add'Ons, as the TweakScale Companions! I think we are not on the same page anymore? But at the same time prevents me to use :FOR when I need something happening :AFTER or :BEFORE something else. :BEFORE, :FOR, :AFTER et all are mutually exclusive. I can't use :FOR[TweakScaleCompanion_ABC]:AFTER[ABC]. What can be easily verified with the following stunt: @PART[mk1-3pod]:FOR[ArbitrarilyDefinedTag]:NEEDS[TweakScale]:AFTER[Squad] { %title = This is impossible. Or not? } That renders the following on MM's log: [WRN 10:25:58.535] more than one pass specifier detected, ignoring all but the first: TyBarneyBlobs/Stunt/@PART[mk1-3pod]:FOR[ArbitrarilyDefinedTag]:NEEDS[TweakScale]:AFTER[Squad] <CUT> [LOG 10:26:00.123] :BEFORE[ARBITRARILYDEFINEDTAG] pass [LOG 10:26:00.123] :FOR[ARBITRARILYDEFINEDTAG] pass [LOG 10:26:00.123] Applying update TyBarneyBlobs/Stunt/@PART[mk1-3pod]:FOR[ArbitrarilyDefinedTag]:NEEDS[TweakScale]:AFTER[Squad] to Squad/Parts/Command/Mk1-3Pod/mk1-3.cfg/PART[mk1-3pod] [LOG 10:26:00.124] :AFTER[ARBITRARILYDEFINEDTAG] pass [LOG 10:26:00.124] :BEFORE[ASSEMBLY-CSHARP] pass [LOG 10:26:00.124] :FOR[ASSEMBLY-CSHARP] pass [LOG 10:26:00.124] :AFTER[ASSEMBLY-CSHARP] pass <CUT> [LOG 10:26:00.124] :BEFORE[TWEAKSCALE] pass [LOG 10:26:00.124] :FOR[TWEAKSCALE] pass [LOG 10:26:00.162] :AFTER[TWEAKSCALE] pass [LOG 10:26:00.162] :BEFORE[TYBARNEYBLOBS] pass [LOG 10:26:00.162] :FOR[TYBARNEYBLOBS] pass [LOG 10:26:00.162] :AFTER[TYBARNEYBLOBS] pass [LOG 10:26:00.163] :FINAL pass :FOR really shouldn't be the tag used to create MM tags, I think.

That is interesting! Can you please send me your KSP.log? Just out of curiosity, I didn't see this coming!

Nuff said!

Yep. It's subtle, you need to pay attention to see the damage this can cause. At first glance on my mobile I didn't got it, I had to come back to my computer and see it on the big screen to have something snapping on my head. I can think on a one or two use cases where someone would want to use :FOR[TweakScale]:NEEDS[TweakScale] on their patches -- in a nutshell he wants to be sure that his TweakScale support for his parts should be available to everybody at the same time TweakScale does his owns, so people using :AFTER[TweakScale] and :BEFORE[TweakScale] would not have their toes stomped by him. Consider the following scenario: some people strongly disagrees with the free scaling on stock parts (i.e., the hability to allow scaling the thing between two hard scales - discrete scaling). So this guy write this: @PART[*]:AFTER[TweakScale] { @MODULE[TweakScale] { %freeScale = false } } But that other other guy had named his Add'On as TyBarneyBlobs . So, alphabetically, it's executed after TweakScale. He uses :AFTER[TweakScale] as a good citizen of Kerbin nevertheless. But then, that guy that prefer discrete scaling also used :AFTER[TweakScale] and ended up being patched first - and the after math is that some parts will be discrete scaled, and a few others don't. Okey, this will be solved by :LAST[TweakScale]. Until someone else uses it too, and now we have a new race condition for the :LAST position. This can be prevented if people that wants his own parts with TweakScale support but don't need to be patched on any special order could also use :FOR[TweakScale] . So their patches would be applied at the same time TweakScale's ones, and anyone wanting to second guess TweakScale scaling decisions would not have any problems on using :AFTER[TweakScale] or :LAST[TweakScale]. This is a legit use of the :FOR[TweakScale] by third-parties writing their own patches. For some time, I considered doing it on the TweakScale Companions - but then I thought that it would make it harder for people to detect the Companion itself, and concluded that I would be regressing to some of the problems I had before deprecating anything but Stock+DLCs on TweakScale itself. In a way or another I agree that everybody (but TweakScale) need to use :NEEDS[TweakScale] on his patches, only TweakScale stock own patches should use :FOR[TweakScale] alone - and this includes the Companions, as they should be handled as third-party from TS point of view.

shhh... don't snitch me!!! And there's one more possible reason, this one affecting TweakScale. On the beginning of time, there was only the LEGACY. The patches were applied in the order they were found, and they were found alfabetically -- essentially, a find . -name "*.cfg" | sort with the difference the filenames are URL escaped (due Unity's architectural decisions). It as a mess, but since TweakScale is ordered near the end of the patching list, every single add'on those name comes before T is patched first, and TweakScale so ends up patching later, overwriting any eventual patching. A lot of tricks were applied to overrule TweakScale due this. Then the pass specifiers came, people started to use it and then everything changed - now TweakScale patches first, and everybody else started to overrule TweakScale by default, without efforts. And after some toe stomping fests we reached another fragile equilibrium for some time. On this previous status quo, trying to use :FOR on TweakScale would have caused a huge breakage on the patching because this would withdraw TweakScale from the LEGACY, breaking the expected chain of patching on add'ons that wants to overrule TweakScale. So some of my patches ended up in need to use :FINAL, because I could not use :AFTER[TweakScale], because TweakScale could not use :FOR at that time. My pesky insistence on telling people to do not use % when they are the owner of the patch not only prevented double patching on TweakScale, it ended up with patches being written without relying on TweakScale being on the LEGACY - the easy (and suicidal) way out of shoving % on everything and hope for the best didn't worked anymore. And so, now, TweakScale is migrating the patches to correctly cope with the new status quo. The 2.4.4.x series will be the last minor version with TweakScale on the LEGACY phase. The TweakScale 2.5 Beta is using :FOR for ages now, and nowadays people using it on the field are not getting any of the problems I got when I first tried using :FOR on my test beds so it's certain the 2.4.5.x (assuming I don't came to terms on going straight to 2.5 at once) will have :FOR on the patches.

Apparently not! My bad, I totally missed we were on someone's thread.. I'm jumping between many tasks today, and this plays havoc on noticing details... Try this so: @PART[part1,part2,<etc>]:BEFORE[KRnD] { -MODULE[TweakScale],* { } } (Assuming the MM tag for KRnD is KRnD). This will ensure TweakScale is removed before KNrD tries to patch it. :BEFORE, :AFTER:, :LAST and :FINAL are pretty useful (and underestimated) tools!

The problem with that approach is that you need to remember things while updating - at least for me, not the best of ideas. I usually recommend a patch to disable the parts using a patch placed on a easily remembered place (i like GameData/__LOCAL/ for that - but anything goes as long you remember where the patches are and don't remove it by accident). It's something like this: @PART[part1,part2,part3<etc>]:FINAL { -MODULE[TweakScale],* { } } If you know for sure that every part with a [certain] module should not be scalable, as KRnD, try this: @PART[*]:HAS[@MODULE[KRnDModule]]:FINAL { -MODULE[TweakScale],* { } } Of course, it works for any module (engine, lift, etc) - just replace the KRnDModule for ModuleEnginesFX (if you don't want scalable engines) or something else. In time, that :FINAL thingy is important, I should had put it on my previous examples! It's safer this way because if you update something and forget you had removed the patches from that thing, on the next boot the patches will be applied (of course) and then be shoved on your crafts and savegames on load (I think I understand why, but need more time to be sure), and this will play havoc on the savegame as an empty, unusable section will be shoved on that parts and TweakScale will detect it and complain about. Cheers!

It's exactly the same thing on that thread suggested above: [LOG 09:19:24.788] [ApplicationLauncher] SetHidden: [LOG 09:19:24.795] [MessageSystem] OnAppInitialized [LOG 09:19:24.796] [MessageSystem] Reposition 0.0788687 4700 [WRN 09:20:07.927] Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak [WRN 09:20:07.927] To Debug, enable the define: TLA_DEBUG_STACK_LEAK in ThreadsafeLinearAllocator.cpp. This will output the callstacks of the leaked allocations [WRN 09:20:07.946] Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak [WRN 09:20:07.949] To Debug, enable the define: TLA_DEBUG_STACK_LEAK in ThreadsafeLinearAllocator.cpp. This will output the callstacks of the leaked allocations [WRN 09:20:07.970] Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak <repeat ad nauseaum> The workaround should be the same. Set the FPS of the game to 60 (I explain how here). Let me know if this fixes something. Your KSP instalment is pretty spartan, by the way. This will make things simpler to diagnose if the stunt I suggest works!

RCSs are easily added to TweakScale with something like this: @PART[the-partname-you-want]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } Works for almost every RCS radially attachable. If the thing is a block to be stacked up, use: @PART[the-partname-you-want]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[Engine]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = <size-of-the-part> // Check the bulkheadProfiles, and choose the bigger one. size1 = 1.25, size2 = 2.5, etc } } Stacks are terribly sensible to the defaultScale, please, please don't mess it up - really use the right value. On the other hand, if you don't give a piece of paper to standards and only want to have fun scaling things (hey, I do it sometimes too, ok? Your game, your rules), give All-Tweak a shot. Quick&Dirty TweakScale support for everything - no strings (or rules) attached. And it works fine most of the time - some really exoteric parts will fail on it, but... No risk, no gain. But you need to keep something on mind: your savegames will not be compatible with anyone else's KSP, neither with your owns if you install "proper" TweakScale support later for something (check the TweakScale Companion Program, by the way, I'm adding support for a lot of things latelly).

If you are on KSP 1.9, it's a known (and fixed) problem: you need to install KSP-Recall. This will fix this toe-stomping not only on TweakScale, but on Fuel-Switches too. If you are not running KSP 1.9, then it's something else. Place a note on TweakScale's thread with your KSP.log and Player.log and I will dive on it. Cheers!

less than 50m/s, I used a scaled juno as (real) propulsion. But the thing reached 120m/s at the end of the airstrip! This stunt gave me some ideas....

Me!!! And the car got trought in (almost) one piece!

Baby steps. I run out of time for modding this month! (yeah, real life...) I got rid of the redundant textures and meshes and started to use the ones from the KSP's instalment, taking advantage of a new feature of KSPe (KSP version conditional patching! yeah!). The next step is to optimize the textures that remained, as they have no equivalent on KSP and they are now the bigger space guzzlers. With the textures under control (and converted to DDS), the models will be refactored. I'm pretty sure there're duplicated vertices everywhere - I will do this by last because I want to resurrect an old tool of mine from my times on Orbiter (a lint tool for meshes). But as I said above, my time for modding this month is more than exhausted, this will have to wait a bit.

Eventually. https://github.com/net-lisias-ksp/TweakScale/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.4.4.1

How about things like this?

Yep. It's not the first time this thingy bites TweakScake. From the logs, all that warnings you are seeing are about the same part, the M2X.FF5WayRCS: [TweakScale] WARNING: TweakScale was externally deactivated on module on part [M2X.FF5WayRCS] 5-Way Mk2 RCS Block [TweakScale] WARNING: Duplicate TweakScale module on part [M2X.FF5WayRCS] 5-Way Mk2 RCS Block [TweakScale] WARNING: TweakScale was externally deactivated on module on part [M2X.FF5WayRCS] 5-Way Mk2 RCS Block There's 214 log entries complaining about this part in a way or another. What's really interesting is that there's 814 (!!!) complains about "TweakScale was externally deactivated on module on part". This is the last line of defense of TweakScale, triggered when something fails to remove, or shove a TweakScale bad data on the part by brute force, TweakScale detects the badly formed data and kills itself on the part to prevent damage. There's yet 83 complains about "Duplicate TweakScale module on part", what again hints we have a serious problem of bad patching on the instalment from @Tradyk. All of them on the same part, M2X.FF5WayRCS. This one is surely about bad patching, so I think we can assume the root cause of this torrent of complains are directly or indirectly related to bad patching. @Tradyk , please post your full KSP.log (and the Module Manager's ConfigCache too!) on TweakScale's thread and we will continue from there (at least this appears to be unrelated to Hangar) about this specific issue. This will lift some weight from @allista's shoulder. -- -- -- -- -- @allista, this one caught my eye: 7/24/2020 4:40:36 PM,KerbalAlarmClock,Vessel Change from 'rover lander hanger-2' to 'rover mk3 Probe' (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) dT is NaN! tA: NaN, E: NaN, M: NaN, T: NaN at System.Environment.get_StackTrace () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at Orbit.GetDTforTrueAnomaly (System.Double tA, System.Double wrapAfterSeconds) [0x00000] in <c168e21ec56346b082f89043e76162e1>:0 at PatchedConics._CalculatePatch (Orbit p, Orbit nextPatch, System.Double startEpoch, PatchedConics+SolverParameters pars, CelestialBody targetBody) [0x0 0000] in <c168e21ec56346b082f89043e76162e1>:0 at PatchedConicSolver.Update () [0x00000] in <c168e21ec56346b082f89043e76162e1>:0dT is NaN! tA: NaN, E: NaN, M: NaN, T: NaN at System.Environment.get_StackTrace () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 at Orbit.GetDTforTrueAnomaly (System.Double tA, System.Double wrapAfterSeconds) [0x00000] in <c168e21ec56346b082f89043e76162e1>:0 at PatchedConics._CalculatePatch (Orbit p, Orbit nextPatch, System.Double startEpoch, PatchedConics+SolverParameters pars, CelestialBody targetBody) [0x0 0000] in <c168e21ec56346b082f89043e76162e1>:0 at PatchedConicSolver.Update () [0x00000] in <c168e21ec56346b082f89043e76162e1>:0 (and this logs repeats itself in secula seculorum) I think there's something else on that KSP playing havoc with the game. TweakScale when borks (or it's borked by someone else) can shove NaNs on mass and some others physics parameters, but there's nothing on it that can affect the ticking of the simulation's clock. But the sequence of exceptions started exactly when the 'rover mk3 Probe' got the focus - so somehow they can be related. Keep me in the loop if you want. I need to find the source of all these bad patching or whatever - TweakScale just can't operate with invalid data, but yet, something is crazily shoving bad data into TweakScale these days!

Yep. You can use wildcards and carefully crafted :HAS patches, but since I expect that some parts would fail before others, you will probably ending up fallbacking to single part patching anyway - it's possible that some parts can be scaled to 100 meters, while others would not reach 30 or 40 without blowing up something. In a way or another, the joints will be easily overloaded - you will need KJR for sure sooner or later. Check the hotfixes and workarounds on the Extras folder of the TweakScale distribution for examples of how to write your patches. -- -- -- BRUTE FORCE POST MERGE -- -- -- I took way more time to fill you guys because I ended up discovering that, well, I didn't really borked on it and needed time to do a lot of testings in order to be really sure this time. Now I know that I could do better, but yet it would "fail" the same because the behaviour on KSP <= 1.7.3 is really different from the one on KSP >= 1.8.0 . Oh well... SNAFU. Life goes on. Cheers!

Not that hard, but a bit cumbersome for doing it right. As always, wet your feet cautiously, as too much big parts can lead to some physics attributes bigger than the physics engine can handle - if you have an incredibly big mass dividing something small (lift, by example), you can get a value too close to zero, and injecting this number on the physics engine can lead to some NaNs, and by then... So I don't advise to blindly shove this stunt on everything, but only on the few selected parts you want to have that size (and, so, minimising your surface of exposition to the problem): If the part uses a ScaleType called stack, use this: @PART[my-big-fancy-part]:FINAL { %MODULE[TweakScale] { //type = xxx - use this for stack and stack_square only! //defaultScale = xxx - Don't touch this thing! %scaleFactors = 0.1, 0.3, 0.625, 1.25, 1.875, 2.5, 3.75, 5.0, 7.5, 10, 20, 50 %incrementSlide = 0.01, 0.025, 0.025, 0.025, 0.025, 0.05, 0.05, 0.1, 0.1, 0.2, 0.5 } } If the part uses a ScaleType called free, use this one: @PART[my-big-fancy-part]:FINAL { %MODULE[TweakScale] { //type = xxx - use this for free and free_square only! //defaultScale = xxx - Don't touch this thing! %scaleFactors = 10 , 50 , 100 , 200 , 400, 5000 %incrementSlide = 1 , 1 , 2 , 5, 50 } } If the part uses a ScaleType called surface (some oldies still use it, and I like it more than free): @PART[my-big-fancy-part]:FINAL { %MODULE[TweakScale] { //type = xxx - use this for surface only! //defaultScale = xxx - Don't touch this thing! %scaleFactors = 0.1 , 0.5 , 1 , 2 , 4 , 50 %incrementSlide = 0.01 , 0.01 , 0.02 , 0.05, 5 } } Shove these stunts on a config.cfg file somewhere on your gamedata (I suggest GameData/__LOCAL/something for easy access and remembering) and you are set.

Jarre - Live on your living room!