Lisias

I still don't a clue about what's happening to you, but at least I can say the thing is working for me. Check if the downloads are set to automatic for you. Mine are automatic and with priority.

My understanding of the question was about the Hero / Anti Hero epic as related to the Dharma. The Anti Hero did everything by the book, but died anyway - and then the questioning about the point of doing the right thing. My point is that it's pointles to expect rewards by doing the right thing. We do the right thing because it's the right thing to do, and the suffering (or price) we pay by doing it only happens because other people choose to do nothing, or decided to be rewarded by doing whatever it's need to be so - what's not uncommon to be the bad thing. An interesting characteristic of the truly righteous is that it's not unusual they reject being called righteous. They did it because it was needed to be done, and they were in the position of doing it. So they did, with or without the suffering. I think we’re converging on what we meant, besides disagreeing in how we say it? The suffering was irrelevant. He would do it with or without the suffering. And he didn't choose to suffer, he decided he would not allow the other guy to die, besides any suffering. Suffering that he endured because a lot of other people, by omission or directly acting in evilness, put these people in that horrible situation. Just imagine all that people of that terrible era doing what's right, besides a little suffering.. This was the reason for Kolbe's suffering, not his commitment to save lifes. The meaningfulness of the suffering, or if he was defeated or victorious is out of scope of my arguing, by the way. I do nit intent to make any judgment of value on this.

I have a different view. My answer to your answer is NO. We do the right thing. Point. End of history. We don't suffer by doing the right thing. We suffer by others don't doing the right thing. Your choice? You can choose to be the one that stops the suffering, or the one that allows the suffering to linger, affecting everybody else. That history about the Hero and the Anti-Hero? It's more or less like this saying, attributed to Bruce Lee : "Expecting life to treat you well because you are a good person is like expecting a tiger will not attack you because you are a vegetarian." The Dharma history is telling you to do not expect fighting the good fight and be rewarded by your enemy doing the same. You fight the good fight because you need to do so, and onde you decide to fight, you don't put yourself on a situation in which your defeat can only be avoided by your adversary being like you. If your enemy was as you are, they would not be your enemy, you would be fighting with them, not against them. So, the Anti-Hero lost his life not because they did the right thing. He lost his life because he expected that his adversary would do the right as he. But if the adversary would be the type that do the right thing, they would not be fighting each other at first place!

Yeah. Lots of things are now making sense. When KSP 1.4.0 came to light (2018/March), they already had about 9 months on development (2017/August). Of course they probably didn't had a full 30 people team at that time, but the planning were already done and the work should had been started already. The somewhat big amount of bold moves they did on the KSP 1.4.x with some of them later abandoned or half done (Mission History) and not promoted by the P/R guys always rendered me uncomfortable. At that time I was guessing TT2 were testing KSP1 to decide to start or not a new code tree for the game, but as it appears this was the initial plan since the buyout. What made KSP 1.4 and newer a laboratory where we were the guinea pigs. The stagnation on some Add'Ons development and bug fixing also rendered me smelling a rat - this information should had leaked way before the official announcement. "Le Roi Est Mort, Vive Le Roi!"

It was never a TweakScale issue. Not in the past, not nowadays. What happens is that TweakScale is the most used Add'On borking due the bad patching, so now TweakScale is complaining about. It's a third parties Add'Ons problem, and this Is happening for years already. With or without TweakScale installed. — post edit — The safer TweakScale release is always the latest one. As new problems are identified, they are detected and mitigated.

