Lisias

I find you lack of ecological caring... disturbing. I think it needs more heat dissipators thou. Curiously, if I turn off the gigantors, the Electricy Charge is not sustainable anymore after returning them on, and I need to turn the generators on too.

Sometimes I find my English skills.... Insufficient.

Yep, it handle resources its own way, but it also handles TweakScale events, so things just works - as long no other fuel switch is installed, when IFS waives the switching but still tries to scale the part when TS asks it. It's the reason TS yells when it finds more than one Fuel Switch on a part, as it can't know who is switching and who is scaling, with the net result of something borking on the Rescale and TS taking the blame. Users of KSPI didn't needed the KSP-Recall exactly due this - it was not affected by the resource overwritting. On TS, this triggers the TweakScaleRogueDuplicated stunt, and until recently was due rogue patching - patches that blindly adds an additional TweakScale module on a part instead of modifiyng the existent one. But this can be verified by inspecting the MM ConfigCache, and on this case the MM ConfigCache was ok, no double TweakScale on it..... Hummm... I'm an idiot. I didn't checked if anything else was double patched. I will check that file again and see if I find anything else duplicated on opt.sage . -- -- -- POST EDIT -- -- -- Yep. The opt_sage engine is double patched. There're TWO ModuleEnginesFX modules working on this part, I found both on the MM ConfigCache, so this is a double patching for sure. At least on TweakScale, only the first copy is active - knowing it, TweakScale declares the second a RogueDuplicate and get rid of it. But since you don't do it, the second module lingers around with incomplete data and when something tries to probe it, you have the NullReferenceException mentioned . [edit: Multiple ModuleEnginesFX are used by MultiModeEngine module. It's legit, it not the same as TweakScale] This is the two copies of the module I found on the ConfigCache: MODULE { name = ModuleEnginesFX engineID = WJOpen thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.03 minThrust = 0 maxThrust = 250 heatProduction = 160 useEngineResponseTime = True engineAccelerationSpeed = 0.7 engineDecelerationSpeed = 0.35 useVelocityCurve = False flameoutEffectName = flameout powerEffectName = running_open engageEffectName = engage disengageEffectName = disengage spoolEffectName = running_turbine engineSpoolIdle = 0.05 engineSpoolTime = 1.0 EngineType = LiquidFuel exhaustDamageMultiplier = 200 exhaustDamageMaxRange = 10 atmChangeFlow = True useVelCurve = False useAtmCurve = True PROPELLANT { name = ElectricCharge ratio = 3.1 DrawGauge = True } PROPELLANT { name = IntakeAtm ratio = 1 DrawGauge = True } atmosphereCurve { key = 0 300 key = 1 240 -22.22222 -12.72055 key = 10 190 -1.065011 0 } atmCurve { key = 0 1.5 0 0 key = 0.01 2 0 0 key = 0.1 2 0 -2.810402 key = 0.4 1.079561 -0.4394221 -0.4630589 key = 1 1 8.414095E-07 -0.2883541 key = 9 0 -0.1323353 0 } PROPELLANT { name = LiquidFuel ratio = 0 DrawGauge = False } } ---- copy two ---- MODULE { name = ModuleEnginesFX engineID = WJClosed thrustVectorTransformName = thrustTransform exhaustDamage = True ignitionThreshold = 0.01 minThrust = 0 maxThrust = 375 heatProduction = 190 useVelocityCurve = False flameoutEffectName = flameout powerEffectName = running_closed engageEffectName = engage disengageEffectName = disengage engineSpoolIdle = 0.05 engineSpoolTime = 1.0 EngineType = Electric exhaustDamageMultiplier = 200 exhaustDamageMaxRange = 20 PROPELLANT { name = ElectricCharge ratio = 101.927 DrawGauge = True } PROPELLANT { name = IntakeAtm ratio = 1 DrawGauge = True } atmosphereCurve { key = 0.001 3000 key = 1 30 key = 1.05 0.001 0 0 } } Ignore that PROPELLANT[LiquidFuel] at the end of the first copy of the module, it looks like my hack. I asked a fresh copy from @pmborg to confirm thou. This is the complete list of patches being applied to opt_sage: [LOG 10:51:11.317] Applying update Jettison/ModuleManager_Jettison/@PART[*]:HAS[@RESOURCE,!RESOURCE[Ore],!RESOURCE[Ablator],!RESOURCE[SolidFuel],!RESOURCE[ElectricCharge],!RESOURCE[MonoPropellant]] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:12.474] Applying update OPT_Legacy/MM_Patches/OPT_SAGE_VIsp/@PART[opt_sage]:NEEDS[B9PartSwitch] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:12.564] Applying update OPT_Legacy/MM_Patches/OPT_TweakScale2/@PART[opt_sage|opt_egg|opt_vtol_egg]:NEEDS[TweakScale] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:12.565] Applying update OPT_Legacy/MM_Patches/OPT_TweakScale2/@PART[opt_sage|opt_egg|opt_vtol_egg]:NEEDS[TweakScale] to OPT_Legacy/Parts/Engines/VTOL/EnginesEggDog.cfg/PART[opt_vtol_egg] [LOG 10:51:12.722] Applying update OPT_Legacy/MM_Patches/Category/Category/@PART:HAS[#manufacturer[OPT?Prop*Division]] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:12.852] Applying update OPT_Legacy/Parts/DepthMasks/Patches/@PART[opt_sage|J61] to OPT_Legacy/Parts/Engines/J61/OPT_J61.cfg/PART[J61] [LOG 10:51:12.853] Applying update OPT_Legacy/Parts/DepthMasks/Patches/@PART[opt_sage|J61] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:13.778] Applying update OPT_Reconfig/OPT_CTT/@PART[opt_surge|opt_sage|j81turbojet|opt_vtol_wrap?2|opt_vtol_jumpa2] to OPT_Legacy/Parts/Engines/J81/j81turbo.cfg/PART[j81turbojet] [LOG 10:51:13.778] Applying update OPT_Reconfig/OPT_CTT/@PART[opt_surge|opt_sage|j81turbojet|opt_vtol_wrap?2|opt_vtol_jumpa2] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:13.778] Applying update OPT_Reconfig/OPT_CTT/@PART[opt_surge|opt_sage|j81turbojet|opt_vtol_wrap?2|opt_vtol_jumpa2] to OPT_Legacy/Parts/Engines/SURGE/OPT_SURGE.cfg/PART[opt_surge] [LOG 10:51:13.778] Applying update OPT_Reconfig/OPT_CTT/@PART[opt_surge|opt_sage|j81turbojet|opt_vtol_wrap?2|opt_vtol_jumpa2] to OPT_Legacy/Parts/Engines/VTOL/EnginesAT-WJ.cfg/PART[opt_vtol_jumpa2] [LOG 10:51:13.778] Applying update OPT_Reconfig/OPT_CTT/@PART[opt_surge|opt_sage|j81turbojet|opt_vtol_wrap?2|opt_vtol_jumpa2] to OPT_Legacy/Parts/Engines/VTOL/EnginesWrapperWJ.cfg/PART[opt_vtol_wrapj2] [LOG 10:51:13.778] Applying update OPT_Reconfig/OPT_CTT/@PART[opt_surge|opt_sage|j81turbojet|opt_vtol_wrap?2|opt_vtol_jumpa2] to OPT_Legacy/Parts/Engines/VTOL/EnginesWrapperWJ.cfg/PART[opt_vtol_wrapl2] [LOG 10:51:13.778] Applying update OPT_Reconfig/OPT_CTT/@PART[opt_surge|opt_sage|j81turbojet|opt_vtol_wrap?2|opt_vtol_jumpa2] to OPT_Legacy/Parts/Engines/VTOL/EnginesWrapperWJ.cfg/PART[opt_vtol_wrapk2] [LOG 10:51:14.178] Applying update OPT_Reconfig/OPT_LiftSurface/@PART:HAS[@MODULE[ModuleLiftingSurface]:HAS[#dragAtMinAoA[>0.1]],#manufacturer[OPT*Division]]:NEEDS[!FerramAerospaceResearch] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:14.221] Applying update OPT_Reconfig/OPT_LiftSurface/@PART:HAS[#title[OPT?*],#manufacturer[OPT*Division]]:NEEDS[!FerramAerospaceResearch] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:14.621] Applying update OPT_Reconfig/CRP/OPT_B9PS_Cryo/@PART:HAS[#manufacturer[OPT*Division],@MODULE[ModuleB9PartSwitch]]:NEEDS[B9PartSwitch,CryoEngines|KerbalAtomics,!Pathfinder,!ModularFuelTanks,!RealFuels] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:14.683] Applying update OPT_Reconfig/CRP/OPT_IntakeAtm/@PART:HAS[@RESOURCE[IntakeAir],!RESOURCE[IntakeAtm]]:NEEDS[CommunityResourcePack] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:14.831] Applying update OPT_Reconfig/CRP/OPT_RCS_toggles/@PART:HAS[#manufacturer[OPT*Division],@MODULE[ModuleB9PartSwitch]]:NEEDS[B9PartSwitch,!Pathfinder,!ModularFuelTanks,!RealFuels] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:26.816] Applying update __LOCAL/hack/@PART[opt_sage] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:33.013] Applying update OPT_Reconfig/CRP/OPT_IntakeAtm/@PART[opt_sage|opt_vtol_wrap?2|opt_vtol_jump?2]:NEEDS[CommunityResourcePack]:AFTER[OPT_Legacy] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:33.013] Applying update OPT_Reconfig/CRP/OPT_IntakeAtm/@PART[opt_sage|opt_vtol_wrap?2|opt_vtol_jump?2]:NEEDS[CommunityResourcePack]:AFTER[OPT_Legacy] to OPT_Legacy/Parts/Engines/VTOL/EnginesAT-WJ.cfg/PART[opt_vtol_jumpa2] [LOG 10:51:33.014] Applying update OPT_Reconfig/CRP/OPT_IntakeAtm/@PART[opt_sage|opt_vtol_wrap?2|opt_vtol_jump?2]:NEEDS[CommunityResourcePack]:AFTER[OPT_Legacy] to OPT_Legacy/Parts/Engines/VTOL/EnginesWrapperWJ.cfg/PART[opt_vtol_wrapj2] [LOG 10:51:33.015] Applying update OPT_Reconfig/CRP/OPT_IntakeAtm/@PART[opt_sage|opt_vtol_wrap?2|opt_vtol_jump?2]:NEEDS[CommunityResourcePack]:AFTER[OPT_Legacy] to OPT_Legacy/Parts/Engines/VTOL/EnginesWrapperWJ.cfg/PART[opt_vtol_wrapl2] [LOG 10:51:33.015] Applying update OPT_Reconfig/CRP/OPT_IntakeAtm/@PART[opt_sage|opt_vtol_wrap?2|opt_vtol_jump?2]:NEEDS[CommunityResourcePack]:AFTER[OPT_Legacy] to OPT_Legacy/Parts/Engines/VTOL/EnginesWrapperWJ.cfg/PART[opt_vtol_wrapk2] [LOG 10:51:33.053] Applying update OPT_Reconfig/OPT_00Clean/@PART:HAS[#manufacturer[OPT*Division]]:FOR[OPT_Reconfig] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:33.093] Applying update OPT_Reconfig/OPT_B9PS_TAC/@PART:HAS[#manufacturer[OPT*Division],@MODULE[ModuleB9PartSwitch]]:FOR[OPT_Reconfig]:NEEDS[TacLifeSupport,!ModularFuelTanks,!RealFuels] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:36.260] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[!MODULE[AtmosphericIntake],@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir]]]:FOR[WarpPlugin] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:36.364] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#area]]:FOR[WarpPlugin] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:36.435] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#intakeTransformName]]:FOR[WarpPlugin] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:36.529] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#intakeSpeed]]:FOR[WarpPlugin] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:39.870] Applying update B9PartSwitch/PartInfo/@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FOR[zzzzzz-B9PartSwitch] to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:40.167] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:42.297] Applying update PartInfo/PartInfo/@PART[*]:Final to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] [LOG 10:51:43.173] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] This is the exact patching log I have on my rig except by one extra patch: [LOG 10:51:42.297] Applying update PartInfo/PartInfo/@PART[*]:Final to OPT_Legacy/Parts/Engines/SAGE/OPT_SAGE.cfg/PART[opt_sage] That it's part info that I didn't installed. But this is harmless for sure. Now the interesting part: my ConfigCache is also double patched for opt_sage, but my rig don't suffer of the NREs reported by @pmborg. Or this is something related to something else I didn't installed, or by some twist of fate the MacOS port of KSP is immune to this (the MacOS version is more resilient on some borderline situations related to multithreading).[nah, I managed to reproduce it. I was clicking on the right "wrong" button, instead of the wrong "right" button"] So, this is not about finding who is borking anymore - given the "rogue duplicated" situation, I take for granted that sooner or later someone will try to fetch some data from the rogue and bork. The task is to search and destroy the rogue patch that it's shoving the duplicate, and this patch is on one of the patches I listed above.[It was not a rogue patch. It's a legit use of double Modules, the problem is somewhere else].

The heat exchange is not scaling properly, there's something missing somewhere and I didn't managed to have the time to find it. The problem is that this exponent is not doing what it's expected to do - or perhaps, I'm misunderstood what it's expected to do and so I'm failing to tinker with it. There's no wrongdoing on a personal gaming. KSP is not a competitive game, there's no cheating, there's no wrong way of playing it. There's TechTree support on TweakScale for people wanting to give it a try, by the way - I just can't do it on Vanilla TweakScale because it will ruin any previously running savegame. I agree that TweakScale can spoil terribly an career game, but on the other hand, it can make it more interesting too: As trying to go Virgin Galactic with WW2 technology. It's up to the users to decide how they will use the tools I made available for them. Not to mention a myriad of interesting things waiting for being unlocked on KSP:

Nope, TweakScale is working fine with SAGE and B9 on my test rig, I would had detect any problem at first glance - I'm reproducing the @pmborg instalent gradativelly to detect exactly what's going wrong. Sounds more like an (bad) interaction between B9 and some other fuel switch, as it already happened in the past. I will get into it in the exact instant I install the conflicting Add'On

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. EDIT: I want to say that again. So many problems could had been avoided in the past if this poor decision making didn't happened at all.... ---- POST EDIT ---- And, finally, my thick skull finally got rid of some idealized misconceptions about MM and its Community, allowing me to see I had made a mistake. :FOR always create a "modname" on the MM's taglist, and :NEEDS only prevents the Patching Phase between :BEFORE and :AFTER . The full story will be found here.

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. ---- POST EDIT ---- And, finally, my thick skull finally got rid of some idealized misconceptions about MM and its Community, allowing me to see I had made a mistake. :FOR always create a "modname" on the MM's taglist, and :NEEDS only prevents the Patching Phase between :BEFORE and :AFTER . The full story will be found here.

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