Lisias

You misdiagnosed the problem! There're a bug on KSP where reaction wheels and RCS thrusters ends up fighting each other, gradually increasing the torque forces due resonance (hey, KSP¹ apparently simulates resonance! cool!!) and, as such forces increases over time, they fatally reaches some part's breaking point. I have a link to a Reddit post somewhere here where an user not only explains how to deterministically reproduce this problem, but also provides a viable workaround! As soon as I find it, I will edit this post with it. The guy deserves the credit.

ANNOUNCE Release 2.4.7.4 is available for downloading, with the following changes: A serious regression was detected on 2.4.7.3. The code intended to fix Issue 307 triggered Yet Another Bug on Editor™, and had to be removed. This, unfortunately, resurrects #307. Closes Issues: #314 The Editor is screwing with me again when scaling Parts with PartModuleVariant ReOpen Issues: #307 Attachment Points are not being scaled (or being reset) after changing the Variant A SERIOUS REGRESSION were (finally) diagnosed. The fix for the Issue 307 ended up triggering a new bug on Editor (or an old bug in disguise), what lead into the problem reported on Issue 314. Exactly "how" this happens is (hopefully) diagnosed, "why" I will never know and "when" is currently work in progress - the aim for the next TweakScale release is to close again #307, but without screwing anything else this time. Until there, please select your Variant before scaling the part, what's exactly what you had to do before 2.4.7.3 anyway. I'm not happy with the time I took to finally understand the problem, but I least I could issue a fix in less than 2 hours after detecting it. My apologies for the borkage on the wild - but Real Life™ and Day Job© sometimes conspires together to screw my life, and the last 8 weeks were being royally screwed - and the few days I got to rest I, well, rested. @AnFa, I'm afraid I didn't managed to diagnose correctly your report, my apologies - but as a matter of fact, I think you were bitten by BOTH problems are the same time (mine and ReRoot). In a way or another, if you are still using TweakScale, please check this fix, thank you. Know Issues Attachment nodes are being reset when changing Variant on a scaled part. Please change the Variant before scaling the part as a temporary workaround. See issues #307 and #314 for the gory details. There's a long standing issue on TweakScale about scaling ModuleEnginesFX's plumes - some engines' plumes is just not scaled, while others scaled pretty badly. It's something that never worked right on TweakScale, and it will only be really fixed on TweakScale 2.5 (when this thing goes gold) The best workaround (and also the reason I'm dragging my feet on this) is to use SmokeScreen or Waterfall. For SmokeScreen, you need: SmokeScreen itself. Real Plumes (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on Real Plumes. For Waterfall, you need: Waterfall itself. StockWaterfallEffects (to enable SmokeScreen on Stock parts) Additional Part Sets and Add'Ons may need specialised support not included on StockWaterfallEffects. See Issue #27 Disclaimer By last, but not the least... And since we are here, a very important disclaimer and serious warning: please, pretty please don't give attention to character assassinations attempts against my add'ons. I'm perfectly aware that they are not perfect, but under no circumstances they are malicious. There's absolutely NO CHANCE any of my code would do shady things on you, neither try to force you to do something by your back. I may bork trying to do the right thing, but it's all. In special, this crap: is, well… CRAP!! That "shady ass version of a Module Manager tampering library" is a tool to PROTECT YOU from fatal mishaps on installations: You forgot to install Module Manager, or by some reason it isn't operational? It will bark on you. You installed an older version of MM by accident, what fools KSP on using the older version? It will try to fix it, and then will bark on you so you restart KSP and use the right one. You installed a different version of MM by accident? It will remove the alien one (no matter what it is) so the MM you want to use will be safeguarded against replacement. You screwed something while trying to get rid of PD Launcher? It will bark on you, warning that things are not going to work 100% fine, no matter what anyone else tells you the KSP.log ending up on the wrong place is already a sign that you should not do it this way!!! You forgot to install a dependency that makes TweakScale to bork? It will bark on you and prevent you from loading the game, what would destroy your savegames!! You forgot to install a dependency that makes KSPIE bork? Same thing! You have any Add'On that screws up the savegames if incorrectly installed? Talk to me and I will implement a WatchDog for it. And since Module Manager (forum) itself is being prevented somehow to yell when Reflection Exceptions are detected while loading DLLs nowadays (see Issue 312), Module Manager WatchDog is, now, the only defense you have against such borkages! And even this "shady" feature can be easily disabled when using CKAN or any other PackageManager that handles itself the problem, as we can see on this link. I never pushed my weight on users, and this will not change. I have my share of problems to fix, I'm not denying it and I'm bashing my cheeks to have them sorted out. No one needs half baked, unfunded and easily refutable (the freaking thing is OPEN SOURCE, damnit - anyone can read the code and check themself!!!) accusations to be added to my already significant workload - unfortunately, this means that I will need to defend myself from such crapness as I'm doing now. This is not even about my reputation anymore (I don't need help to screw it up myself!! ), we are talking about people intentionally putting users at risk. I will not even try to speculate about the reasons. (sigh). Vida que segue. 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. Right Now.