Hi. I had being asked (more than once) if this overrules and hotfixes of mine are definitive fixes, if they can be used safely, etc, etc, etc. So I though it could be a good idea to try to explain, better this time, what at heck are these stunts after all. Overrules An overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things "broken" in a deterministic way. Rogue patches usually renders the GameDatabase in a unsafe state, but sometimes they just messes things without provoking crashes on the game. So, once these situations are detected (i.e.: messed up GameDatabases but that doesn't explodes under our noses), a overrule can be created to keep only some parts "broken" in order to keep ongoing savegames… ongoing. This is needed because, now, savegames are intrinsically tied to the GameDatabase on the host installment. Modules preset on the GameDatabase that are not present in the savegame are injected while loading. It wasn't always this way - some KSP versions ago, and I tested it until 1.4.5, absent modules on the savegame would render parts in memory without that modules - so this is a relatively new problem. Older KSPs probably don`t need this - but yet, rogue patches are undesirable anyway. There're three problems on this approach: I brute force my way into the GameDatabase, disregarding everything else. This is bad because an additional Add'On would like to change something (as a new scale type), and the overrule will bluntly throw away everything and shove a recorded in stone configuration that used to work on the time I wrote the thing. So every time a new Add'On that patches something with TweakScale is installed, we need to make sure that the overrule are still valid. This keeps the GameDatabase in a unholy (besides controlled) state, and so every craft and savegame will only work on a broken installment. It's, indeed, only meant to prevent you from losing your savegame. It prevents the part to be checked by the Sanity Checks. Since the thing is essentially breaking the part, it would rise an "Houston" on TweakScale. So… if you mess up a Overrule, TweakScale will not detect the problem. HotFixes A HotFix is something like a Overrule, except that instead of breaking the part to keep an ongoing savegame alive, I effectively fix the part as it should be at first place. They are meant to be used while the Add'On Author/Maintainer doesn't applies a new Release with the fixes, or when the Add'On is stalled and cannot be adopted and fixed due Copyright reasons (as being ARR or CC-*-ND). This is less worst than an overrule because crafts and savegames are now interchangeable between different (sane) KSP installments. But there're two problems on this approach: I brute force my way into the GameDatabase, disregarding everything else. This is bad because an additional Add'On would like to change something (as a new scale type), and the overrule will bluntly throw away everything and shove a recorded in stone configuration that used to work on the time I wrote the thing. So every time a new Add'On that patches something with TweakScale is installed, we need to make sure that the overrule are still valid. It prevents the part to be checked by the Sanity Checks, as sometimes it will force a condition that the Sanity Check thinks it's bad, but it was found to be a false alarm. So… if you mess up a HotFix, TweakScale will not detect the problem. Conclusions Overrules and HotFixes are not final solutions for the problem. They are temporary workarounds that fix the problem under our noses, but can create new ones later, and are meant to be used as last resource only. The only real and safe solution for the problem is reaching the offending Add'On Author/Maintainer for a new release with the problem fixed. In the mean time, and as always, you can reach me here for help when things go through the tubes. No savegame will be left behind. Link to my site where this essay will be updated now and then http://ksp.lisias.net/blogs/tech-support/TweakScale/Hotfixes-and-Overrules

Guys, Whoever is still using Mercurial on Bitbucket, it's time to migrate to GIT. Bitbucket is deprecating Mercurial: The procedure is easy enough: Install stuff virtualenv -p python2.7 ~/python . ~/python/bin/activate pip install dulwich urllib3 brotli ipaddress or if you don'd mind installing stuff directly into your System sudo pip-2.7 install dulwich urllib3 brotli ipaddress And then follow the instructions on https://hg-git.github.io Windows users will need a slightly different procedures, but it's essentially the same thing. Some older KSP projects are hosted in Bitbutcket, and perhaps some of them are using Mercurial. It seems a good time to clone and convert them for historical reasons!

Something doesn't computes as it should... <before> [LOG 21:57:50.566] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 97 Sanity Check failed; <after> [LOG 10:29:16.960] Config(@PART[*]:HAS[@MODULE[TweakScale]&@MODULE[ModuleFuelTank]&@MODULE[ModuleB9PartSwitch]]:NEEDS[TweakScale]:FINAL) __LOCAL/TweakScale/HotFixes/ModuleFuelTank--ModuleB9PartSwitch--Prefer-B9/@PART[*]:HAS[@MODULE[TweakScale]&@MODULE[ModuleFuelTank]&@MODULE[ModuleB9PartSwitch]]:NEEDS[TweakScale]:FINAL [LOG 10:34:24.349] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 97 Sanity Check failed; There're no TweakScale relevant differences between both logs (before and after the HotFix). DO NOT use that HotFix, it's not working as I intended. My understanding of MM patches need some work, I will fix this as time allows.

Wake up listening to this on my head today.

It's not a bit early to target KSP 1.7.4 ? "NAME": "Firespitter", "URL": "https://raw.githubusercontent.com/snjo/Firespitter/master/For%20release/Firespitter/Firespitter.version", "VERSION": { "MAJOR": 7, "MINOR": 13, "PATCH": 0 }, "KSP_VERSION":{ "MAJOR":1, "MINOR":7, "PATCH":4 }, (excerpt from the Firespitter.version from the most recent download here)

Welcome! ("Hawa"?) Yes, but no necessarily. Running "business" late night can be 'dangerous' — we start to do things by muscular memory, and end up spreading outdated information. Things are somewhat more manageable with HotFixes, a stunt that I implemented recently. A HotFix is just a patch with a marker that TweakScale recognizes and shows a message on the screen, they are not special by themselves. What make them special is how I handle them: with care. Since these things are essentially mangling with other people's works by their backs, if something changes (as a correctly written third Add'On that delete everything and applies its own sets of rules), these HotFixes can start to break things instead of fix them, and then the backslash would be somewhat… "uncomfortable". That`s the reason I was restraining myself from openly publishing fixes before cooking a way to keep track of them - what ended up being more simple than I initially thought, by the way. Kind of overreaction from my part. Patches are patches, if they work on 1.4.0, they work on 1.3.1. The latest Module Manager 4 apparently works on 1.3.1, so you should be good by applying the patches on 1.3.1 too. (and if stock MM4 borks on 1.4.1, talk to me - I have a custom fork that I tested down to 1.3.0, and I think 1.2.2 but don't remember exactly if everything worked right). TweakScale, by now, doesn't works on 1.3.1, but it's possible to backport it to support 1.3.1 if there's demand. I'm working on supporting 1.3.1 on some Add'Ons since some time (note: one of the KSPe library objectives, if you peek TweakScale dll files), so perhaps this would be a nice addition to the 2.4.x series from TweakScale. Moving straight to 1.7 can be traumatic, a lot of things changed (and not always for "better" - KSP 1.7 run slower then 1.3.1 on the same machine), if 1.3.1 suits you perfectly and there's nothing on newer ones that you want to use, sticking to 1.3.1 can be a viable option. Yep. In a way or another, the patch only removes one of them when both are installed, that hot fix don't delete anyone when just one are there (or when TweakScale is not installed on the part - I just checked things with TweakScale, so I decided to be prudent on this). Installing just one of them on the KSP is the easiest way out of the mess, obviously. But with hotf ixes it's feasible to keep both (besides worksome, as someone need to cook hot fixes all the time). You need to see my 1.4.5 installment. I preserved it (I had invested a huge amount of time on it), and I'm using it as a test bed. First time I run the beta version of TweakScale 2.5 (where everything will be running as it should), I got 172 FATALities alone (I don't even remember how many warnings…). In a way or another, it's not user's fault. It's not necessarily even Author's fault - people borks, people borks all the time. What rendered us in this mess was ignoring that we are prone to bork instead of applying safeties to allow people to bork, safely detect the foolish and then fix it. Until now. Hey, I did some FORTRAN77 on college. Even managed to do some task on punch cards I saved mine, by the way. Good. But I just realized I need to fix the message, it's misleading! It should say "there's no way to scale them", not "used them". Well, fixed for the next release. Okie dokie! Welcome, and thanks! (I like dogs) Vish… (local expression for "irrc" or something). So, something is blindly shoving MFT in your installment, without even caring if MFT is available or not. So applying the patch "prefer-MFT" would kill your installment. Well, someone needs to check every patch being applied to that affected parts and fix them using :NEEDs or something. Well, at least this implies that these 97 parts are false alarms - without MFT installed, the MFT module is ripped out from the part on the crafts. (or it should, at least - some KSP internals changed slightly on the past months, so it would be wise to check this info just in case). Welcome. It's not that hard, and since you are an UNIX freak as me , cat , pipes, grep and wc are your friends. I will check the new logs by night.

Hi! A Customer! Welcome! (cleaning up the dust from the balcony) FATALities are a problem, because they ultimately lead to savegame corruption, and demands a human (Kerbals didn`t managed to cut it yet) to inspect what`s happening and fix it (or workaround it). Yellow boxes are Warnings and/or advises. They are telling you that something needs to be remembered due reasons: Overrules (specially crafted patches meant to keep the game broken in a controlled way so you can keep playing your current savegames) and HotFixes (brute force fixes to the installment, allowing you to create new savegames that will keep compatible with future releases of the Add`Ons, as well to older releases of Add`Ons that cannot be updated by some reason). I call these Sanity Checks: Parts not supported yet. These ones will disappear as I implement proper support (see the Road Map on the OP). Parts that fails to be checked. I don`t do anything about because, well, I failed to check it - so it can be good, or can be bad. I`m tackling down these ones as I realized what`s wrong and fix the code. The difference from the "Houston" errors from the Warnings for parts that are not Sane is that these ones I can bluntly withdraw support because they never did or will work correctly, and any savegame with it is already doomed. The only safe approach to these parts is not allowing TweakScale to touch them, so at least you can use them safely (without scaling, however). It`s a pain in the SAS, but other than an annoyance, that`s all. The "Houston" are serious because the patching itself is bad, and can render a good savegame into a trashcan. You install the bad patch, open your savegame, save your game, and now you are doomed - deinstalling the patch will ruin everything that it`s flying with the affected patches. Once it happens, you need to keep the affected parts "broken" in a deterministic way, and this is the job of the Overrules. A HotFix aims to fix the patching into a sane way, compatible to things made right. They are meant to be used while the offending Add`On is not updated, or when it is stalled and not updated anymore and can`t be fixed due copyright reasons (ARR or Non Derivatives). Both of them must be deleted as soon as they are not needed anymore, because they interfere with the normal patching process, brute forcing something into the game. Well, I think you can now be somewhat assured that only "Houston" problems are really nasty, and the others are just temporary annoyances that, ideally, will vanish by themselves as I implement proper support (for that few parts I do not support yet) and the Add`Ons are fixed (and so, patching is sane and overrules and hotfixes are not needed anymore and can be deleted). Now, let`s crack that nut: Ugh… Somewhat messy installment: [LOG 11:04:48.461] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 18 Show Stoppers found; 97 Sanity Check failed; Let's solve the FATALities first. [LOG 11:04:48.340] [TweakScale] ERROR: **FATAL** Part truss-octo-01 (Octo-Girder Modular Truss XL) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.340] [TweakScale] ERROR: **FATAL** Part truss-octo-02 (Octo-Girder Modular Truss) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.340] [TweakScale] ERROR: **FATAL** Part truss-octo-03 (Octo-Girder Modular Truss Mini) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-04 (Octo-Girder Modular Truss Micro) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-adapter-01 (Octo-Girder Modular Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-adapter-crew-01 (Octo-Girder Pressurized Adapter) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-angled-01 (Octo-Girder Modular Angular Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-angled-crew-01 (Octo-Girder Pressurized Angular Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-attach-01 (Octo-Girder Radial Attach Node) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.341] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-01 (Octo-Girder Pressurized Truss XL) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-02 (Octo-Girder Pressurized Truss) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-crew-03 (Octo-Girder Pressurized Truss Mini) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-125 (Octo-Girder Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-25 (Octo-Girder Heavy Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-docking-octo (Octo-Girder Octagonal Docking Connector) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-drone-01 (Octo-Girder Guidance Unit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.342] [TweakScale] ERROR: **FATAL** Part truss-octo-hub-01 (Octo-Girder Modular Hub) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 11:04:48.343] [TweakScale] ERROR: **FATAL** Part truss-octo-hub-crew-01 (Octo-Girder Pressurized Hub) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). Well, they all have duplicated properties. It's almost certain that something is installed twice on your installment. Let's pick one of the parts and see: [LOG 00:53:10.876] Applying update Contares/Patches/CONTARES_TweakScale/@PART[truss-octo-*] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02] [LOG 00:53:45.036] Applying update TweakScale/patches/NFT_TweakScale/@PART[truss-octo-crew-02] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02] [LOG 00:54:22.916] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02] [LOG 00:55:43.522] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02] [LOG 00:55:43.910] Applying update B9PartSwitch/PartInfo/@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FOR[zzzzzz-B9PartSwitch] to NearFutureConstruction/Parts/Truss/truss-octo/truss-octo-crew-02.cfg/PART[truss-octo-crew-02] Every patch that touched the "truss-octo-crew-02" are listed above. Of course this is not bad by itself, we need to figure out the ones double patching TweakScale on the part. Since a fellow Kerbonaut already had reached me with something similar, I already know how to fix it. See this post for details. I want to quote myself from that post here: This will ensure things will be patch as Contares' Author want it to be. However, this will break any savegame with flying crafts that uses one of these 17 parts, as due the patch's flaws, they are being overwritten by TweakScale ones . So, perhaps you would want to delete "GameData/Contares/Patches/CONTARES_TweakScale" instead - but by doing so, you risk losing the patches that are fine, and then you will have other parts not behaving as expected. I recommend to install S.A.V.E. and try both approaches to see the one that will work for you. Alternatively, I will publish a HotFix for Contares on the TweakScale repository using your ConfigCache as source (thanks for it, it make things easier to me), so at least you can keep things how they are in a safe way and keep playing. Stay tuned. The best solution is to reach the Contares's Maintainers and ask them to fix the patches as I explained here. This will fix everything and for good. About hat 97 warnings…. 9 of them are about parts with ModulePartVariants with mass. These ones are ok for now, I will implement support for it as time allows (see that Road Map) 7 of them are about parts with FSbuoyancy. Same thing, this will be solved as I have time to understand how to scale these. 81 of them are ModuleB9PartSwitch together ModuleFuelTank . Well, there's not too much I can do. A part can only have one Fuel Switch, but some patched blindly shove themselves into parts without caring if there's another Fuel Switch already applied. You can delete the previous patch and add yours, or you can ignore the part - both options are perfectly fine. But ideally you can't have both, as no one tells TweakScale who is the right one to obey and then **kaboom**. My best advise is to choose one Fuel Switch and stick with it, deinstalling any other from your installment. It's possible to have many Fuel Switches installed on the same KSP, but they need to guarantee that only one is being applied to a part. Until there, there's nothing else one can do. You can safely use all that parts, no problem. You just can't scale them until the problem is fixed. — — POST EDIT with FIXES — — Well, I think I managed to cook some HOTFIXes. @sierralpha, I think this will interest you too! This is a HotFix, so it will brute-force its way into the GameDatabase. Bluntly. But at least, you have a choice about who you want to brutalize with the patch! These patches will only work when TweakScale is installed and being used on the part, as I don`t have notice of problems happening when TweakScale is not installed on the part too. Contares problems can be fixed are follows: Download (click on the Raw button) or extract from the distribution file the TweakScale/Extras/TweakScale/HotFixes/Contares--TweakScale.cfg file. Move it into some place on your KSP installment. Be sure to remember where, as you would want to delete it once the Add'Ons maintainers fix the problem. I suggest to use GameData/__LOCAL/TweakScale/HotFixes/ — — — About the Fuel Switch problem, if you prefer to use MFT over B9 (i.e. if both Fuel Systems are installed on a part, you want to keep using MFT): Download (click on the Raw button) or extract from the distribution file the TweakScale/Extras/TweakScale/HotFixes/ModuleFuelTank--ModuleB9PartSwitch--Prefer-MFT.cfg file. Move it into some place on your KSP installment. Be sure to remember where, as you would want to delete it once the Add'Ons maintainers fix the problem. I suggest to use GameData/__LOCAL/TweakScale/HotFixes/ Otherwise, if you prefer B9PartSwitch over ModularFuelTank (what should be considered as B9 switches a lot more things than only fuel), do what follows: Download (click on the Raw button) or extract from the distribution file the TweakScale/Extras/TweakScale/HotFixes/ModuleFuelTank—ModuleB9PartSwitch-—Prefer-B9.cfg file. Move it into some place on your KSP installment. Be sure to remember where, as you would want to delete it once the Add'Ons maintainers fix the problem. I suggest to use GameData/__LOCAL/TweakScale/HotFixes/ I didn't have time to proper test these things, so please use S.A.V.E. and also publish again your ConfigCache so I can Eye Ball the thing and be sure everything is fine. I will check it myself as time allows, but until there, consider these patches as untested (because untested they are!) — Warning: The two patches above (about Fuel Switches) are not working, I will edit this when I fix the things!

No, I didn't. What you did was more analog to criticizing Contact from Carl Sagan because it wasn't Cosmos. KSP is a game. A Science Fiction game, to be more exact. We are kicking green butts into orbit on a fictional planet somewhat bigger than a moon, besides having the gravity of a full planet - not to mention having an atmosphere with the consistence of mocotó broth using a myriad of different engines running on "fuel" no matter what (not to mention jets that work under water).

The other aspects of this argument were already handled above, but I want to talk about this one. Of course he would report it as "habitable", that dude is a gamer designer. He need to grasp on every possible plausible concept in order to keep some contact with the reality, otherwise the history will not stick as Science Fiction and will be tagged merely as Fantasy. I got an argument once with my father, he didn't liked 007 moves (that I love) because they were unrealistic. My reply? "Of course it's unrealistic, it's a fiction movie! A realistic movie would end the franchise on the first movie, with Bond dead in the first 15 minutes!!!". Elon Musk took 10 frakking years to have a reliable, recoverable and reusable Launch Vehicles. It's hard to believe that someone would play a realistic game where you would need to do the same - no to mention buying the damned thing.

Oh, boy…. I did it again? I'm checking what the heck I did this time. I'll be back in a moment. — post edit — It's with a lightened heart that I inform I'll not be alone on the Asylum for the Senile Kerbonauts. You already had merged it. https://github.com/linuxgurugamer/ModularFuelTankExpansion/pulls?q=is%3Apr+is%3Aclosed Cheers!

Not from me, not from the game. But I didn't found a better place to post this, and it is too good to not be posted! (on a spoiler anyway)

No one can force your wife to wave rights. The US Constitution and Legal system are crystal clear on this. You can be induced to wave your rights, but not forced into it. There must be consent. However, exercise prudence. To win a legal battle, you don't need to win in court : you can induce the adversary to bankruptcy on legal fees. And I don't think these guys are that dumb - they are obviously dishonest, but this doesn't means necessary they are stupid. There're loopholes on the law about what can be considered consent, and even if this would not ultimately stick on court, the legal fees can be enough to make you wish you had given that consent after all. In time, do you know this site? https://en.wikipedia.org/wiki/Glassdoor

The best engineers never go to Space - but, boy, we attend a lot of funerals.

Yeah, mas you missed the broader scenario. The important is getting the adversary with a formal accusation of wrongdoing. Once the accusation is dismissed, the divorce is already judged - and the judge will rule using the facts he/she have in hands, i.e., one of the litigants has a formal accusation of wrongdoing. I was wrong. You didn't missed the broader scenario. One of the parts is building a public Circus in order to influence the Public Opinion to be used as a weapon on the trial. I suspect things are going to be a lot worse. Poor kid.

So don't implement it properly. Make things happening faster "outside" the the Current Frame of Reference for things under Relativistic rules, and make things happening slower for them when the current Frame of Reference is under Newtonian rule. You don't have to implement the thing - it's good enough to mimic their effects on artifacts under the user's perception. The only extra complication I see is having to track time separately for artifacts under Relativistic rules.

Its a bogus claim to poison her image to try to gain sympathy and earn advantages on the divorce. It works very well when the defendant… exercises an more orthodox sexuality.

YOU did signed that NDA ? (call your layer before trying the stunt, however).

Welcome. Well, you almost did it. You need to unpack the ModuleManager DLL into GameData directly, and then you unzip the Ubiozur zip on the desktop, and move just UbioWeldingLtd into GameData, like this: The 2.5.3 kinda works on 1.7.3. I remembering fixing some bugs on my fork, but you will need to install dependencies to use it. In both ones, you will have some problems on welding parts with Variants (as the fuel tanks). I think it will be more productive to use 1.5.1 for welding, but then you would need to copy some textures from zdeprecated into the original place (SXT from LGG has a script that does that for you). Let me know if you need some more help! Weld safe!

I like Blondies.

Thanks. I found the problem on both sides (patch, and lack of proper check on TweakScale). The problem on your installment is TMasterson5 TweakScale Patches. It naively sets the scaling type to "free" on everything without checking if TweakScale is installed, neither if the part is supported. @PART[wheelReg3] { %MODULE[TweakScale] { type = free } } There's nothing preventing this patch to be applied if TweakScale is not installed, or the part has not support for TweakScale (i.e., TweakScale is installed, but no one had patched the part). And there're no patches for Grounded's wheels currently (not from me, not from Grounded's Maintainer). Additionally, when (by luck) the part is already patched, the "type" has not the "%" operator, so a new instance of the attribute "type" will be added - and this will make TweakScale panics later, issuing a "Houston" on you (as two "types" is one of the known situations that can ruin the scaling rules for crafts, including flying ones. nasty). Every single patch from TMasterson5 TweakScale Patches (and not only this one) must be edited to something like this: @PART[wheelReg3]:NEEDS[Grounded] { @MODULE[TweakScale]:NEEDS[TweakScale]:FINAL // Should be :AFTER[TweakScale], but TS doesn't uses :FOR yet. { %type = free } } I reopened Issue #30 to handle the detection of this variant - it's a silly change, but I'm tracking code related to these issues, so I walk on the line these times. For a Quick&Dirty fix, you can edit GameData/TMasterson5TweakscalePatches/GroundedTweakscale/weakscaleConfigPatch.cfg and bluntly delete the patches for wheelReg, wheelReg2 and wheelReg3 . In the current state, these parts are inducing TweakScale to a NRE if you try to use them. Thanks for the ConfigCache. It helped me to confirm my suspects (you know, I'm somewhat prone to misread logs today ).