Lisias

This didn't worked as I expected….

The root part is the very first part on the craft. Crafts on KSP are "Trees" (a programming data structure), it looks lke this when drawn: The top node (1) is the root. The bottom ones (8, 9, 10, 11, 13 and 14) are "leafs". This is a binary tree, because each node can have only 0, 1 or 2 "sons". KSP use n-nary trees, i.e., has no limits about the quantity of "sons" a node can have. Being a tree, a "son" can have only one "father", and you can't have circular references - i.e., a node cannot reference a brother, a cousin, or any ancestral. You can't link 14 to 3 neither 4, for example. EAS Struts is a way to overcome this limitation. On a craft file, the ROOT is the part that has no parents, but has "sons". I suggest to edit the craft on VAB/SPH, and then cheat it into the space for testing, instead of trying to hot edit a living vessel. Using the reroot tool is way more convenient. As I said before, I only successfully rearranged small crafts (about 5 to 7 parts), bigger than that it's just too much hassle to do manually. At least on the craft files I edited (it's some KSP versions since the last one), its the first PART on the craft file. Each "father" has 0, 1 or more "link =" data, linking to a son - so a root part is a part where nobody has a "link =" to. You can edit the tree by editing that "link =" thingy. But yet, the reroot tool is the bast way to do that. I explained all of that to you so you can understand what the tool does. So the weight of their "sons" is too much for them. You need to auto strut some of its sons to root too, so they can share the load. Using auto-strut on everything can bite because auto-struts adds more load on the physics engine, and when you overload it the wobble happens, because KSP tries to cut some corners to save framerate and then suddenly the physics engine got flooded by "over-shoots", and eventually one of that overshoots ends up being bigger than the joints can withhold.

I remember it as it was 30 years ago.

Hi. That stunt of mine did the trick for you?

THIS is what it should be about!

The experiences the channels I watch says exactly the opposite. Great. Another A.I. believer. Still on this line of argument? Dude, do you know that making assertion that could be easily denied by a simple Google Search doesn't make your opinions exactly valuable, right? Google had obliged themselves to pay for content once the youtuber applies for Revenue and it's Accepted. It's a commercial relationship. I strongly suggest you to better inform yourself, please. How about this one on UK? https://www.copyrightuser.org/understand/exceptions/parody-pastiche/ USA has the Fair Use, and even Brazil (with a somewhat draconian copyright law that tries to make amends to a terrible past fro the 70's and 80's) has something like that. If you are on EU, you may want to read this: https://www.copyrightuser.org/understand/exceptions/ for a full essay.

Got it. [LOG 17:50:01.838] [TweakScale] INFO: WriteDryCost: Started [LOG 17:51:16.772] [TweakScale] INFO: WriteDryCost Concluded : 1528 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 1 Show Stoppers found; 9 Sanity Check failed; 855 unscalable parts. No big deal, just one FATALity: [LOG 17:51:16.461] [TweakScale] ERROR: **FATAL** Part pp.vvmach (Plume Party Vapor Vent Mach) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). But this is a new one! Let's improve our TweakScale knowledge base a bit! [LOG 17:40:24.198] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:24.201] Applying update PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:28.101] Applying update Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:28.102] Applying update Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:28.103] Applying update Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:28.104] Applying update Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent/@PART[pp_vvmach]:NEEDS[TweakScale] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:51.786] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:51.786] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:51.793] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:40:51.793] Applying update kOS/kOS-module-manager/@PART[*]:FOR[kOS] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:41:03.758] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:41:03.758] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:41:03.767] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:41:03.767] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:41:04.615] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:41:04.617] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:41:04.662] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] [LOG 17:41:04.663] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to Shuttle Orbiter Construction Kit/PlumeParty/Vapor/vent.cfg/PART[pp_vvmach] Well.. This is a new. There're many patches being applied to pp_vvmach, every one of them twice! This is a new one, indeed! Looking into the KSP.log, I realized that there are more than one copy of PlumeParty on your installment! [LOG 17:40:14.583] KSP-AVC -> D:\Steam Games\steamapps\common\Kerbal Space Program\GameData\PlumeParty\Version\PlumeParty.version [LOG 17:40:14.583] KSP-AVC -> D:\Steam Games\steamapps\common\Kerbal Space Program\GameData\Shuttle Orbiter Construction Kit\PlumeParty\Version\PlumeParty.version I'm pretty sure you copied the Folder on Shuttle Orbiter Construction by accident. Delete it, it will no only fix your issue but probably prevent some others that TweakScale doesn't knows about! Cheers! "install safe!"