METAR A serious regression was detected on TweakScale 2.4.7.3. See Issue 314 for the gory details. TL;DR: When I fixed Issue 307, I inadvertently triggered yet another bug on Editor™ . Why it's a bug on Editor? Because if it would be something I'm doing wrong, I would be screwing crafts when they are loaded on the Flight Scene (i.e., by loading a SaveGame, or by launching crafts directly into the Launch Pad or Runway), since the code is essentially the same. Being a Editor bug or not, the fact is that KSP is not going to be fixed, so I need to cope with the problem somehow. Currently Work In Progress. In the mean time, I strongly suggest to revert back to 2.4.7.2 . You will be hit by Issue 307 again, but it's a lesser of a problem than what we have now.

A real life case of Strut abuse! Boeing SRB-X. As a bonus, also a case of SRB only launch vehicle ! (Life imitates Art Kerbal)

Oh, well… Just to inform you: I reproduced the problem easily on a (almost) Stock KSP 1.12.5. https://github.com/TweakScale/TweakScale/issues/314 Problem: this thing was working, I'm absolutely sure about. I didn't released anything since the borkage started to happen, and no new KSP release were issued neither. The thing just started to happen, out of the blue. Why? Good question. In a way or another, I will see what I can do about. One possible way to mitigate one aspect of the problem is selecting the Variant of the part before scaling it. I only checked for this problem on Editor, however. I still need to check how this thing is behaving with flying crafts. --- POST EDIT --- Flight scene appears be all right. All the crafts I cheated into space, with parts scaled, behave as expected, including docking and undocking. More tests as needed to be sure, but apparently the problem is confined to the Editor. I will update this as new information is gathered.

Just to clarify, the TSCo-AirCrafts is capable to remove that patches and inject its own in their place. Your previous installation didn't worked as intended because the rogue copy of the NAP patches ended up being applied before the TSCo correctly installed (but older and borked) ones, and when the later was applied, it replaced the good patches with its borked ones My initial confusion was due the "Cannot create config from file" messages related to all that TSCo patches. I spent a good amount of time early this year fixing them, but I got a serious issue on Day Job© in the mean time and ended up forgetting to… publish them! So I got myself in a self confirmation bias thinking that messages were due the files themselves being zero sized instead (what's exactly what happens when CKAN used to bork when installing things on a full disk). Way later that little voice inside my head (the other two are on PSL ) started to pesky me about I missing something and so I double checked, and realised that I didn't published that fixes yet, and so your problem should be something else. Cheers!

If you are planning long term missions, real time months duration, the a KSP 1.7.3 with all the bells and whistles are your best bet. Anything after that, from KSP 1.8.0 to the latest, have a really nasty bug on the ReRoot feature that tends to destroy your craft in memory permanently - and since your craft is rerooted when you dock, any serious gaming is doomed. Since you have a beefy machine, you will not miss the performance enhancements on Unity 2019. But no Parallax for you so. If all you want is casual gaming, the 1.12.5 will suit you fine. There are OPT versions for all that KSP versions, and IIRC they were pretty stable on the KSP 1.7.3 era.

