Lisias

To tell you the true, autostruts can be a source of problems when docking heavier vessels. Everything autostrutted to the root or to the heaviest part will suddenly be "reautostrutted", and this can cause wobbles big enough to destroy the craft. So perhaps avoiding autostruts across docking ports can ended up being beneficial - but this will break some of my designs for sure, now and then I use docking ports as stage separators (exactly by their superior resilience). I wonder if an Add'On could selectively "fix" this - perhaps a "bypass autostrut" toggle option? That would be a nice solution for the problem - allowing the user to disable the autostruts bypass or not. Well, some of mine surely will.... On the other hand, I heard that the EAS Struts will be maintainable by Kerbals, so perhaps using an Engineer to (re)place some EAS Struts between the docked parts could be a viable work around for this problem.

I wish there would be a way to buy one of these from Brazil...

I have another plausible explanation for this. One that I just detected, by the way, I made a mishap on an add'on in which I ended up abusing the Garbage Collector. On a sane system, I would be causing some stuttering but on Unity I ended up locking the whole program - it happens that when the Garbage Collector is collecting, everybody else needs to halt waiting for it (you can't easily allocate or access memory in the mean time, as the GC is meddling with the heap). Apparently, Unity is using spinlocks on the waiting threads, and this is plain stupid on a heavy threaded system! Every waiting thread using a spinlock would occupy a CPU (or a hardware thread on a CPU - a hyperthread as Intell calls them), and since we have a very finite number of CPUs available, if you have threads enough waiting for the GC, the high number of spinlocks will halt the whole process, as they will compete with the GC thread - the spinlocks will prevent the GC from running while the spinlocks wait for the GC to terminate its business - a catch 22 situation. Module Manager, by its own nature, is another piece of code that heavily stress the Garbage Collector. I also had a borderline situation on MM where a reboot had solved the issue, what's plain nuts because the OS (MacOS on my case) zero up the memory before giving it to a process. So memory corruption is not an option (mainly because nothing else on the system crashes). But the use of spinlocks where a MUTEX is needed explains this problem - MacOS is nasty with memory hungry processes, as it compresses memory on the fly (RAM Doubler or SoftRAM style, for people that tried this stunt on Windows 3 and 95), and these things also taxes the CPU. If you have a lot of spinlocks bullying the CPU, everything on the system will slow down, including a simple malloc.

It's the UNIX EPOCH. On UNIX, the timestamp 0x000000000000000 is January 1st, 1970 0:00:00.000 Zulu (GMT-0 - or Greenwich Time). Since USA is some hours earlier than Zulu (East Cost Time is GMT-5), January 1st, 1970 0:00 Zulu is December 31st 1969 19:00 on the USA's East Cost. The server hosting Forum is probably on USA, so this explains this date: the posts got their timestamp zeroed (the default value for most uninitialised data), then it was converted to a ISO 8601 datetime localised to some USA time zone.

yes you are. as a matter of fact, you just did. It doesn't matter what I believe. We are not talking about religion or something like that. What's matter is if it's possible, how are the chances of that happening, and what I can do to mitigate the risks I would take. Risk Management. It bites. Now take what I said and multiply by every stakeholder on this history. Welcome to the desert of the real: it's not enough to be good, you must convince people that it's good - and this is slightly more difficult when you have some karma attached. I wonder how the new pos-pandemic zeitgeist will affect this. Remote jobs are popping out everywhere, business demanding physical presence or proximity are going to fight competition from the whole World... or cleaned up, perhaps? Waving workforce and later hiring again usually suggests some structural problems on the company. Granted, can be anything from an a internal power struggle to financial problems - but in a way or another, it raises some eyebrows. my opinion is that KSP2 was meant to be released on the 10 years mark, and 1.7.3 was intended to be the final KSP1 release. But something happened and they decided to push KSP 1.8 and newer, being this last ones a contingency plan being run in background at that time - just in case. I'm pretty sure the pandemics really screwed up things on the Plan B too.