I used to use KOS. KOS allows you to name the part (I think this can be done on recent KSP?). This makes things slightly less harsh. Once I find the craft and the part I want, I keep track of the indentation. "Professinal grade" Text Editors as Notepad++ allows you to open more than one window with the same file, so you can have multiple "visions" of the same file. This also helps a lot. It's not exactly hard - the problem is that is way to easy to make mistakes.

Ugh…. I was in "Developer Mode". Finding the heaviest part on a craft is somewhat simple with the right tools (I just use Notepad++, seatch for all "mass = " and then pick the biggest number on the list). Sorry. I'm on Mac, so I will show you a TextWrangler screenshot - but other than the looks, Notepad++ works the same. Changing the autostrut is just editing that "autostrutMode" thingy. Problem: you make a mistake, a simple typo, and you screw up the savegame. Use SAVE if you are willing to try this such a stunt. Every time you dock and undock a craft, you change the root part of the thing. There can be only one (#highlanderFeelings). When you undock, the root of the undocking craft is recalculated/restored (never bothered to check…. something to be done). However, doing it manually is a pain in the SAS, no doubt. I only managed to do that on small crafts, and I made a lot of mistakes until making it right. I did the stunt just by the challenge, there're easier ways to accomplish that (see below). The few stations I made were not that big, and I didn't welded them, I used the big docking ports and then autostrut them to root - at least for my stations, autostruting the key docking ports to root did the trick. But I had choose the root do be equidistant of them... I think it's easier to spawn a new, fixed station in the place of the current one, and then edit the savefile to move the crew from the old to the new, and then just delete the old station from the savefile. This will mangle the saveMD5 on the loadmeta file, however - since I don't care too much for career, I just don't care about, but that saveMD5 is there for a reason (for trophies, perhaps?). Oh, yeah. Use SAVE.

Find that heaviest part, made it root, and the auto strut to root. It's what I do on mine monster crafts. Sometimes, I wish I could select a "corner part" (as in cornerstone) to use auto struts. Root parts change on docking, and heaviest parts on fuel consumption. Both triggers the Wobble of Doom.

Me too. The problem is about copyright abuse. Sooner or later some stand-up guy will claim a copyright on the Pentatonic Scale. The small phrase from the music used by Matt is not too far from it (and, look, the music was not stroke by a claim). You can check by yourself, this is the music that they say their IP was infringed. Source: This is not only about YouTube revenue. It's about the plain right of making your own music and distributing it the way you want.

On the grounds they are causing prejudice to the Society. You know, we vote on these idiots. I think Ukrania has something to teach to the rest of the World.