I'm telling this for years: KSP¹ is how really technology works! Engineering have a loooong history of weirdities until we finally had settled with the designs we currently consider "successful". But things are changing again, we are flirting experimenting with "new" designs again! https://en.wikipedia.org/wiki/Boeing_X-48

— — POST EDIT — — I'm reexamining the issue, and realised that some patches from the TwealkScale Companion are, indeed, "empty". I sincerely thought I had already published the new versions, but as we can see, I didn't. The patches I found causing this false alarms were removed from the previous listing above and moved here for reference: — — POST POST EDIT — — @Falcon Aerospace, I misdiagnosed your problem. CKAN is innocent on this one. One of the problems you have is that the TweakScale Companion for AirCrafts is installed on the wrong directly! [LOG 17:53:10.880] Applying update AirCrafts/NAP/patches/NeistAir-Structural_TweakScale/@PART[CF34-8-TopMountPylon]:NEEDS[NeistAir,TweakScale]:FOR[TweakScaleCompanion_AirCrafts_NAP] to NeistAir/Parts/Engine/CF34-8/CF34-8-TopMountPylon.cfg/PART[CF34-8-TopMountPylon] The TSCo-AirCrafts must be installed inside the TweakScaleCompanion directory - interesting enough, you have it in the right place too: [LOG 17:53:24.120] Applying update TweakScaleCompanion/AirCrafts/NAP/patches/000_CleanUp/@PART[12NCS,14MST,18-06CurvyTail,18AN-24,18CB,18CBjr,18CD,18CF6,18CF6-TopMountPylon,18ConformalTank1]:BEFORE[TweakScaleCompanion_NAP] to NeistAir/Parts/Aero/12NCS/12NCS.cfg/PART[12NCS] Completely remove the directory D:\Kerbal Space Program\GameData\AirCrafts and run KSP again. Then send me new KSP.log, MMPatch.log and ModuleManager.ConfigCache (note that I need the ConfigCache file in the GameData!) if the NeistAir Parts are still non scalable! — — POST POST POST EDIT — — I fired up a 1.12.5 test bed with NeistAir and the whole TweakScaleCompanion thingy (and TweakScale, of course). Indeed, there're a lot of valid "Cannot create config from file" messages (i.e., I didn't fixed all of that as I was thinking), but other than being extremely annoying (not to mention making a fool of me), they are harmless. But since the current TweakScale Companion UberPacket wasn't updated yet with the NeistAir fixed patches, obvioulsy the NAP parts are not scaled. You need to download and install the latest revision for AirCrafts that you will find here: https://github.com/TweakScale/Companion_AirCrafts/releases But you need to install it properly. Copy the whole TweakScaleCompanion directory on the zip on your GameData, including the TweakScaleCompanion directory itself. Or copy the contents of the zip's TweakScaleCompanion directory into your GameData/TweakScaleCompanion . The result will be the same. Overwrite any previously existing files. I will update the UberPacket ASAP - pending Real Life™ and Day Job© agreement…

Half baked abreviation for TweakScale Companion for AirCrafts! I need authorisation to download them. As soon as you authorise me, I will check them! Cheers!

I'm unsure what to recommend, because I don't know what you intend to do and how powerful (or potatoish) is your rig. I play KSP mainly between day job tasks or between working times, when it would not worth start a new task after being blocked on another one because it would not be finished before the road is unblocked, and so I play KSP on a Potato secondary machine I have on my desk (MacMini 6.2, to be precise). I came to terms that I need to settle on KSP 1.4.3 to have good playability on it because the potato uses a Intel HD4000. If you have something more powerful (pretty easy to tell the true! :P), I recommend KSP 1.7.3. From the KSP versions, 1.7.3 have the better feature/bug ratio of all of them. You will be happy with any CPU with 4 cores, 8GB (16GB is better if you want some visual mods) and a GPU with at least 4GB VRAM. If you want the most bugless KSP ever, you will need to settle with 1.3.1 or 1.2.2. KSP 1.8.0 and newer are good for small play sessions and for making videos - any long term playing is fated to be doomed due some horrible bugs on key features of the KSP engine.