Some people knows the value of Reputation while merging teams. Less than adequate management (between many other factors) create stains on the working force's psique that usually cause problems while integrating them on an already stablished and funcional team where a more sane culture is already consolidated. Sometimes, it just don't worth the effort -- being the reason that merging organisations usually implies in a bloodshed on the receiving end of the merge (as correctly explained by Dientus). Internal culture plays a really important role on this matter. If you are a member of a team being merged where no one is being dispensed, be aware of the incredible luck you have and value this opportunity that is denied to many.

If you speak portuguese, this little jingle is even worse!!!!! (it's a local Nissan ad for their trucks - this jingle is a MEME around here) (note - safe for work version )

Think on the GameDatabase as it was a filesystem, with a twist: "../" means the parent dir (or node), but the current mode is given by "/" - while the "root" is given by "@". It's a bit confusing because everybody is used to "..", "." and "/" to do this job. So, think on the nodes as directories, and the values as files. You have, so, something like this (names ending with "/" are directories on this representation): PART[DM-RFC]/ MODULE[ODFC]/ ODFCMaxEC MODE[MP]/ MaxEC FUELS/ MonoPropellant MODE[LFO]/ MaxEC FUELS/ LiquidFuel Oxidizer What you wrote, so, is something like this: PART[DM-RFC]/ MODULE[ODFC]/ ODFCMaxEC MODE[MP]/ MaxEC = ../MODULE[ODFC]/ODFCMaxEC // Whoops! FUELS/ MonoPropellant MODE[LFO]/ MaxEC FUELS/ LiquidFuel Oxidizer MaxEC will take a value called ODFCMaxEC from a MODULE[ODFC] that it's on its parent, i.e., it's looking for a module that it's "its brother". What is not what you want, the value is not inside a "brother" module, it's on its parent itself! PART[DM-RFC]/ MODULE[ODFC]/ ODFCMaxEC MODE[MP]/ MaxEC = ../ODFCMaxEC // This should work! FUELS/ MonoPropellant MODE[LFO]/ MaxEC FUELS/ LiquidFuel Oxidizer So, what you need is: @MaxEC = #$../ODFCMaxEC$ when in doubt, "simulate" the GameDatabase on the file system the way I did. Things will be easier this way. Cheers!

Yes, it is. Stock + DLC will be handled by TweakScale itself. The Companions will handle everything else. You request is (almost eternal... ) Work In Progress at this moment. https://github.com/net-lisias-ksp/TweakScale/issues/46 (Serenity is the codename for the Breaking Gound DLC). Once KSP 1.12 is released and settled down (the last releases were, unfortunately, pretty disruptive and we can only hope that 1.12 will break this trend), development on TweakScale will come back to rails (another sad fact is that Real Life is pushing really hard on the last months -- and I can't complain, as my bills are being paid). There's a roadmap for TweakScale here: https://github.com/net-lisias-ksp/TweakScale/milestones and, besides I'm not being able to deliver deadlines, the roadmap is being effectively fulfilled as (real life) time allows.

I feel your pain, bro. Same here. You may be abusing a bit your swapfile, 90 minutes is really too much... But there're some things you may try to mitigate the problem: Activate filesystem compression on the GameData folder. This will minimize the hard disk I/O considerably (not to mention the space savings), what will speed things a bit for you. Windows NTFS has a transparent file compression available, right-click the GameData folder on Explorer and navigate until you find a property called "compression" or something (longe time since I used a Windows Machine). (I would not compress the whole drive, I had problems doing it in the past) Not every file worth being compressed. Files that are written regularly (Word files, images, savegames, etc) usually don't worth the trouble. On MacOS, see this thread. On Linux, BTRFS has this option (the best compression level I ever used, by the way) Lower the Texture Quality on Main Menu / Settings / Graphics. On the Rendering Section, you will find a Slider called Texture Quality. It's usually on Full Res, and the other options are Half Res, Quarter Res and Eighth Res. Everybody is upgrading the Textures to 4K nowadays, and this not only is a waste for people gaming on 1080p, as it more than doubles the memory needed for textures both on GPU as on GPU (including loading times). By lowering this setting, the Textures will be downgraded on loading, saving you some precious memory. Even if you have a beefier machine, if you are playing on 1080p this setting would save some VRAM, allowing you to get better FPS or even rendering the game playable on cheaper GPU cards. The bad side of this solution is that Textures that are fine for 1080p will be downgrade too (it's all or nothing), and this can render the U.I. somewhat problematic (some widgets can get so blurred on Eighth Res that you can't tell if a checkbox is checked or not. I usually use Half Res, and some installments of mine are even on Quarter Res! Consider adding a HDD to the machine, and move KSP to another disk than were your swapfile are. Reading files at the same time you are swapping memory to the same disk is terrible to I/O, as the HD's heads will jump like crazy between the cylinders where KSP is stored and the cylinders where the swapfile is. And every time the heads have to move, I/O halts. If you are adventurous, you can buy a cheap SSD (120G is more than enough), install it and use it only for swapfile. This SSD will not live too long, so don't store anything valuable on it. It's best to do not store anything at all, as the more free space you have on it, more the SSD firmware will mitigate the writings to minimize wearing and more it will live. It's counter-intuitive, but since you only load a game once per session, but use swapfiles all the time, you will notice the machine sensibly more performatic on average than using the SSD to store the game and the harddisk to store the swapfile! Good to know! Cheers!

I'll try to simplify things to allow easy understanding - once we understand the basics, we could dig into the gore details (and I don't know all of them anyway.. ). There're info on the Kerbal that are meant to be changed and preserved; there're info that can be changed but will be thrown away later; and there're some info that just can't change, as they are used as primary keys inside the game. Things that are preserved are saved automatically by KSP into the ROSTER once you recover the Kerbal. If you want to save additional info, usually you write a custom PartModule, patch it into the Kerbal's prefab, and on your code you handle the OnSave event (what to save and where to save it will be handle on that custom module!). Some other things are just thrown away when you recover the Kerbal- for example, the amount of EVA fuel on the older KSP versions. But some few things cannot be changed otherwise KSP (and everybody else) will lose track of the objects - by reading your logs, I'm concluding that the Kerbal's name is one of that things. When you correlate information from different objects, you need a Primary Key (something that univocally identifies a thing): Kebal A is piloting Vessel B, Kerbal C is a passenger on Vessel D, etc - so you can't have two kerbals named A, or two Vessels named B... There's a thingy called InstanceID that univocally identifies an object at runtime, but this is only valid at runtime - once you recover the object (or save the savegame), these InstanceIDs are thrown away and the next time you launch that Kerbal (or anything else), it will gain a new one. So the InstanceID is kinda a temporary Surrogate Key valid during a session (like a token on a webpage). So we are back to the Primary Key problem (i.e., that thing that will identify the Kerbal between gaming sessions): it happens that the Kerbal's name is that Primary Key! So, if you change the Kerbal's name at runtime, when you recover the Kerbal (or save the game), the KSP's code that would preserve the persistent data from the Kerbal will not find it on the ROSTER, and since this is a situation that was considered out of scope of the implementation (we just don't change a Primary Key of an object), the code doesn't handle this exception and so BADABOOM!! #leelooFeelings Since I don't know exactly what you are planning to do, I don't know what to suggest - but on a wild guess, perhaps creating a new Kerbal for the job (using some other as a template) would not do the job? It's important, believe me. In the past, KSP was "protecting" us by doing every callback inside a try-catch block - so we could bork as we wish without screwing up things: def execute_physics_frame(world): for game_object in GameDatabase.AllGameObjects: for module in game_object.modules: for callback in module.callbacks: try: execute(callback, parms) except ex as Exception: Log.exception(ex) But.. Try-catches are terrible expensive: every time you enter a try block, the runtime needs to create a new stackframe in order to handle the block, and once you leave the block, the stackframe needs to be cleaned. A lot of nested stackframes on every call on every animation frame of the game, and you will lose easily about 5 to 10% of the CPU juice only handling stackframes! So ideally we need to get rid of all try blocks to save a lot of CPU power, that so can be used on new shinny things: def execute_physics_frame(world): for game_object in GameDatabase.AllGameObjects: for module in game_object.modules: for callback in module.callbacks: execute(callback, parms) But that have an undesired effect: since an uncaught exception will halt the whole execution until the stackframes's top level, if we bork something down here the caller of the execute_physics_frame will be halted - and so, the whole game can crash!! (and yeah, you just learnt why sometimes we have a CTD - Crash To Desktop - on some games!) So KSP is getting rid of try-catches only on hot code (i.e., parts of the program that are called all the time!) in order to prevent a CTD. But yet, now we can't just bork things as we were used to do without injecting collateral effects on third-parties: def execute_physics_frame(world): try: for game_object in GameDatabase.AllGameObjects: for module in game_object.modules: for callback in module.callbacks: execute(callback, parms) except ex as Exception: Log.exception(ex) (I don't know if this is really how KSP handle things, but my empirical tests suggests it's something near this) Now, knowing that KSP needs a Primary Key to keep track of things at runtime, and knowing that missing Primary Keys throw Exceptions inside your callbacks, we can see why, usually, it's a bad idea to just shove an empty try-catch on borking code to mask exceptions, instead of properly handle them (or prevent them to happening). IMHO, that's the way to go (at least, it was what I did when I was starting here). Everybody was a beginner in the beginning and the best way to learn things is... Making mistakes and then fixing them. And, frankly, fixing bugs is a hell of an effective way to get your feet wet: What's broken? Why it broke? How I fix this? And, now, how in hell I proper fix that damned thing without creating new bugs? Once you are able to answer these questions, things start to make sense. And then you write a Mod, are bitten by the modding bug and now you are doomed like the rest of us.

Welcome! Lets' dig on this new one... No. You had a problem of double patching (i.e., when someone applies TweakScale again disregarding any previously existent patch). This was pretty nasty at a time because the code that were responsible for "migration" of scaling was not working due a change on KSP, and so having a double patch would would render your scaled parts corrupted if by any chance the order of patching was altered - only the first patch is used, if it vanishes, the second patch would be used and then weird things could happen: And so TweakScale, on saving, renamed all the non used patches to "TweakScaleRogueDuplicate" to prevent this from happening. So, you had an annoyance glitch in the past, and now that the glitch is not more, this is just an echo from the times the glitch was happening. You can safely ignore this, as it will be removed as you save the crafts again. On the other hand... I found this on your KSP.log: [LOG 17:50:23.794] [TweakScale] INFO: WriteDryCost Concluded : 3081 parts found ; 1 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 0 Sanity Check failed; 1101 unscalable parts. One of the sanity checks failed to execute, and looking for it I found this: [LOG 17:50:23.456] [TweakScale] ERROR: part=opt.vtol.wrapj1 (OPT-E FVT-J) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <06f13185617646e5bc801baeab53ab75>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <06f13185617646e5bc801baeab53ab75>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <06f13185617646e5bc801baeab53ab75>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <06f13185617646e5bc801baeab53ab75>:0 at ConfigNode.CreateCopy () [0x00006] in <06f13185617646e5bc801baeab53ab75>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <06f13185617646e5bc801baeab53ab75>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x00005] in <f137bf7c0dfc4221bd660b246ac5a59f>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <f137bf7c0dfc4221bd660b246ac5a59f>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <f137bf7c0dfc4221bd660b246ac5a59f>:0 at error:0 There's something happening preventing TweakScale from checking the Config Node for opt.vtol.wrapj1 (OPT-E FVT-J) . I don't have the slightest idea why this happens sometimes - it's something borking inside KSP's guts for sure, by why this is happening I never figured it out Since this part was not checked, it may be borked or it may be working fine. Just to err on the safe side, create something with this part scaled, save it, reload it, launch it, restart to launch, go to the main menu, reload back the savegame and check if it keeps working fine.

One problem you have for sure is that MM appears to do not understand negative indexes (the relevant source code is here, if you are really curious, your use case starts to be handled here). After parsing your path, in the very end the index is handled here. This function, FindValueIn, starts looking on index 0 of the array, and stops as soon as the selected index counter is negative. Since your index is already negative, it returns the first value. This explains that command returning the "0 0.17 0 0" value, as it is the first entry on the "array". (The wiki also states negative indexes are not yet supported here, look for "(,<index>)?"). However, your second problem is confusing me. This post explains that "[0, ]" should be working as expected - you want the second value from a space separated list of values, so the expected result should be 0.17... Perhaps some bug on the parser? Try this: %temp = #$MODULE[ModuleWheelMotor*]/torqueCurve/key,-1$ %topTorquePoint = #$temp[0, ]$ -temp = Kill me! It's a wild guess, but if this works it will result with 0.17 on the topTorquePoint - what at least solves part of your problem while we try to tackle down the other part (perhaps a hack using MM_PATCH_LOOP ?)

How about this one? -- -- post edit -- -- Could not resist this one (watch at your risk)

On the other hand, you can save some EVA fuel on the stunt...

Please be cautious with this. Consider the following meta-program (python style - I completely pulled it out of my hat, I'm trying to make a point, not to solve a problem): class EarnYourStripes: class CrewPanelMonitor: @KspEvent def OnEditorShipCrewModified(self, ship:ShipConstruction): try: modifiedCrewList = self.buildModifiedCrewList() overwrittenCrewList = self.GetCrewToOverwrite(modifiedCrewList) for crew in modifiedCrewList: self.announce_crew_modified(crew) for crew in overwrittenCrewList: self.handle_crew_overwritten(crew) except: # In God we trust! :P pass def GetCrewToOverwrite(crewList:list) -> list: r = list() # yada yada yada yada if self.something_wrong_happens_randomly: throw RandomException("duh") return r def handle_crew_overwritten(crew:Kerbal): self.remove_crew_from_roster(crew) self.announce_crew_removed(crew) new_crew = self.rename_crew(crew) self.announce_crew_modified(new_crew) def handle_crew_modified(crew:Kerbal): self.warn_kerbalism_about(crew) self.warn_courageoustourists_about(crew) # etc, etc, etc def announce_crew_removed(crew:Kerbal): # yada yada yada yada # etc, etc, etc That pseudo-code kinda mimics what you said you are doing, but using hypothetical tasks to make things easier to explain. By that hypothesis, the OnEditorShipCrewModified does what follows: Build a list of Kerbals that were modified, but were not "overwritten" (whatever is this) Build another list of Kerbals that were "overwritten" Announce every Kerbal that was modified to Kerbalism, KourageousTourists, etc (again, I'm pulling this from my hat - I don't know if you need to announce these changes to anyone) Handle the crew members that were "overwritten" delete it from roster announce to everybody that that crew member were removed (so they will not crash by trying to access it) get a new member based with the removed one's data (but renamed) announce this new crew member to everybody, so they know there's a new kid on the block Now imagine that we get an Exception on GetCrewToOverwrite as it's happening to you in real life. What this means? Well, code will abort execution on that line, and everything until the end of the caller's try block will not be executed - Kerbalism and KourageousTourists (on this example) will not be notified about the changes and then may behave erratically!! So, if you really don't know how to fix this, but somehow this new code fixes something even worse on the wild - and so, you are replacing a nasty bug with one less nasty - the less horrible way to cope with this problem is, so, to do as follows: @KspEvent def OnEditorShipCrewModified(self, ship:ShipConstruction): modifiedCrewList = self.buildModifiedCrewList() try: overwrittenCrewList = self.GetCrewToOverwrite(modifiedCrewList) except: # oh, well... FIXME ASAP! overwrittenCrewList = list() for crew in modifiedCrewList: self.announce_crew_modified(crew) for crew in overwrittenCrewList: self.handle_crew_overwritten(crew) Doing things this way will, at least, allow the modifiedCrewList to be handled correctly. Did I made myself understandable? This is really important, you may be inducing third parties to bork doing what you are doing if you are doing the way I think you are doing... This is not only a hypothetical situation - these things really screwed me up on my first year on maintaining TweakScale: things go badly somewhere else, but TweakScale was the one borking because it needs something that was not done somewhere else due that bork. And this is a proverbial Pain in the SAS to diagnose! I would advise against a Pull Request with the empty Try Catch he is using at this moment to overcome that Exception - unless this is really the only way out of the mess. Things may appears to work on his machine, but once this stunt is published, it may (probably will) induce undesired collateral effects on third parties that will rely on that code to be fully ran. Once that process is aborted on the middle, things that should had been done will not.

Yes, that's for sure. A Companion for Wild Blue is planned, but I confess I delayed it (a lot) due the changes happening on KSP since 1.10. I have successfully worked on scaling KIS containers, for example, but since KSP 1.11 KIS have some problems with the new Stock Inventory System (not to mention TweakScale itself, I need to understand this too before applying patches for it on the main distribution). Trying to work WBI Omnistorage would open yet a new front on this battle, so I'm dragging my feet a bit on this one. I'll probably work on it after I implement proper TweakScale support for the Stock Inventory. In a way or another, there's a task for it already : https://github.com/net-lisias-ksp/TweakScaleCompanion/issues/12 Did you installed the TweakScale Companion for Visuals? Without it, TweakScale don't know now to handle WaterfallFX. TweakScale just shutdown itself down when you do not scale a part, so it's pretty improbable that TweakScale would be causing this problem on unscaled parts - but, granted, it's not impossible (I may had borked on the shutdown proceedings on unexpected situations...). Well... There's a way to be sure about: backup your savegames (just in case...), uninstall TweakScale, create a new savegame and try to reproduce the problem on a unescaled CryoEngine to see what happens. Then shutdown KSP, reinstall TweakScale and redo the process on the same savegame you used before. This will rule out or confirm TweakScale as a trigger for the problem - and, with the full KSP.log from the session you managed to reproduce the problem, I can try to hunt the problem being triggered.

Kerbals are essentially special one part crafts and, so, have a prototype or "template" on the prefab from where they are instantiated on the Scene. And, exactly as any other part, any change you do on an instantiated ("living") Kerbal is lost once the part is destroyed or recovered. With a twist - there's a list of available Kerbals on a place called ROSTER where the currently instantiated Kerbals are kept (including the killed ones!). Do a test: open a SFS file on a good Text Editor (or better, make a copy of a SFS file and open it - just in case...), search for the word "ROSTER" (all upcase) and see how this data structure is stored on the file. You will have something similar on the memory once you load the savegame. If you want to permanently rename a Kerbal on a savegame you need to change its name on the ROSTER, and from that point every time you "select" the Kerbal on the SPH or VAB (where the available Kerbals are already instantiated), they will be spawned with the new name. There's an old Add'On, CrewManifest, that creates and spawns new Kerbals on a Scene. Check its code to see how they do it. Alternatively, you can just directly edit the SFS file (being extremely careful to prevent screwing up something - always do backups!). (remember: it's pointless to rename a spawned Kerbal, you need to rename the template on the ROSTER before it is spawned)

Well, let's play Jack The Ripper (let's do it by parts ): CryoEngines doesn't scales! You need TweakScale support for it, currently unavailable I'm working on a new Companion for Post-Kerbin-Mining-Corporation non NF add'ons - but I will work on it only after KSP 1.12 is on the wild and I checked if it will break any of my Add'Ons (and fixed it, of course) CryoEngines doesn't have nice plumes! You need WaterfallFX support for it, but I don't know if it is available. Check with the Waterfall guys for it. Until there, you may want to use SmokeScreen. I had read that Waterfall "reuses" SmokeScreen configs, so perhaps installing SmokeScreen will "fix" this problem by colateral effect? CryoEngine scales fine and have nice plumes, but the plumes are not scaling! You need to install TweakScale Companion for Visuals (currently in alpha) Report any problems on the TweakScale Companion Thread. Except by the Plumes being unscaled on Revert to Launch, as this is a known issue. "My God! It's full of Fatalities..." THIS is what I can fix here. See below Well, you sent me Player.log, not the KSP.log - TweakScale doesn't logs on Player.log, only on KSP.log - and some logs gets truncated on the Player.log, hindering the diagnosing - see what's logged on your Player Log: [TweakScale] INFO: WriteDryCost Concluded : 1335 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts Now compares with some other KSP.log from a problem I solved in the past that I have on my records: [LOG 13:53:52.997] [TweakScale] INFO: WriteDryCost Concluded : 1155 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 304 Show Stoppers found; 0 Sanity Check failed; 310 unscalable parts. As you see, Player.log truncated the line, and now I'm missing the very information I need to save me a lot of work: how many Show Stoppers and how many Sanity Checks failed you have. On the bright side, I didn't found any TweakScale log with a WARNING or an ERROR, so apparently there're no patch errors on you rig. But without the KSP.log, I can't be sure.

