Lisias

I don't have a 1.12.3 available for testing anymore, so I gave this a try on 1.12.5 (and, of course, on 1.4.3 too - why not? ). This is what I did: Launched the game, created a new sandbox called "test-doe" this step, obviously, is only executed the first time Opened the DOE Settings, clicked on Reset to Defaults and made sure the Flares and the SkyBox Dimming are enabled. Also enabled the Show Names on MouseOver. Closed the Settigns after clicking Apply. On VAB, loaded the Ion Powered Space Probe Launched it into LaunchPad Cheated it into a 6000000000 (9 zeros) orbit around the Sun. Made sure to move the camera to be between the Sun and the Probe (so the Sun was "behind me" for sure), and at the same time be able to see the flare of some planed, in my case, Duna. Quit the game to Desktop Reloaded the game, reloaded the savegame, got into Tracking Station, selected the probe and clicked on Fly. Nothing wrong detected - the Sky is not dimmed, and the flares are visible. Moving the camera around worked as expected - things got dimmed when the Sun appeared, and got back to be visible as the Sun is out of the view. I repeated this procedure on 1.4.3 and 1.12.5. I think you may be experiencing some 3rd party conflict, perhaps? Or something that is mangling with the game's life cycles?

Yep. I would love to have such limitations on the game - even as an option. This would impose real challenging on airplane designs! FS is, also, a very abstracted model, so not so realistic as it may sound - but it makes things more fun to cope with. And even by not being used on the procedurally generated blades for the thing, it can be "hacked" to be used on "hardcoded" engine meshes to match the actual number of blades on the thing. There's ModulePartVariant to switch meshes to models with 3 or 4 blades (more blades, better performance on high altitudes; less blades, better on lower altitudes). What I really liked on FS was making believe the space race had begun before the WW2 - so, what kind of carrying vehicles we would had? How would be launching a primitive rocket from a primitive airplane carrier? I spent weeks avoiding upgrading parts and facilites, trying to do the most I can with the current restrictions - as launching a kerballed mission to a fly-by over the poles on a suborbital trajectory from a biplane (as I could not steer the rocket from the launchpad yet), and still be able to recover and reuse most of the parts (and with primitive SAS). Months of fun and amusement, it was one of my best savegames to date. And, damnit, it's fun to fly biplanes. These ones are not going to use propellers!

Exactly my point. Extraplanetary aircrafts doesnt' needs to be spacecrafts! Check how NASA did with Ingenuity, Point taken. Something to consider about. I think this argument doesn't proceed. I'm talking about performance, not size. Kerbals still have about 1 meter high, so shrinking things this way would make the part unsuitable for them (and, in fact, I think that some are). Kerbin is about a third of the size of Earth, but have the same atmosphere height and the same gravity. So the parts should, ideally, perform in a way that would impose similar challenges to the user as the equivalent reallife™ counterpart - reaching the same altitude, but with a proportional autonomy. Again, what would be the point of having propelled engines if they would perform exactly as the jet ones? RSS usually rebalance the parts for their needs. I don't see why I should balance parts to be used on RSS if they are meant to be use on Stock. But the upscaled words argument has merit - if the stock parts performs good on upscaled world, so A+ should do. The parts should fit the game. That's the whole point. Do the research again for propelled bombers and fighters on real world. So they are currently meant to be used on sandbox, not on career. Ideally, you should do your first steps on flying using propellers, and only later research jet engines. Our fist space artefacts were transported by propelled crafts, the jet engines came common use only after the space age had started. And, as I said, things are esily patched. These are not mutually exclusive options. This is due how KSP simulates the fuel consumption and engine performance over altitude. The model is simplified and tied to the air intake consumption only - by the way, is how the power curve over altitude is simulated, by reducing the volume of the air intaking from the intakes. So, in essence, the fuel consumption for flying 1 hour at 100% trust is the same as flying 2 hours at 50% trust, no matter the altitude. This model works fine for rocket engines, but poorly on jet engines - and terribly on piston engines. It's not a matter of being possible or not. It's a matter of hating this kind of animation. I don't mind reworking the propellers to use stock animations, but I will not use them - I will keep the current animations as an option for people using Firespitter, as I do. I don't mod things I don't use. That's the point: I'm not using FS because I need, I'm using it because I like it. The code models engine power and propeller efficiency pretty nicely, it really makes difference between using a 3 bladed propeller and a 6 one. Using a too much powered engine with 2 blades will not convert all the power into trust, you need more blades. But adding each blade adds a bit of drag (and some weight!) on the thing, so you need to balance - and this is what makes things interesting on a LEGO style gaming as KSP, you need to balance things in order to get what you want, it's the whole point of the game!!