The real problem is not the companies, but the laws. Companies have to follow the Law too, and that trolls are - essentially - exploiting bad Laws to earn some coins, disregarding the destruction being made (what would render everybody without coins later). We need to tackle the cause of the problem - bad legislators. Who made this law? Who approved it? Why we are not persecuting these idiots? As a follow up of your idea - multiple audio streams for the Video would be marvelous. Deleting or replacing the music channel is way easier than brute forcing your way on a single stream of audio (what always leaves artifacts, and I didn't touched the problem of decompressing the signal, processing it and then recompressing it - we are talking about lossy compression here).

So totally unrelated about what I said. I think you may had hit a bug. I have an interesting behaviour on my aircrafts - I make heavy use of flaps and slats for landing and taking-off, and I found that sometimes the surface controls get inverted when I deploy them. I go back to Editor, change the deployment, fire them, they works. But now and them, they are spawned inverted again. Try this test: launch the Vessel, check the drag. If its there, "Revert to Launch" and try again. See if the thing "fixes" by itself. Then revert again to see if you get it "broken" again, or if the thing from this point is right and stays right. Perhaps Reverto to Editor should do the trick, something to be tried. If you manage to reproduce the issue with that steps, this worths a entry on the bug track.

Yep! That should be the ideal solution. But not all Add'On authors would want to keep TweakScale patches themselves. So an alternative solution is an Add'On those solely function is to add TS patches to Tantares. With the patches stable later, Tantares' maintainer can decide to adopt them as default on the Distribution. Making History patches for TweakScale apparently was born this way, and later incorporated into TweakScale. It's not a bad idea, not at all. We just need to do better job on synchronising efforts on the merge, so we don't stomp on each other toes later. On the MH patches, instead of deleting the source Add'On, I would issue a new release, empty, with the newest TweakScale version (with the patches) as hard dependency. This would make the transition smoother for CKAN users.

In which KSP version? A screenshot can be useful. Last time I got hit by this, it was on 1.4.x and the problem was that the part must fit inside the part's colliders in order to get shielded by it. I was being bitten by it because I was trying to ferry a whole booster inside a long chain of cargo bays and, obviously, the thing had spread to more than one cargo bay - making impossible to be shielded at all. I recently heard that on 1.8.x they changed the rules (not confirmed it my self). Apparently, you need to keep all the connected bay doors closed to keep things inside shielded from drag. One single door not properly shut, and everything gets drag.

Too primitive. Patrick Volkerding made an excellent work after forking it into Slackware.

S.A.V.E.

Or perhaps no one forwarded you the memo. People can be mean to people that annoys them. As weird as it appears, this flame-fest was useful. Lots and lots of relevant information above - including about people and thoughs about other people. I agree that all that information could be spread less painfully, however. When you have is a 1500kN press instead of teeth, and all you know is to push buttons, it can be the only option available. I think it's time to resurrect blogs and feeds aggregators. There was a time in which we didn't have to submit ourselves to a demi-god in order to get the information we wanted. We knew how to seek the info by ourselves, and some nice guys cooked a way to make things easier - the RSS feeds. You sign up on the RSS feeds you like (a "channel"), and then you gets informed about the new content, no matter where they are published - that nice guys working with RSS made the grunt work for you. — — — POST EDIT — — — A youtuber friend on mine, on USA, just got hit too. Weirdly enough, this is "good news". The wider the problem, the faster the response. This mess is going to be sorted out relatively quickly. This guy just told me about a new feature from Youtube that removes the music from the audio stream, leaving the voices.

Almost sure some lost patch forgotten on a subdir. Sometimes, new versions of Add'Ons change the name and/or the place of a patch in order to easy the maintenance efforts (I did it on TweakScale recently), and so by downgrading without removing all the old (or new) contents, you end up with two copies of the patches (the old and the new), both playing havoc with each other. Following the hint from @Aelfhe1m, I will post too the UNIX command lines I use to munch the KSP.log - it's interesting to say the least! cat KSP.log | grep "WriteDryCost" [LOG 01:51:18.046] [TweakScale] INFO: WriteDryCost: Started [LOG 01:51:18.877] [TweakScale] INFO: WriteDryCost Concluded : 2160 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 6 Show Stoppers found; 75 Sanity Check failed; 733 unscalable parts. Well, we have only 6 FATALities here, so I can tell you in advance that TweakScale is not the Add'On involved on the downgrade problem. A huge amount of parts get FATALities when this happens. cat KSP.log | grep "ERROR: \*\*FATAL" [LOG 01:51:18.809] [TweakScale] ERROR: **FATAL** Part SXTInlineAirIntake (XM-600 1.25m Air Intake) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 01:51:18.809] [TweakScale] ERROR: **FATAL** Part SXTWingSmall (Mk0B Small Modular Wing) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 01:51:18.809] [TweakScale] ERROR: **FATAL** Part SXTWingLarge (FAT-460 Super-Lift Aeroplane Main Wing) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 01:51:18.815] [TweakScale] ERROR: **FATAL** Part SXTOsaulNoseCockpitAn225 (Kn-225 "Osaul Payload" Cockpit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 01:51:18.815] [TweakScale] ERROR: **FATAL** Part SXTOsualRadCockpit (Mk.P-Yavka Radial Cockpit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 01:51:18.830] [TweakScale] ERROR: **FATAL** Part SXTtruckbox (Truck Box) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). All the six are from SXT, so they all probably shares the same root problem. It's a good news, because probably you have only one patch misbehaving on the whole system. When parts from multiple Add'Ons start to get problems, things are a bit more hairy to diagnose. The next step is to check every patch being applied to the affected parts. Let's follow my hunch about all the parts sharing the same misbehaviour and check only SXTInlineAirIntake : cat KSP.log | grep "Applying update" | grep "SXTInlineAirIntake" [LOG 01:42:00.830] Applying update BDArmory/MMPatches/000000_HitpointModule/@PART[*] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:00.831] Applying update BDArmory/MMPatches/000000_HitpointModule/@PART[*] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:42:11.174] Applying update SpaceTuxIndustries/RecycledParts/AtomicAge/IntakeAtm/@PART[*]:HAS[@MODULE[ModuleResourceIntake],@RESOURCE[IntakeAir],!RESOURCE[IntakeAtm]]:NEEDS[!WarpPlugin|!GTI] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:11.174] Applying update SpaceTuxIndustries/RecycledParts/AtomicAge/IntakeAtm/@PART[*]:HAS[@MODULE[ModuleResourceIntake],@RESOURCE[IntakeAir],!RESOURCE[IntakeAtm]]:NEEDS[!WarpPlugin|!GTI] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:42:12.928] Applying update SXT/Patches/ModCompatibility/SXT_TweakScale/@PART[SXTInlineAirIntake]:NEEDS[TweakScale] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:12.958] Applying update SXT/Patches/ModCompatibility/SXT_TweakScale/@PART[SXTInlineAirIntakeTLarge]:NEEDS[TweakScale] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:42:14.546] Applying update SXT/Patches/ModCompatibility/SXT_TweakScale/@PART[SXTInlineAirIntake]:NEEDS[TweakScale] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:15.200] Applying update SXT/Patches/ModCompatibility/CCT/SXT-CCT/@PART[SXTInlineAirIntake]:NEEDS[CommunityTechTree] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:15.232] Applying update SXT/Patches/ModCompatibility/CCT/SXT-CCT/@PART[SXTInlineAirIntakeTLarge]:NEEDS[CommunityTechTree] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:42:44.138] Applying update FerramAerospaceResearch/FerramAerospaceResearch/@PART[*]:HAS[@MODULE[ModuleResourceIntake]]:FOR[FerramAerospaceResearch] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:44.138] Applying update FerramAerospaceResearch/FerramAerospaceResearch/@PART[*]:HAS[@MODULE[ModuleResourceIntake]]:FOR[FerramAerospaceResearch] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:42:44.277] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[LaunchClamp]]:FOR[FerramAerospaceResearch] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:44.277] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[LaunchClamp]]:FOR[FerramAerospaceResearch] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:42:46.492] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[FARWingAerodynamicModel],!MODULE[FARControllableSurface]]:AFTER[FerramAerospaceResearch] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:46.492] Applying update FerramAerospaceResearch/_FARPartModule/@PART[*]:HAS[!MODULE[FARWingAerodynamicModel],!MODULE[FARControllableSurface]]:AFTER[FerramAerospaceResearch] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:43:12.618] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[!MODULE[AtmosphericIntake],@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir]]]:FOR[WarpPlugin] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:43:12.618] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[!MODULE[AtmosphericIntake],@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir]]]:FOR[WarpPlugin] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:43:12.860] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#area]]:FOR[WarpPlugin] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:43:12.861] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#area]]:FOR[WarpPlugin] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:43:13.210] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#intakeTransformName]]:FOR[WarpPlugin] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:43:13.210] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#intakeTransformName]]:FOR[WarpPlugin] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:43:13.528] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#intakeSpeed]]:FOR[WarpPlugin] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:43:13.529] Applying update WarpPlugin/Patches/AtmosphericIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake]:HAS[#resourceName[IntakeAir],#intakeSpeed]]:FOR[WarpPlugin] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:43:37.287] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:43:37.287] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:43:38.809] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:43:38.810] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:43:40.236] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:43:40.237] Applying update Kopernicus/Config/SolarPanels/@PART:FINAL to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] [LOG 01:43:42.313] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:43:42.313] Applying update WarpPlugin/Patches/OreTanksFix/@PART[*]:FINAL to SXT/Parts/Aviation/Aero/airIntake/part4Large.cfg/PART[SXTInlineAirIntakeTLarge] Ugh… A huge lot of patches. Things can get messy, but let's keep cool and methodic on the subject. Let's see line be line. And yeah, we found the problem! [LOG 01:42:12.928] Applying update SXT/Patches/ModCompatibility/SXT_TweakScale/@PART[SXTInlineAirIntake]:NEEDS[TweakScale] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:14.546] Applying update SXT/Patches/ModCompatibility/SXT_TweakScale/@PART[SXTInlineAirIntake]:NEEDS[TweakScale] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] [LOG 01:42:15.200] Applying update SXT/Patches/ModCompatibility/CCT/SXT-CCT/@PART[SXTInlineAirIntake]:NEEDS[CommunityTechTree] to SXT/Parts/Aviation/Aero/airIntake/part2.cfg/PART[SXTInlineAirIntake] We have the same patch file being applied to the same part three times, what's unusual! (to say the least). And now, I just remembered (old fart. memory not serving me as it used to…), this is an already detected problem. Newer versions of SXT have it fixed already, but you surely had to install a version where the fix were not applied yet. (on a side note, I was wrong about the issue - I initially though about a double patching due renamed files - it's pretty usual, but as we saw, it's was not the only possible explanation). But back to business, yeah, it's a known issued already. So I used my own hint about (the Search) and looked by mentions of the SXTInlineAirIntake on this topic. Since this was already fixed on SXT, the newer entries would only state that the thing is already fixed on the upstream, so I gone for the older ones where SXT fixes where not applied yet. And bingo, found it here. However, I never issued a HotFix for SXT, as the SXT maintainer promptly updated his Add"On once I pushed a pull request with the fix. But now, we have a new problem to cope. I'm not sure if that file will work fine to SXT 0.3.27 , the one you installed. This version was issue on Apr 19, while the first SXT released with the fix is SXT 0.3.28.2, from Jun 17. And this one is for KSP 1.7.0. =/ So, and now we are going into uncharted waters, let's try a stunt. This will void your warranty for sure, but since you are on a (now) very old KSP version, chances are that you have none anyway . So I checked the Git History of that patch and learn that aside this fix of mine and another one from a previous change from the maintainer, this file is the same since 2017. But that previous change would break the TweakScale patch for MEMLanderSXT (this part would be not scalable). Well. you can't have the cake and eat it too. Let's try the easy way out first: Download this file. Click on "Raw" Move the downloaded file overwriting the old file on your KSP Installment If you can live without scaling the MEM Lander from SXT (are you aware that it conflicts with a DLC on the SXT version you are using, right?), I think this will solve your issue - besides creating an inconvenience at the same time. If it doesn't not solve your problem, and/or create a new one that you don't want to cope, kick me here again and I will cook a HotFix for you. I could not do it by know, as I'm working (yeah) and writing this post slowly from on the past two hours (while taking a break from the RL task) - no KSP on the new machine, so I cannot test things, so I will not dare to publish anything. I expect to have an easy day or two this week, so I can do a better job by then. Right now, this is the best (or less worst! :P ) I could do. Let me know one way or another! Cheers!