Bleeding for 20 minutes means a somewhat significant artery rupture. It's almost sure due dry weather, but usually the smaller arteries blow up. In 9.999 between 10.000 cases, it's really only that - ruptured vessels due dryness, but I got "lucky" enough to be one of that remaining one cases - so I got in trouble. Consider talking to your doctor and check for any anatomic anomalies in your nasal cavities and perhaps cavum. There's that pesky cysts that enjoy embracing arteries, weakening them, and you want to know about them the sooner you can if you are so "lucky" as I was!

Problem is… This thing are happening in the wild, and I'm taking the heat. If we could diagnose your rig, I will help to prevent further damaging in the field. What I managed to gather until this moment is that apparently the ReRoot problem plaguing the Editor since KSP 1.8.0 is also affecting living crafts - when you dock, your craft is ReRooted, and consequently screwed. Merging SubAssemblies (or crafts) appears to be affected too - you merge a subassembly and your craft's nodes get screwed… And with the craft's nodes completely screwed, when the craft goes to rails and then back, TweakScale will be called to rebuilt the nodes and… Garbage In, Garbage Out: with screwed nodes, you will get scaled screwed nodes. TweakScale really scales everything, including borkages. You will find further information on the following links: https://github.com/KSPModdingLibs/KSPCommunityFixes/pull/142 Interesting enough, apparently you are being plagued by a lesser form of the problem, what's by itself something to be analysed. In a way or another, if you change your mind I'll be around! Cheers!

Crap, I let this pass trough. Sorry. I tried to download the new log, but mega.nz is not working for me today - it's not the link the problem, the whole mega.nz is not responding here. You probably solved the problem by yourself by this time - but it this is still an issue for you, post a new KSP.log using something else but not mega.nz, and I will inspect it. Cheers.

I have this feeling that Unity Technologies didn't finished with the layoffs yet... The ad boycotting is royally screwing them, with a incoming decrease risking getting even bigger than the increase they expected to get with the install fee stunt. https://mobilegamer.biz/the-unity-boycott-worked-its-ad-network-and-ua-business-have-both-taken-a-hit/ This is getting interesting...

Humm… I double checked the thing, fired up my KSP 1.12.5 test bed with only NeistAir, TweakScale (and dependencies) and the TSCO-AirCraft downloaded from the github (to be extra sure), and the thing worked. So, now, it must be something on your rig. Send me your KSP.log, MMPatch.log and the ModuleManager.ConfigCache so I can dig them looking for whatever gone South on your rig.

Hi! You have a case of missing dependency. Please remove the file <KSP_ROOT>/GameData/ScrapYard/Plugins/ScrapYard_ContractConfigurator , or install Contract Configurator (and its dependencies, if any) and you will be good. Additionally, please file a report on CKAN about it. Their metadata files needs to be updated, this file should be installed only when Contract Configurator is installed! Cheers!

“Merciful Kraken, I have squandered my savegames with plans of many things. This was not among them. But at this installation, I beg only to play the next few games well. For all we ought to have launched, and have not launched; all we ought to have rescued, and have not rescued; all we ought to have clicked, and have not clicked; I pray thee Kerman for forgiveness.”

With so many workforce being fired, I think the best time to get funded and hire experienced people to work on the project is now!