A Cessna Caravan has a max autonomy of 1070nm, or about 1980Km on Real Life™. Kerbin has an Equatorial diameter of about 3.770 KM. Earth (the real one) has about 12.740 KM. So Kerbin is about 0,29591837 times the size of Earth. So, if I want to make a Cessna Caravan correctly balanced for Kerbin, the thing should have about 320KM or autonomy! Otherwise, again, why bother building an add'on for propelled airplanes? People willing to throw balancing trough the window can cheat their way into the game, why spoil the game for people willing to have a balanced, challenging game using airplanes?

Exactly. Stock cockpits have an excuse for being heavy as hell - they are meant to go into space. Airplane Cockpits doesn't have such a role. The whole point of having an Add'On for Airplanes is to fly… Airplanes. If you want spaceplanes, you don't want propellers!

That's the problem: everything in KSP is trimmed to use engines that have the same thrust of their directly real-life equivalent counterparts. You need better balanced parts to use on that engines, otherwise what's the point on adding such engines at first place?

I'm working on something to fix that. Unfortunately, the original is not maintained anymore - more than one Fellow Kerbonaut submitted fixes in the last years, but the P/Rs are not merged or at least acknowledged. We will lost the propellers anymation, that so will need to be worked around using stock modules like the robotics do. Frankly, I hate this kind of animation. The current engines are way overpowered, a punny cesna engine is giving us as much power as the engine for an F-18 - frankly, ridiculous. The original FS support had done that right, AFAIK, and I'm working to resurrect that support and then rework the stock patches to mimic the same power curve. And I don't want to get rid of FS, I want to fix it somehow. But some people want to get rid of FS and still be able to use A+, so...

Getting rid of Firespitter will be hard and sad, because I love that little bugger. But yes, the main reason the BETA got out of the line is because I started to look for alternatives to it, but didn't did a good job on this first trial. What I intend to do is to do what I use to do on everything I lay my dirty pawns on: offer the user a choice: you will be able to use Firespitter if you have it installed, but I will reconfigure the thing to use Stock modules if you don't. You will not get a so nice experience without FS for some time, but you will get a working A+ at least. It's going to be some heavy work, but - hey, A+ deserves it.

What may be a bad move, as there are some subtle difference between Linux and Windows (and MacOS!) that is way harder to cope with when you already have a 1.0 release aiming only to Windows. Epic and Steam clients are a known pain the bottom on non Windows machines due this - I had to create blundles with tricked filesystems and then mount them on a directory to use these ones on MacOS. GOG client is the only one that just works on MacOS - exactly because they aimed Linux at the same time Windows. So, in a nutshell - there's a good chance that Linux and MacOS support will not be available for more than a year after 1.0 is gold. If ever.