That's not an irony. It's the core of my argument. People enough decide not to agree to yet a new change in the ToS, they flee. And once they flee, any revenue they would get goes with them. As with any broadcast company, It's not a good idea to push the audience away. But yet, they need the money of the advertisers, so it's not a good idea to push them neither. Some kind of compromise must be reached. On this very subject, I think this compromise must be attempted by revising the Laws - at least on UK, as the last two strokes I'm aware hit British youtubers.[ No. A youtuber on USA, friend of mine, just got hit too].

That's the catch. It was someone else copyright infringement. Assuming Lowne (and a lot of more people more) is telling the true, the Copyright Infringement was committed by YouTube itself, by endorsing the use of the infringement as it was good to use. Of course, YouTube themselves are not exactly "guilty", as they accepted in good faith the claim of a thirty party about the material. However, there's a thing called Vicarious Liability - by accepting the claim end endorsing it, they are co-responsible by any damage caused by the false claim. On the other hand, on an alternative point of view, all this Copyright Infringement claim from Sony ATV is clearly abusive. I wonder how they would handle a class suit about Fair Use if all the alleged infringers were living on USA.

No sir. Their core business is to sell advertisements. The audience is not the paying customers, we are the "cattle" that provide them with the resources they sell to their paying customers. We are a natural and renewable but somewhat scarce resource being explored. It only happens that we are a very tricky kind of cattle - we can choose to who we are going to provide the milk, I mean, the resource. The money is not being shared. They are paying for a service. It happens that some of that "cattle" can give them some cheese, and not only the milk, and since they sell "cheese", is advantageous to save money on cheese factories and buying already made cheese from some of the "cattle". Yes. if the poster does something that make them lose money, they will act. However, if by acting they end up losing yet more money than they would by doing nothing, they will not. It's simple like that (assuming, of course, that there're someone on Google willing to make YouTube a cash cow. I can be wrong on this last assumption, as it appears). They need people watching their content in order to sell advertisement. If people enough gets liquided off and leave to other platform, this will have a significant impact on their incoming. So, yeah, it's their concerning that people are making a living off their platform. Because they can choose to make that living in another platform, taking their audience with them.

Dude, when young I had a friend that had a Honda N360. These cars made some success on Manaus at that time (the only place on Brazil where you could have a imported car). You do not board this car. You wear it. In my case, a 1.8M high, 1.2M round dude, it was like wearing a tight latex pant - I GOT STUCK on the front passenger chair, my friend had to call for help to get me out of the thing! They had to dismantle the seat!

How much they are asking? See the Reddit ToS - if you agree, use it. If you don't, don't. So don't use it. Close your account and go posting somewhere else if the Forum's ToS is not good for you. You are the one asking for money. Go find someone willing to give it to you. Except that YouTube wants to be the "patreon" themselves. It's their core business, dude!