This is not exactly how Laws work. The final interpretation of the meaning of a License is defined by a Court in Common Law systems, and the License is not helping neither. "Primarily" is somewhat vague: a retired professional those only activity is to maintain CC-NC material under patronage is doing it as a primary activity? The only activity explicitly exempted from the Non Commercial activity is file sharing! Additionally on the same license: Please note that on granting the License, the "primary" word is not used. But even by that, since we are talking legalese, we need to use legal terms properly. The definition of "primary" is: https://www.lawinsider.com/dictionary/primary-activity And this is the interpretation a Court of Law will use if someone gets sued. Yes, it is. Every citizen is subject to his local laws first. Always. The USA's Copyright Act is only enforceable on USA, and there's nothing someone can do about. Some of the protections of the USA's Copyright Act is enforceable here where I live because there're local laws saying that. Additionally, from the very same license: What it's an explicit concession that the License is subjected to the local laws of the user. (By the cold letter of the law, the first paragraph s redundant, because there's no legal way for a License to overrule a Law. Point. This clausule is merely informative.) The second paragraph is trying to "salvage" the situation where that happens (the opposite of what the GPL does, by the way, that essentially fully nullify itself withdrawing any granted rights). But this is exactly how Law works. On Common Law countries, the only real "official" interpretation is given by a Court of Law. On Roman Law countries, by the letter of the Law itself (and when the law needs further interpretation, by a"High Court"). Any provision to the contrary is null and void. This is exactly how Copyright works. And this is the reason that Copyright needs International Agreements in order to be enforceable on a country. https://www.rightsdirect.com/international-copyright-basics/