Hi! I found essentially two issues with your rig: You are using Firespitter, and the deprecated patches included on TweakScale are outdated. Please install TweakScaleCompanion for Firespitter (or just the Überpaket and forget about dependencies). TSC Überpaket If you are lazy and just want to get rid of dependencies TSC for Firespitter. If you are minimalist and only wants to have installed what you really need. Parts with duplicated properties, usually meaning they were double patched. 18ConformalTank1, 18ConformalTank2, 25ConformalTank1, 25ConformalTank2, 31ConformalTank1, 25-31AD-2, 25-31AD, 25-37AD Digging further on your KSP.log, I detected that you have a pretty old ModuleManager DLL shoved somewhere in your GameData!!! To tell you the true, I'm surprised the damaged was restricted to only a few parts. [LOG 14:37:54.880] Load(Assembly): AoATech_1.3.9/GameData/ModuleManager.2.8.0 AoATech_1.3.9 is badly installed. Please completely remove the directory AoATech_1.3.9 from your GameData and install it correctly (i.e., the zip's folder AoATech_1.3.9/GameData/* contents should go into your <ksp_root>/GameData/). Be cautious to do not install that old ModuleManager DLL again. I suggest you to install ModuleManagerWatchDog. It would had detected and warned about this issue.

Hi. Drag0nD3str0yer decided to focus on his own project, and decided to step out. He did pushed some fixes, trough - thanks, man! Yes, but… Real Life™ issues terribly screwed up my free time, not to mention some pretty weird KSP weirdities that plagued me not only on this one. That published release is a BETA, and I'm somewhat embarrassed to tell it's not a good one. KSP2 will not be a thing for me for a long time, my main gaming is going to remain on KSP1 the foreseeable future - I'm a MacOS user - so you can expect anything I publish to be maintained to at least one year yet. Perhaps more. The next release will be on the works Soon™ - I would suggest everybody to avoid using anything from the "Plus" directory, as these assets are the ones Drag0nD3str0yer decided to incept into his new add'on and will be removed from AP+.

Nope, you misunderstood the problem. The bug was on handling a bad patching situation where 3rd parties were applying TweakScale twice. The bad patching were being applied by installing twice some add'ons, or by installing an older and a newer versions of another one at the same time, and at least one situation pinpointed above by @SeniLiX where apparently Module Manager is being instantiated twice, because every patch is being applied twice. The bug on TweakScale was on the code that was trying to survive the double patching, and this bug is fixed on 2.4.6.23. On the bright (or less dark) side, @luna_cat's problem is not this "everything patched twice" problem, as not every patch is being applied twice. On @SeniLiX case, every single patch I had checked was applied twice, including the KSP-Recall ones that I had confirmed was not installed twice on the rig (it was really the same patch being applied twice, not two copies being applied). On @luna_cat case it may be related to two copies of the same patch being applied (in this case, MM is doing right). This one is a new. I confirm, these three AddOns are being injected twice into PartCategories.cfg . — POST EDIT— @luna_cat, that's weird. I found this on your KSP.log: [LOG 16:20:05.610] Config(CUSTOM_PARTLIST_CATEGORY) Squad/PartList/PartCategories/CUSTOM_PARTLIST_CATEGORY What's not a surprise, since you had uploaded a "PartCategories.cfg" file for inspection. Problem: I'm not finding it on my rig! Since you have HLAirshipsCore installed, I found prudent to give this a peek since it's involved and I'm maintaining it. But I not only couldn't reproduce your issue on KSP 1.12.2 to 1.12.5 (I don't have 1.12.1 available anymore), as well I just could not find a "PartCategories.cfg" file on my <ksp_root>/Squad/PartList directory neither! To tell you the true, I found it on a pretty old KSP 1.4.1 test bed I had forgot laying around on my rig... I also didn't found any mention on in on ModuleManager sources. Right now, I don't think this is a ModuleManager problem. MM is completely "agnostic" about what he does, it blindly applies patches into ConfigNodes without knowing what it's doing, it's up to the patch author to know what they are doing - otherwise you would need to "reimplement" some KSP thingies inside it, whats not only unfeasible - it's plain nuts. The reason you are not being able to use the game appears to be this: [ERR 17:32:41.375] Input is null for field 'categoryName' in config node 'SUBCATEGORY' at System.Environment.get_StackTrace () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at ConfigNode.AddValue (System.String name, System.String value) [0x00000] in <a5c262f7fe724eb9918d4487db8b635e>:0 at KSP.UI.Screens.PartCategorizer.SaveCustomPartCategories () [0x00000] in <a5c262f7fe724eb9918d4487db8b635e>:0 at KSP.UI.Screens.PartCategorizer.AddPartToCategory (AvailablePart part) [0x00000] in <a5c262f7fe724eb9918d4487db8b635e>:0 at KSP.UI.Screens.PartDropZone.ButtonInputDelegate (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <a5c262f7fe7 at UnityEngine.Events.InvokableCall`1[T1].Invoke (T1 args0) [0x00000] in <12e76cd50cc64cf19e759e981cb725af>:0 at UnityEngine.Events.UnityEvent`1[T0].Invoke (T0 arg0) [0x00000] in <12e76cd50cc64cf19e759e981cb725af>:0 at KSP.UI.PointerClickHandler.OnPointerUp (UnityEngine.EventSystems.PointerEventData eventData) [0x00000] in <a5c262f7fe724eb9918d at UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerUpHandler handler, UnityEngine.EventSystems.Ba at UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventD at UnityEngine.EventSystems.StandaloneInputModule.ReleaseMouse (UnityEngine.EventSystems.PointerEventData pointerEvent, UnityEngin at UnityEngine.EventSystems.StandaloneInputModule.ProcessMousePress (UnityEngine.EventSystems.PointerInputModule+MouseButtonEventD at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent (System.Int32 id) [0x00000] in <9f35cb25d6a4409c8c02e911403f3f at UnityEngine.EventSystems.StandaloneInputModule.ProcessMouseEvent () [0x00000] in <9f35cb25d6a4409c8c02e911403f3f7f>:0 at UnityEngine.EventSystems.StandaloneInputModule.Process () [0x00000] in <9f35cb25d6a4409c8c02e911403f3f7f>:0 at UnityEngine.EventSystems.EventSystem.Update () [0x00000] in <9f35cb25d6a4409c8c02e911403f3f7f>:0 And now things made sense! You had created custom categories for yourself, and so KSP had saved them on the file "<ksp_root>/Squad/PartList/PartCategories.cfg". But KSP saves the whole shebang, not only your customisations. From this point, less than ideally written patches trying to create their own Categories on the GameDatabase fool ModuleManager into patching this file instead, and the net result is… double "patching". Worst, progressive patching, as in each KSP boots [ConfigCache rebuilding by MM] a new entry is added if I understood it correctly. And, yes, I easily reproduced the problem by creating an empty Custom Category called "unknown" and then restarting the game! So, in essence, you have found bugs - but not on Module Manager. The bugs are on: HLAirships SpaceY KSPIE The HLAirships one you can solve easily by deleting the file "<ksp_root>/GameData/HLAirships/Category/Category.cfg". HLAirshipsCore (the one I'm maintaining in behalf of the owner) appears to do the right thing, but I will double check it later. I suggest you to post bug reports to SpaceY and KSPIE maintainers. Pinpoint this post as reference (as well yours with the links to the logs). HLAirships (the old one) is not maintained anymore, so there's nothing you can do but to manually delete the file I mentioned. I had confirmed that HLAirshipsCore works fine when the file "<ksp_root>/Squad/PartList/PartCategories.cfg" exists.

This may explain why I have so few old friends remaining…

Hi! Uh… This one is on me. You have TS 2.4.6.22 installed where I made a pretty stupid mistake on a code that tries to workaround a kind of bad patching that It's manageable (someone shoving TweakScale twice on a part). The latest TS, 2.4.6.23, have this bug fixed. (you still have a case of bad patching, but as I said, this one is manageable - as long I don't screw up something!) Sorry for the trouble and cheers!

I don't have the slightest idea how I survived my younghood. The only reason I wasn't nominated for a Darwin Awards is the incredibly fact that I survived every time - just don't ask me how, because I don't know! There must be a psychological reason I'm so attached to this little freaking game!

Hey, great news! A fully diagnosed problem is a problem that we can prevent to happen again! May I suggest you to reach CKAN maintainers suggesting they mark them a conflict with each other? This will prevent some headaches in the future! Cheers and thanks for your time!

Terribly Kerbal, I say. Who didn't did that yet? https://www.instagram.com/reel/Cn-Sub2pAob/

These phantom problems are…. well… phantom. As long as you didn't installed or deinstalled anything from your rig, I can still use it as a benchmark for the problem - trying to find correlations to others KSP.log where the thing had happened. Correlation is not causation Causality - but they can be useful into finding a way to prove Causality. Thanks!

I'm starting to think something else recently published is raining hell on us, see my last post - absolutely weird as what you are describing. The Waterfall "Integrator" stunt would not had been instantiated without Waterfall and TweakScale being installed, because the loader checks for them before doing that. The message: [EXC 21:28:42.962] NullReferenceException: TweakScale not found! it's a nonsense on a healthy rig. The Integrator would not even be in memory if TweakScale wasn't installed! I will try to reproduce this here to see what I get... — — POST EDIT — — IT'S WORKING FOR ME. https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks/issues/5#issuecomment-1421910626 @AccidentalDisassembly, please fire up your problematic KSP, go to Main Menu then quit the game. And then send me your KSP.log, your ModuleManager.ConfigCache and your Logs/ModuleManager/* files. It's something happening in your rig, perhaps the same problem that's affecting @SeniLiX? It's a long shot, but if we have phantom instances of Module Manager on the system, we would have also phantom instances of TweakScale...

Just found this one, and it's pretty damn good, I say! Yothu Yindi - an Australian band formed by Aboriginal artists. Aussies will conquer the World - song by song!

Yep, you got caught by what appears to be a new batch of bad patching. I found the log entries that are bothering you: [LOG 22:57:17.281] [TweakScale] WARNING: Duplicate TweakScale module on part [US.1C10.Wedge.Quadcore] Universal Storage: QuadCore [LOG 22:57:20.084] US.1C10.Wedge.Quadcore added to ship - part count: 2 [LOG 22:57:20.102] [TweakScale] WARNING: Part US.1C10.Wedge.Quadcore has a Rogue Duplicated TweakScale! [LOG 22:57:20.240] [TweakScale] WARNING: Duplicate TweakScale module on part [US.1C10.Wedge.Quadcore] Universal Storage: QuadCore [LOG 22:57:23.210] [TweakScale] WARNING: Part US.1C10.Wedge.Quadcore has a Rogue Duplicated TweakScale! Misteriously, this part was deleted by someone right after these messages: [LOG 22:57:31.396] deleting part US.1C10.Wedge.Quadcore And I assure you it wasn't by me (everything I do is logged and have a tag identifying who has done it). So I kept digging, and found this: [LOG 22:38:15.892] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to UniversalStorage/Parts/US_1C10_Wedge_Quadcore/US_1C10_Wedge_Quadcore.cfg/PART[US_1C10_Wedge_Quadcore] < some other logs> [LOG 22:38:15.892] Applying update 999_KSP-Recall/patches/attached-on-editor/@PART[*]:HAS[!MODULE[ProceduralPart],!MODULE[WingProcedural],!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:LAST[KSPRECALL-ATTACHED-ON-EDITOR]:NEEDS[TweakScale] to UniversalStorage/Parts/US_1C10_Wedge_Quadcore/US_1C10_Wedge_Quadcore.cfg/PART[US_1C10_Wedge_Quadcore] I mentioned this because KSP-Recall is mine, and you can bet your mouse I care about my patchings. So this tends to rule out any addon as a source of the bad patchings, because I know for sure the above patch is solid - because I wrote and tested it myself. With this in mind, I kept digging for who would be being induced to bork the same - more as curiosity than anything else, because at this point I was thinking I already knew what's happening: [LOG 22:37:35.167] Applying update UniversalStorage/Compatability/US Tweakscale/@PART[US_*] to UniversalStorage/Parts/US_1C10_Wedge_Quadcore/US_1C10_Wedge_Quadcore.cfg/PART[US_1C10_Wedge_Quadcore] <some more log entries> [LOG 22:37:35.167] Applying update UniversalStorage/Compatability/US Tweakscale/@PART[US_*] to UniversalStorage/Parts/US_1C10_Wedge_Quadcore/US_1C10_Wedge_Quadcore.cfg/PART[US_1C10_Wedge_Quadcore] And now we have found the patch involved in the mess. I didn't cared to look on the patching itself, because the KSP-Recall entries above had already hinted this is a bad process of patching, not bad patches. This looks like having two ModuleManagers in memory at the same time - I had already diagnosed this once, I even wrote a tool to detected that. But I didn't found any rogue DLL on your rig, so this apparently this is not the reason, because I didn't found any rogue DLL listed in your KSP.log… So I choose a random part, nfa-atomic-jet-25-1, and tracked all the patchings this part had and: Applying update 999_KSP-Recall/patches/attached-on-editor/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update 999_KSP-Recall/patches/attached-on-editor/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update 999_KSP-Recall/patches/refunding/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update 999_KSP-Recall/patches/refunding/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update AtmosphereAutopilot/csurf_sync/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update AtmosphereAutopilot/csurf_sync/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update Diazo/AGExt/part/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update Diazo/AGExt/part/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[@MODULE[Refunding]]:NEEDS[KSPRECALL-REFUNDING]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update KSPCommunityFixes/MMPatches/ModSupport/KSPRecall/@PART[*]:HAS[@MODULE[Refunding]]:NEEDS[KSPRECALL-REFUNDING]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update NearFutureAeronautics/Patches/NFAeroCTT/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update NearFutureAeronautics/Patches/NFAeroCTT/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update ProbesBeforeCrew/Mod Support/ZsNF-AeronauticsPatch/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update ProbesBeforeCrew/Mod Support/ZsNF-AeronauticsPatch/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update StationScience/MKSEffects/@PART:NEEDSto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update StationScience/MKSEffects/@PART:NEEDSto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScale/Deprecating/patches/NF/NFA_TweakScale/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScale/Deprecating/patches/NF/NFA_TweakScale/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/000_CleanUp/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/000_CleanUp/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/000_CleanUp/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-multimode-25-1.cfg/PART[nfa-atomic-multimode-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/000_CleanUp/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-multimode-25-1.cfg/PART[nfa-atomic-multimode-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/Engine/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update TweakScaleCompanion/PKMC/NFA/patches/Engine/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update UmbraSpaceIndustries/Konstruction/Patches/EVAConstructionTweaks/@PART[*]:HAS[!MODULE[ModuleCargoPart],#mass]:Final to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update UmbraSpaceIndustries/Konstruction/Patches/EVAConstructionTweaks/@PART[*]:HAS[!MODULE[ModuleCargoPart],#mass]:Final to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PARTto NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to NearFutureAeronautics/Parts/Engine/Atomic/nfa-atomic-jet-25-1.cfg/PART[nfa-atomic-jet-25-1] (I removed the timestamps to allow ordering the logs and making the double patch better detectable). Wow… EVERYTHING IS BEING PATCHED TWICE. Absolutely everything. This is a Module Manager issue. I suggest you cry for help on MM's Thread, as I can't help further on this one!

ANNOUNCE Release 2.4.6.23 is available for downloading, with the following changes: The fix for the ScaleType Migration Code on 2.4.6.22 ended up creating a new bug on the TweakScaleRogueDuplicate security feature, leading KSP rigs infected with this problem to crash when trying to save the game. My bad. Really sorry. HUGE KUDOS to GoAHead on Forum for their invaluable efforts on helping me on diagnosing this problem. I would not had done this one by myself. Closes Issues: #290 Regression on handling the TweakScaleRogueDuplicate patching problem. #289 Yet another unexpected Misbehaviour, this time on PartModule.OnSave. See last NOTAM for details. On a side (and sad) note… I still don't know why the code on 2.4.6.22 had to be written (salvo for this unhappy line of code that I let pass unchecked). Sooner or Later™ I will need to revisit this issue. Disclaimer By last, but not the least... 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. The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong - as it did with .22...

Hi! Only found this today, sorry for being late. If you are scaling parts down, the Crew Capacity is reduced accordingly - and eventually you will get a part too small for holding a crew. Ideally, scaling up would add crew - but KSP since 1.8 or 1.9 shut this door definitively for TweakScale. Squad implemented a cap on it and any attempt to scale crew up is squashed on launch. Sorry.

NOTAM A bug on a workaround code for an old problem was found on TS 2.4.6.22 . TL;DR: in the past, bad patches were plaguing the TweakScale ecosystem, and one of that bad patching is injecting TweakScale twice in a part. I don't need to explain what would happen with two TS modules trying to scale the same part at the same time. We can easily reproduce this using the following patch somewhere in your GameData @PART[strutCube]:FINAL { MODULE { name = TweakScale type = screwed defaultScale = 3125 } } From this point, all strutCube parts will have two TweakScale sections in your craft and sfs files: Everything was fine for some years, until I had changed something on 2.4.6.22 to solve another issue, and created this one by accident. A fix is currently work in progress: https://github.com/net-lisias-ksp/TweakScale/issues/290 The workaround for this problem is to revert back to 2.4.6.21 until the next release is published - or to fix your patching. I may had created a bug on the workaround code for this problem, but the trigger for it is still a bad patch. I would recommend to @AlonzoTGto double check his installation, as I had said initially - or perhaps just stop modding your KSP, if you don't know how to do it properly. @Luna Cat, @Professor K, please send me your Logs/ModuleManager/* contents and your GameData/ModuleManager.ConfigCache for inspection. You guys do have rogue patchings in your rig, and these are a known source of problems. This doesn't excuse TweakScale from this problem, but ideally you should get rid of those too! I will gladly help on the task. Last, but not least, I want to give a huge thank you to @GoAHead for their invaluable help on diagnosing this one. I had completely forgot about this TweakScaleRogueDuplicate stunt, I would never be able to diagnose this one without such marvellous help. TweakScale 2.4.6.23 is on the works, and it will be issued as soon as possible™.

Yes, I'm getting some of these reports lately. Unfortunately, these are not happening on my rig. I had already diagnosed at least one case, but I need confirmation before going public with my findings. Can you please send me your full KSP.log after reproducing the issue? You will find this file in the same place where the KSP's executable is.