Yep! Some few of us ends up understanding machine code directly - but I'm not absolutely sure we can call them "humans" , so yeah, it's exactly it! It's one of the reasons, for sure. There're different ways of releasing the source, with different outcomes. I will summarise the most relevant ones (being plausible or not) to help you on understanding the matter: The Source could be released on Public Domain, so anyone can do whatever they want with it. Yeah. Right. Dream on! Unless they are completely out of hope of keeping the franchise alive, they will not do it. I won't neither, and I AM an Open Source evangelist. The Source could be released on a MIT/Expat License style: Almost the same thing as Public Domain, but at least anyone using the Source Code will be obliged to mention you on the copyrights and documentation. Again, I won't do it neither. There's no gain on it while there's hope of making money on the franchise. The Source could be released under a GPL or similar Free (as in speech) license Things here start to be feasible. GPL style license don't forbid you from rereleasing something using the Source, but demands that any modification you do on the Source must be distributed under GPL (or whatever is the license you chose) too, and so any enhancement will be available to you too! Same for bug fixes. I would be allowed to legally download the Source code, apply my changes, publish a binary only package to whoever would be nuts enough to use their time testing my gadgets that so would help me to check if I did things right - as well anyone else here (many will fail, but we need only one succeeding to have the problem solved) I scratch your itch, you scratch my itch, and both of us profit from the ordeal. But, besides all the other assets not being part of the deal, the Source - in theory - can be used on a competitor trying to cut their teeth on the same niche, and having access to the Source is a barrier less to do such. So, in the end, it's up to them to decided if they think what's worth more for them: to gather open source resources around them (what's, being sincere, it's a problem by itself) but allow a few opportunists to try their teeth on their niche, of if it's better to alienate such workforce but keep a small edge over the competition (that can still invest their own resources on it, if they find profitable, and compete the same - [edit: and assuming they aren't doing it already by using shady practices]). Only them can answer this one - we don't have enough information to even suggest something. The Source can be made available on a restricted license, that allows me us to merely read the code and compile it on my our rigs, so I we can debug it. But nothing else. It's a compromise on doing nothing and going Open Source. Ok, I will not have any incentive to fix the thing myself and push the fixes to be used by them, but I at least I can check exactly how and where things are happening under the bonnet and, so can do something on my add'ons to prevent triggering problems and/or work around them (as I already do on KSP-Recall). THIS is the option that fits perfectly what you said. In a way or another, such Source code is their property - more or less as you computer, home or car. It's up to them to decide what to do, our role on this thread is to offer them options, in the hopes we manage to reach a win-win situation for all parts involved: Users want to play the damned game without being peskyed by bugs, crashes and nuisances. Plain impossible on Stock, and it's becoming extremely hard with mods Authors will be able to really understand what's happening inside the damned thing, and finally we will be able to locate the real source of the problems instead of finger pointing each other, trying to save face (or something worse). They will have a better chance to keep selling KSP¹, helping on keep things funded so they stay afloat. If they go OSI, it's plausible (depending on how dextrous they are on gathering people on their cause) to even expand the user base by supporting new devices currently beyound their reach, as porting things around is where OSI is really good. Not an easy feat, but plausible. It's exactly how we have WINE and Proton nowadays. Ideally. Perl, for example, doesn't exactly copes with your statement!!!!! (yeah, I'm maintaining some Perl code these days - the problem is that the damned thing is still be the best tool for the task, so… )

Symmetry is pretty screwed up on a lot of parts, this is another task force I need to cope soon. I plan to work on it at the same time I work on the wheels, as they are pretty affected by this symmetry mishaps. HOWEVER, on my rig the symmetry for the A+ parts I'm seeing on your pic: are working fine. This is my take: See? The symmetry is working perfectly on my rig. So it's something on the floaters you are using (SXT?), or perhaps something on a previous A+ version? I just released a RC above with some fixes I'm doing over the year, perhaps this new release would better suit you? EDIT: The user is right! @Kerbal410, I confirm your report. The Landing Skid have its colliders messed up. https://github.com/net-lisias-ksp/AirplanePlus/issues/14 /EDIT I think you reverted A+ to a previous version? My release above have the Category working fine. I really don't remember if the upstream's had a problem on it (or if it had a Category at all), so I'm guessing. But in a way or another, I have a category for A+ here on my test bed right now, using my latest release.

Announce! TweakScale Companion for AirCrafts 0.2.0.0 RC is on the wild. Rebranding the whole thing to TweakScale Companion for AirCrafts Reworking APP patches Importing (and reworking) patches from the late Companion for NeistAir New patches for: MPR SXT Download here or in the OP. The previously known TweakScale Companion for AirplanePlus was deprecated, and incorporated in the new TSCO for AirCrafts. The previously known TweakScale Companion for NeistAir was deprecated, and new (fixed and improved) patches were incorporated on AirCrafts too. Support for MPR (Moderately Plane Related) were added. Revised and improved patched for SXT were incorporated, as TweakScale 2.5 will (hopefully) be published sometime in the near future and there's a chance that it will break really old patches (currently on the SXT's main distribution) - so having them on this Companion will guarantee a seamless migration. I will keep this thing as PRE RELEASE for a week, to prevent causing borkage on the wild in the case I let something silly pass trough unchecked. Early adopters are welcome to trial it. Cheers! — — NOTAM — — I screwed up something on the new SXT patches, perhaps they are not finished yet - its' some time since I worked on it and I'm jumping tasks since them. In a way or another I removed them from this release while I (re)work them.

Hi! Your rig is pretty damanged... For starterts, you have two TweakScaleCompanions installed on the rig - and there can be only one. KSPIE is ano badly installed: KSPIE+1.29.6+for+KSP+1.8.1 <...> Stock folder: Squad <...> TweakScale TweakScaleCompanion TweakScaleCompanion 4.48.45 pm Completely remove <KSP_ROOT>GameData/TweakScaleCompanion 4.48.45 pm . Additionaly, rename KSPIE+1.29.6+for+KSP+1.8.1 to KSPIE. Besides this, I think you have a problem with ExsurgentEngineering (and I don't have the slightest idea about what it is): [ERR 17:07:29.850] AssemblyLoader: Exception loading 'ExsurgentEngineering': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <106570632fc343a784fad39e75e877bf>:0 Additional information about this exception: System.TypeLoadException: Could not resolve type with token 0100002b (from typeref, class/assembly SolidRocket, Assembly-CSharp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null) Reach ExsurgentEngineering maintainers for help, this is also screwing a lot of other addons, as HangerExtenderExtended , KineTechAnimationModuleLoader , MechJeb2 and all the TweakScaleCompanions due the Assembly Loader/Resolver problem on KSP: [LOG 17:07:30.683] [ModuleManager] Intercepted a ReflectionTypeLoadException. List of broken DLLs: ExsurgentEngineering 1.0.5122.3109 GameData/ExsurgentEngineering/Plugins/ExsurgentEngineering.dll

Did you installed everything correctly? Things worked fine on my test bed. Send me your KSP.log, MMPatch.log and the ModuleManager.ConfigCache, You will find the instructions on the TweakScale's OP, on the section Support:. I should be able to diagnose the problem with these artefacts. Don't bother, found the cause. A typo in the configs. It was working on my rig because I managed to install NeistAir with the Kraken damned typo!!!! #facepalm Create a directory named "NestAir" on your GameData for while, I'm fixing the distribution and I will publish the fix in the next hours. Sorry! — — POST POST EDIT — — Worst!! I have it fixed already early this year!!!! #facepalm² I completely forgot to publish it!! Damn! (it wasn't even installed on my Acceptance Test Bed, I really forgot about it! damn!!!) Ignore my last advice, install this thing and you will be fine: https://github.com/TweakScale/Companion_AirCrafts/releases — — POST POST POST EDIT — —

I just learnt something that made the photosynthesis in Kerbals something more… 'realistic' on my eyes: kleptoplasty! They can still be animals (molluscs with an exoskeleton, as I imagine them), and by eating Chlorophyll rich food, their cells hijacks the Chlorophyll and start to process light and carbon dioxide to get energy and oxygen to be consumed, restarting the cycle. This can be a good excuse for their incredible ability to survive on space for years without a proper (for human standards) source of oxygen - as long they have enough snacks (hey, this is science fiction, and we just realised why they need so much snacks! They are made of Chlorophyll rich vegetables, as algae, as well something to provide them the remaining nutrients, as vitamins and proteins!). As long there's light (natural or artificial), and a good source of snacks, they can convert the CO2 they produce themselves into oxygen and energy. And by still being animals, they can move freely on the dark as long they have stored energy in their bodies ("fat") to burn for while. This theory needs some polishing, but I like the overall idea!