You need support for both TweakScale and Waterfall on a part to have it scale the plumes. Publish the KSP.log and the Module Manager Patch log so I can inspect it and see who is borking on the patching. Without these logs, I can't help. See the post previous to yours to get instructions about how to locate and publish these logs.

As a matter of fact....

This is not exactly TweakScale's problem, it's a third party patch messing up: you have a rogue patch on your GameData. But without the KSP.log, I can't help. Please publish the KSP.log and the Module Manager Log so I can't diagnose the problem and propose a fix. See the OP (under the Spoiler on the Support subtitle) for instructions. Additionally... 90 minutes to load the game is too much... How much memory you have? How about moving the KSP to an SSD? This will improve the loading time a lot, and if you tell the O.S. to transparently compress the GameData, it will help even more!

The problem with the NC option is that it prevent any kind of commercial use, including the indirect ones. On USA, a professional doing volunteer work on his area is considered Commercial Activity, because it's understood that the guy is promoting itself (marketing) while doing the work. So, theoretically, professional programmers should not touch code licensed under CC-NC (at least on USA). The same for 3D modellers on 3D models, and so on. Additionally, you cannot ask for patronage neither, as it is also considered a Commercial Activity on USA. (and if you don't file an Organisation under the 503 C 3, you can't receive donations, by the way - so without it, any money you receive is patronage, and so it's a commercial relationship).

I have no words!!! Starr Bumble Bee II - (allegedly) the smaller plane in the Word.