Lisias

No, I'm not talking about this. I would be the first on the list if I would! I will not derail the thread with unrelated details, but I was meaning exactly what I wrote: active refusal to fix bugs even after the diagnosis was confirmed and a fix was proposed and even implemented. The last one I ended up shoving the fix on Recall, what's a hell of deviation of its intended purpose (not to mention bringing to me yet more responsibility on the damned thing as I now virtually doubled my test cases for acceptance).

I took them both. Amusing, but gave me a hell of a hang over!!! In time - CONFIRMED. Things happened on my rig exactly as you described. Thanks for your report and artefacts, now I have something to work with. I didn't did any further tests or analysis due working hours, but I will come back to this issue tonight (hopefully). Since I still think it's a KSP issue, I'm working this on Recall: https://github.com/net-lisias-ksp/KSP-Recall/issues/70 If I realise it's a problem on something else, I will move the issue to the right place. Cheers! — — POST EDIT — — I removed all non essential dependencies from the rig, and nothing changed. So this is not something being cause, induced or triggered by 3rd parties for sure. It's something on the CRG-15 Cargo Bay, or it's something on KSP itself. @Krazy1, on a side note… Since I was toying with your contraption, I found that setting the Chute's "Min Pressure" setting to 0.45 would bring us the most realistic (or the less unrealistic!) behaviour. With the chute firing up too soon, your craft would be facing down yet, and the chute wold surely be entangled on the aerodynamic brakes (nice idea! I liked it!). Setting the Min Pressure to 0.45, it will only fire after the brakes managed to do their jobs putting the thing nose up. (yeah, completely unrelated, but hell - I wanna play too!!! )

You care enough to use your time talking about it. (this is a compliment) That's the part of my argument I think you missed: people are leaving KSP not because they stopped loving it, but because they are tired of hating to love it. What's driving people away are the unsolved bugs and the cavalier attitude about user's long term experience that is plaguing this game for years. Most people never leaves Kerbins' sphere of influence, rare are the ones that reach Dune. Why? Because doing it is hard and time consuming as hell, and the last thing the user wants is to restart everything from scratch every time something is updated. But the user choose to update because besides potentially bringing new bugs, the update also fixes bugs that are peskying them and they can't take them anymore. So the user ends up caught on doing only minimalistic playing - what's, frankly, boring as time goes by. Sooner or later the user gets tired of doing the same things all the time (fooling around Kerbin), but he's still afraid of engaging in long term missions (months of planning and executing) because they're fed up of being hit by mysterious bugs - that suddenly goes away, but there's no hope that for good and so the user just stops playing. And I'm kindly ignoring the elephant in the room around here: a modding Scene that actually refuses to fix their own bugs too. And then the user goes hunting something else to play, and they will adopt the game that gives them whatever they mostly liked on KSP, even that at expenses of losing the things they care a bit less. Every single one of the games I mentioned gives you something that you have on KSP at expenses of some other things that they don't - so different people will prefer to migrate to different games. No, Juno is a completely different concept under similar mechanics. Juno is a "modelling dough" game, everything is procedural and you can build whatever you want. KSP is a LEGO game, you have a finite set of parts and try to build what you want from them. Being able to fly the contraptions later is just a logical aftermath, and everything else is just support. It may not look this way, but Juno is in a way better position to linger than KSP right now. Whatever Juno doesn't have yet, it can be implemented and better (like using the procedural parts as building blocks for "shelf parts" that need to be tested et all, and only then be useable - think on KSP's and Factorio's loving child), but whatever Juno does better, KSP is not following suit and, as it appears, never will. You are right about things not changing overnight - but they are changing nevertheless. To where this is going, it's up to us to decide. The 5 steps of Grieving/Acceptance. denial, anger, bargaining, depression and acceptance KSP is going to have a hell of a long Grief as it appears.

Well, "competition" is anyone that may "steal" your users from you, not necessarily by doing the same thing. If the user leaves you in favor of other game, then even Sky Rogue is a competitor because, hell, I'm using my free time playing Sky Rogue instead of KSP lately because I got fed up of finding and fixing bugs most of the time I decide to play KSP. As a matter of fact, KSP it's also its own competitor. I finally managed to built a KSP installation with good enough performance and excellent stability (now that I worked around the worst bugs) using… KSP 1.4.3 (this is the first week this whole year I didn't fired Sky Rogue). Yes, it's missing a lot of features, but yes, it's also missing a lot of bugs - and I can live without the features (since most of them are available on add'ons, and I'm skilled enough to fork most of them and make them running on it). So, if you are betting KSP is safe because there's no direct replacement yet for it, I'm afraid you are going to loose your money. Starfield is going to lure players willing to do interstellar travels - and you can customize your ships. No Man's Sky is a hell of a surviving and exploring game, and a decent open world adventure one - some of the things that some KSP players are asking for years. Space Engineers are a hell of a fun game for builders - just forget about newtonian physics while travelling on space and you will be good. There's also this Empyrion game, but I'm still to find time to explore this one. Elite First Enc… I mean, Dangerous is another hell of a open work rogue style game - combat, mining, survival, you name it. Oukey, no custom ships on this one. Surviving Mars will surely attract people willing to manage colonies. But, hey, all of these are high profile games. There're also the underdogs! About 5 years ago, some dudes from Czech Republic pulled a game called Planet Nomads from their hats. Hell of a game, very decent survival and building game. I spent a couple years playing it instead of KSP, and just stopped because I noticed that this game share some of the Unity problems that KSP has, that were mitigated exactly the same way, and then I caught myself writing tools to make my life easier on the game… And then I realised that, hell, I don't need another KSP in my life (and then I bought Sky Rogue!! ) This freaking game is not half of what KSP provides, but the other half is fun enough. Imagine a KSP where you can modify the terrain and build shelter with sparing parts and still need to survive (including hunting the local fauna). Kiss baby bye-by to newtonian physics, though - this game literally gave the finger to Sir Isaac Newton. Other interesting game that can lure some of the current KSP players is this new kid, EarthX - it appears to be more focused on the managerial aspect of Space Exploration, but I only discovered it this week and didn't bought it yet. (they directly support Linux and MacOS! #hurray!!!) And the list goes on. Once people decide to ditch KSP, they will ditch KSP for any other game (or games) that gives them whatever they were seeking on KSP. Different people play KSP by different reasons, and this was one of the reasons that made KSP such a Cultural Phenomena: it gathered together different people that, otherwise, would not spend time together on the same place. About Juno… Boy, don't belittle these ones. I don't think they are doing everything rigth if they really want to be a KSP alternative, but they are on the right track. But Squad was in the exactly same waters 10 years ago - there's nothing preventing them to do the same (other than a hell of a more fiercely competition nowadays…). KSP goes belly up, Juno is where I'm going. This is another game that I'm playing now and then, by the way. Would probably be playing it right now had I didn't managed to stabilise my KSP 1.4.3 for "serious playing". I completely missed that one… Thanks God this wasn't a rock aiming my nose. Yeah, KSP2 is a serious competitor for KSP¹ - I completely forgot they are/were maintained by different companies inside a Corporation… They are, indeed, competitors!

For reasons beyond the scope of this discussion, something happened in the past that made Forum Module Manager incompatible with the Welding Tool. TL;DR, I gave up and forked MM for my own use. Other tools were created to help keeping your KSP healthy using knowledge I gathered while doing Support around here, having them installed will prevent more than 80% of the issues that used to plague KSP in the past. This is the reason I advise to have a special KSP installation for welding things, as you need to have my MM Fork installed in order to use the Welding tool, as most authors around here will not support you if you use my fork of MM (obviously, I do). Additionally, I use a toolset that help me on maintaining homogeneity on my development, it's the KSPe thingy. Some people suggested me to create a All Batteries included package to make first installers life easy, it's the Modular Management thingy - it have all he startup add'ons you need. Installing the thing could not be easier (as long you know who to copy files on your Operating System!): whatever is inside the GameData on the zip file, should be copied inside the GameData of your KSP. Remove the Forum's MM if you have it installed on that GameData (again, it's advised to use a dedicated KSP for welding, so your main gaming one will be supported by all authors on this Forum - I will support you both ways, but I don't provide you with all the add'ons you need, so…) This file and this file give you hints about how your GameData should look after installing things. The following videos may help you if you need to learn how to unzip things on Windows (the most used O.S. around here, there're similar videos for MacOS and Linux if you need them), as well how to copy files from a place to another. Again, I strongly suggest you make a full copy of your gaming KSP and try things with it first - do not mangle with your main KSP until you are able to install and remove things with success, or you will ruin your KSP!!! Use a copy as guinea pig while you learn your way. I strongly suggest you unzip the distribution files on a temp directory, and then copy the respective GameData contents to inside your KSP's GameData. Remember, you need to copy the Zip's GameData contents to your KSP's GameData, not the thing itself (i.e., you don't want a GameData inside the game's GameData directory).

Can you provide us with a minimal craft where you reproduced the problem the last time? I'm sure you found something, I just didn't managed to zero on it. I'm digging around not only Forum, but also github and reddit for reports of problems involving Cargo Bays and drag and, indeed, there're some reports blaming Attachment Node Sizes - but not enough details about, so I'm still on the dark. However… Remembering my own bad experiences with Cargo Bays in the past (good thing I had saved all that backups!), I came to a possible M.O. : the Attachment Nodes Size may be a problem while attaching cargo on themselves inside the Cargo Bay! All my tests until now used only one part inside the Cargo Bay, but now that it's clear that the problem is more complicated than that, we may be facing a insidious problem on the cargo itself, not on the Cargo Bay… Or at least something on the Cargo Bay being triggered by the cargo's Attachment Nodes (instead of the Bay's inner attachment nodes as I had initially thought). You are not the first one to report such thing: where there's smoke, usually there's fire - or at very least a source of heat.

Because the assets is what make the game… The Game. And we are not pledging that the Game itself would be made freely available, we don't want to "steal" the game from them. The Source Code is just the nuts and bolts that ties the internal mechanics together. The difference between a Beetle and a Porsche is not the nuts and bolts they use, but on how they are used. There's this weird thinking on the wild giving too much importance and value to the Source Code. The Source Code is just the means, the end is where the money is, everything else is just operational cost. Commercial enterprises tend to hide their Source Code not because the Source Code is valuable, but because the ideas expressed in the Source Code are valuable, and by reading the Source Code you would get the whole idea without effort (i.e, without spending money on trials and errors until the damned thing started to work). On a thought experiment: if KSP would be completely rewritten from scratch using Unreal Engine, it would be the same Source Code? Not by a mile. But KSP would be still KSP, the Kerbals would be still the Kerbals, and other than the absence of a few glitches from Unity (and the presence of some new ones from Unreal), the end user would hardly note any change. Now, another thought experiment: there's no DRM on KSP, there's absolutely nothing preventing me (other than my sense of morals and my professional ethics, of course) to illegally distribute bootleg copies of KSP on the wild [edit: under a nickname or fake persona, obviously!]. What difference would make if by any reason I manage to recompile the whole thing fixing the bugs before illegally redistributing it? Whoever had downloaded the illegal copy would just download another illegal copy of the damned thing. No (further) harm, no (further) foul. on the other hand, if I have the rights to legally recompile KSP with the bugs fixed and legally distribute such binaries (and only the compiled binaries) to people that had legally bought KSP (and they have to buy the thing, because I would not redistribute any of the assets that make the game The Game), exactly where are the harm of this endeavour? If only people that had bought the game would be able to use such derivative binaries, people that don't have the game would be enticed to buy the damned thing, or just no use it al all. people that had downloaded a bootleg copy of the game would also have access to it, but they already choose to be on the dark side, nothing will change here. Again, no harm, no foul. But people that had bought the game would have a better experience, and people that didn't would have an incentive to buy it. Source Code is nothing but cement, bricks, nuts and bolts. The first time you build something incredible using a novel combination of such commodities may give such Source Code some intrinsic value due it's scarcity, but as soon as people out there figure out how it was made (or create new ways to accomplish the same thing), that value quickly erodes into oblivion. KSP's Source Code worths very little right now, to tell you the true. Not only because there're shady ways to get it anyway (the shady practices I mention all the time), so anyone with the will and freely available tools and knowledge (and a bit of skills and free time) already have it - but because there're already alternatives to KSP on the wild, some of them with better implementations of some KSP's features. What's still worthing something is the RIGHT to use this Source Code legally because there're still demand for KSP itself, but such demand is also eroding as the eternally unfixed bugs on KSP are making people enough fed up. The World is evolving, the competition is not only catching up but surpassing KSP. What still remains valuable are the Cultural Phenomena KSP still are due the good memories of the past achievements. But this will not last forever.

"no Intellectual Property of any kind - except the Source Code." it's my understanding that this phrase implies that the Source Code is an IP, the word "except" would be an, well, "exception" meaning that only the Source Code would be the only IP those some rights would be granted. "no Intellectual Property of any kind - but the Source Code." would sound better? Both phrases translates exactly the same to PT-BR, so I really can't tell the difference. BUT… If you want to discuss Open Source philosophy… Yes, Open Source is Intellectual Property, and that's the reason we need CopyLeft licenses to protect it. Your garden is not less your property if you decide to let your neighbourhood' kids play on it (granting them a "license" to play on it) - you can even impose conditions in which they can do it, as demanding they fix things that get broken and/or clean up the place before the end of the day, or you would revoke their "license" to use the place. Such "license" was already granted to us! Sometimes I toy with the idea on "perverting" the KSP's Look and Feel to look as a late 90's MS-DOS game, with Gourad Shading et all. But we are digressing - assets are out of scope of our pledge (and we already have the Add'Ons to provide new assets anyway, we already have such legal permission!)

Fair question. Let's check it with moar testings . And you appears to be right, but on the other hand this contradicts reports from other people. So I concluded we don't have enough information yet. Digging around, I found that matching external attachment nodes sizes it's important for structural integrity. But I also found reports correlating attachment nodes to drag. In a way or another, being due drag or not, ideally we should match attachment nodes. This we already have proved it works. How it works, and under what circumstances I don't know, and I will not pursue this one until I have nailed the problem under our noses first - unless we realise it's all the same thing. Humm… Write down carefully every single step you took on every single attempt. Sometimes, one small little detail is the trigger for the problem! In a way or another, I made another one trying to figure out why you would be having problems on reproduce the mishap deterministically. Pehaps something like this? I have conflicting reports about this matter, more studies are on the way - I found one anomaly, but appears to be unrelated to attachment nodes. On the bright side, I had already wrote the patches and they are easily editable to suit our test cases, so we have some tools to play "what if". Worst case scenario, I ditch the patches and call it day, no harm no foul. At very worst, I now have new toys to document and audit parts - hardly a bad outcome. I forgot to mention, but I'm auditing every single part from A+ using the tools I created to check the problem above, and I'm fixing them. Lots of nodes on A+ were defined… creatively. This is material enough to worth a full release, so I expect to kick one through the doors for this weekend.

One click to rule them all, one click to find them, One click to bring them all and in the Forum bind them. 202309060051720z

That's the thing: I'm not willing to appeal to their kindness or extreme altruism (you can bet your cheeks I'm none of these neither). We intend to demonstrate to them that Opening the Source may be a viable solution for their current problems (and they are many). It's important to remember that Opening the Source involve only the Source - no assets, no lore, no Intellectual Property of any kind - except the Source Code. We need more skilled eyes around here, and the most skilled I know are not willing to engage if using shady practices (considered piracy on this Forum) is the only way to accomplish that. I surely won't, by the way. There's no Free Lunch - the idea is we scratch their itch, their scratch our itch, and all parties earn something in the process.

Gee!!! Now I need to build this on KSP!!! The craziest thing able to land on water that I had seen! http://www.luft46.com/bv/bvp111.html

If we could ignore them, we would not have the problem at first place! Everytime you attach two parts those node's size are different, you get drag. [not reproduced inside cargo bays!] Now, on Cargo Bays, you have two sets of nodes: a set for external attachments, and sets for internal attachments. By definition (the whole Stock and StockExpansion abide to this), the internal set of nodes are 1 point smaller than the external ones - what makes sense, you can't carry parts inside a cargo bay that are on the same size, only smaller! However, when Making History was released, a new bulkheadProfile was created, the size1p5 - but KSP has only 5 Node Sizes coded (from 0 to 4). So the dude/gal/person that was creating these new parts had to make a hard choice (don't blame them by the mistake - my chances of doing exactly the same are about 50%, depending on how much time I was already playing with cargo bays at the time), and by bad luck, they did the worst choice - rounding to the ceiling. For external attachments, as long everybody agrees that size1p5 is a Node Size 2, everything will work just fine. It's on internal attachments that you will get screwed by this decision (I know I'm being repetitive, but I want to make this clear to people dropping on the conversation out of the blue too), because besides visually and mechanically (i.e., colliders) a size1p5 is able to fit inside a Size2 cargo bay, you will get drag no matter what because (by definition since the beginning of time), cargo bays have the internal nodes one point smaller than the external and, so a Node Size 1 internal node for a Size 2 Cargo Bay - but the part you are attaching inside it have a Node Size 2 (besides being smaller, 1.5). I don't see a way to fix this without breaking something. What's clear is that giving size1p5 parts a Node Size 2 is causing a lot of confusion for people willing to use cargo bays - and there're a lot of them, by the temperature of my ears. "Fixing" all size1p5 MH parts to Node Size 1 appears to be the logical solution, but we will break a long standing standard, what are followed by lots and lots of 3rd parties (including A+), and they will need to be updated too or you will get new complains from the same people by similar reasons. I just though on a forth alternative (adding to that 3 I posted above): rising the Cargo Bays internal node sizes 1 point, making them the same size of the external ones. This is the easiest route, no doubt - but it will allow people to attach Size 2 parts "inside" Size 2 Cargo Bays without penalty, and this is something that would open a ticket on the bug track for sure, because it breaks a specification (a long standing one). But even by going the krap way, we will still need to patch everybody's else Cargo Bays too, so again a update fest on the Universe… (sigh) From my personal point of view, if I'm going to get screwed no matter what, I would like to do the Right Thing™ and maximize the gains on the long run (as on the short term, I'm screwed no matter what). But I want to be sure about what is the Right Thing™ at first place, because I don't find productive having a hell of a work just to have a the same set of problems happening in other place: if I'm going to get hurt, I want to get hurt only once. Yes, we would not have problems if not! Let me explain this to you graphically (on the using graphics sense, not the other meaning!! ). This is a good setup: A Size2 Part with a Size 1 Part inside, this will cause no drag: For the sake of curiosity, the Mark 2 Cargo bays are the only ones I'm aware those internal Nodes have the same size of the external ones - for a good reason, as besides having 2.5 meters wide, they choose to give them a Size 1 external node (by mistake, perhaps?): Interesting enough, the Short Mk2 Cargo bay have internal nodes set to 0, while the Long have the nodes set to 1. I think this is a mistake, the Short one should have Size 1 too!!! The following setup will generate drag, completely counter-intuitive! Now things start to go South: a size1p5 Part inside a Size 2 Cargo Bay: And this M.O. is replicated everywhere, virtually every 3rd party I inspected until the moment followed suit with giving the internal node a point smaller than then external, while rounding the p5 parts to the ceiling. So Size0p5 uses Node Size 1, not 0; Size3p5 uses Node Size 4, not 3. And then we have this very same situation scattered over the Scene, with people attaching visibly fitting parts inside the cargo bay but getting unexpected drag!! — — POST EDIT — — Until this moment, I didn't managed to induce drag misbehaviours due internal attachment nodes. I think I got some issues on resistance, but I don't think they would worth a large scale intervention. Still studying the issue - there are reports of differences on attachment nodes causing issues on cargo bays, but they weren't specific enough.

Technically, yes. The problem is the consequences - because we would need to patch every single part under the Kerbol to follow suit, or we will have what around here it's know as a "short blanket problem" - if you cover your chest, your feet gets cold and vice versa. I'm inspecting some other 3rd parties, and until the moment everybody is following suit with Making History - rounding the "point 5" sizes to the ceiling, and not to the floor as I'm proposing. So, by patching MH parts now, everybody else will start to have problems. There's also the stablished standard: add'ons with custom sizes, like size0p5, size1p5, etc, are also rounding the Node Sizes to the ceiling, adding yet another layer of complications to our already complicated problem. AFAIK, we have three options: Get consensus on the Scene, where everybody would agree to round the point 5 sizes to the floor, and so we would rush on an update fest for the entire Universe We pull up something from our hats to do it programatically on the user's machine, automatically switching the Node sizes for parts with point 5 sizings. A bit hairy as there're a lot of part with multi bulkhead support, and we need to patch only the respective nodes, and not all of them. We selectively patch parts from the most used add'ons, and hope people will get into the wagon as time goes by adding "support" to it. Obviously, user should be able to activate or not the option. I think the option 3 is the less worst way to go. Everybody still follow suit with Making History on Releases, as we have about 6 years of a standard (being it crappy or not) to cope, and this change will break crafts relying on the older behaviour for sure.

Hello Forum, my old friend I've come to click with you again Because a email softly creeping Left its seeds while I was sleeping And the contents that was planted in my mailbox Still remains Within the sound of clicking…

And… I found a problem inconsistency on Stock!!! It's not a "bug" on the Part Config, it's more a conceptual problem. That's the history: Making History introduced the size1p5, or 1.5 the size 1, or 1.875 meters. However, someone had the extremely unhappy idea of giving these parts a Node Size of 2! Problem: Size 2 Cargo Bays are 2.5 meters wide, and mechanically can hold Size 1.5 parts inside. However, since the Size2 Cargo Bays sets the internal attachment node to 1 (one point less than their bulkheadProfile), by attaching a Making History 1.5 size part inside such cargo bay, you will get drag!! Visually and mechanically (a.k.a colliders) a size1p5 part will fit inside a size2 cargo bay, but since the size1p5 was defined as a Node Size2, the physics engine will inject drag on it because the cargo bay's node is smaller than that. Defining the size1p5 atttachment nodes to 2 was a huge mistake. We need to rebalance the Making History parts' nodes, but by doing that we will "breaking legacy" - and anyone that followed suit to Stock will need to rebalance their parts too, on a cascading update fest. Request For Comments!

Is there anyone left over there? Speaking frankly, since every new release lately is breaking more things than they are fixing, I fear it's best just to leave things as they are - or just Open the damned Source for once!

<please disregard - I misdiagnosed something>

Yep. Just inspected them, and I found one 2.5 part with the wrong definitions. https://github.com/zer0Kerbal/CargoBays/pull/53 At least one of the problems you found will be fixed by it - and I suspect that a lot of other problems are due 3rd parties (or even Stock), as I finding such mishaps on every corner I look!!!

METAR I think I finally found the reason why people were complaining about TweakScale, supposedly, screwing up some parts due excess drag. The reason (as you may be already guessing by now) was not TweakScale, but some Stock parts being shipped with the wrong settings. <Nope - A double inspection revealed that the settings are unusual, but not necessarily wrong!!!> Garbage In, Garbage Out - if the source part is already screwed, TweakScale will scale the problem as well. Right now I'm inspecting Stock parts (as well anything I wrote patches to) for more problems. (krap, krap², krap³!!!!) — — POST EDIT — — Stock, indeed, has a conceptual problem not exactly a bug on a Part Config, but a "bug" on the guidelines used to write such Part Configs! See this post for details: — — POST EDIT — — That conceptual weirdness may play havoc on integrating 3rd parties parts, but the Real Problem™ was found to be our now old friend, ReRoot (mis)feature. I finally have a case of Lupus. House, MD.

No. The CRG-15 is defined right, it's something else now. I want to bring to your attention that we just diagnosed STOCK PARTS with the wrong node settings - a complete mess. <Nope!! That part's settings were unusual, but not necessarily wrong. I will further investigate them, though>. This is probably the reason add'ons are taking the blame for the drag problem, because if you "fix" for some parts, you break them for the others and vice versa. DAMN. —— POST EDIT — — Ha! I was right, I found a problem inconsistency on the node's definition on Stock!! See below!!!

Interesting. I did a peek on the configs, including stock, and this is what I got: Nodes from MK1 parts ending up with _top and _bottom have a node size 1 (the default by absence). Stock cargo bays have two addition sets of such nodes, _top2 and _bottom2 , slightly inside the mesh. These are the attachment nodes for cargo, inside the bay. For MK3 parts, they have a size 1 point smaller than the outer nodes. The A+ Sliding Door Mk1 cargo bay have the _top2 and _bottom2 nodes one point higher than the outer nodes! So we found the problem, my tests were made by surface attaching the ore tank inside the Cargo Bay! Oukey, we found the problem. And the fix is simple, as well the workaround: @PART[mk1cargodoor] { %node_stack_top2 = 0.0, 0.9175, 0.0, 0.0, -1.0, 0.0, 0 %node_stack_bottom2 = 0.0, -0.9175, 0.0, 0.0, 1.0, 0.0, 0 } Shove this patch somewhere in your GameData (I suggest Gamedata/__LOCAL/AirplanePlus/mk1cargodoor-drag-fix.cfg), and you are set. NEWS FROM THE FRONT I inspected some Stock parts from KSP 1.12.5 and… DAMN, what a mess. The mk1pod_v2 has a bulkheadsize as size1, and the node_stack_bottom has a node with size 1. Same for Mark1Cockpit and landerCabinSmall. This contradicts the other mk1 parts I found, as the following parts have a top and bottom node with size ZERO: Mk1FuselageStructural MK1IntakeFuselage MK1Fuselage nacelleBody radialEngineBody Mark2Cockpit So we have a problem! Some STOCK parts for parts with size1 (1.25m) have a _bottom and/or _top nodes set as 0, but other as 1! It's not a surprise so many people are complaining about drag!! #facePalm — — POST EDIT — — Found a pattern: everything on GameData/Squad/Parts/Structural/mk1Parts are setting the attachment nodes size to 0, while everything else is using 1 . KRAP, man… This is a freaking mess! Stock parts are screwed up!!! — — POST POST EDIT — — This krap was detected downto KSP 1.2.2 (don't have anything older installed to keep digging). Damn, this explains why people blamed TweakScale for problems related to drag in the part - GARBAGE IN, GARBAGE OUT. If the source part is already messed up, the resulting one will be too! — — POST POST POST EDIT — — It's not certain that having "weird" values on the cargo bay attachment nodes will cause negative impact on drag - at least, no test corroborated this thesis yet. It may cause other issues (or not), but it's out of the scope of the present study.

Oh, well… It's diagnosing fest again. First let's see when the problem started. I made a quick & dirty (but still fun) aircraft using the Mk1 "Sliding Door" Cargo Bay (one of my favorites), shoved a small ore tank ("Radial Holding Tank") inside and kicked the thing into the air, using "Display Aero Data em Action Menus" from the Alt+F12's "cheat" Physics entry. The M.O. was: Fire the craft into the runway; (I bluntly copied the craft file between KSP versions and save it again on the target's Editor, but the savegame was a new one created on the target) Move the camera into the Cargo Bay exposing the ore tank (do not touch the cargo bay itself) by using the Zoom (mouse's roll wheel) and mouse movement; Right click on the ore tank, then click on the attach icon on the top left so the PAW would be persistent; Alt+F12, Physics, tick the "Display Aero Data in Action Menus"; Note the drag values on the PAW; Fire up the engines, take off; Note the Drag values on the ore tank's PAW stable on 0.0. Once you reach about 100 m/s, open the cargo bay; Note the Drag values on the ore tank's PAW coming to life. Close the cargo bay; Note the Drag values on the ore tank's PAW getting back to zero. Listing of my GameData: drwxr-xr-x 13 lisias staff 416 Mar 16 18:55 000_KSPe -rw-r--r-- 1 lisias staff 29184 Jul 4 19:10 000_KSPe.dll -rw-r--r-- 1 lisias staff 170496 Jul 4 19:10 001_KSPe.dll lrwxr-xr-x 1 lisias staff 72 Sep 4 20:37 666_ModuleManagerWatchDog.dll -> /Users/lisias/Workspaces/KSP/runtime/_pool/666_ModuleManagerWatchDog.dll lrwxr-xr-x 1 lisias staff 57 Sep 4 20:36 999_KSP-Recall -> /Users/lisias/Workspaces/KSP/runtime/_pool/999_KSP-Recall lrwxr-xr-x 1 lisias staff 63 Sep 4 20:37 999_Scale_Redist.dll -> /Users/lisias/Workspaces/KSP/runtime/_pool/999_Scale_Redist.dll lrwxr-xr-x 1 lisias staff 83 Sep 4 20:36 AirplanePlus -> /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/AirplanePlus/GameData/AirplanePlus/ lrwxr-xr-x 1 lisias staff 60 Sep 4 20:36 Firespitter -> /Users/lisias/Workspaces/KSP/runtime/_pool/Firespitter.u2019 lrwxr-xr-x 1 lisias staff 64 Sep 4 20:36 KAX -> /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KAX/GameData/KAX drwxr-xr-x 5 lisias staff 160 Sep 2 02:55 L-Aerospace drwxr-xr-x 8 lisias staff 256 Jul 19 2022 ModuleManager -rw-r--r-- 1 lisias staff 129024 Jan 24 2023 ModuleManager.dll lrwxr-xr-x 1 lisias staff 64 Sep 4 20:36 ModuleManagerWatchDog -> /Users/lisias/Workspaces/KSP/runtime/_pool/ModuleManagerWatchDog drwxr-xr-x 28 lisias staff 896 Jan 15 2023 Squad drwxr-xr-x 4 lisias staff 128 Aug 4 2021 SquadExpansion drwxr-xr-x 4 lisias staff 128 Oct 9 2021 __LOCAL drwxr-xr-x 7 lisias staff 224 Sep 4 19:37 net.lisias.ksp ./__LOCAL: total 4 -rw-r--r-- 1 lisias staff 111 Oct 9 2021 JetEngine.cfg drwxr-xr-x 6 lisias staff 192 Oct 9 2021 TweakScale ./__LOCAL/TweakScale: total 0 drwxr-xr-x 3 lisias staff 96 Oct 9 2021 BreakingParts drwxr-xr-x 3 lisias staff 96 Oct 9 2021 HotFixes drwxr-xr-x 3 lisias staff 96 Oct 25 2019 Tests drwxr-xr-x 3 lisias staff 96 Oct 9 2021 Workarounds ./net.lisias.ksp: total 0 lrwxr-xr-x 1 lisias staff 67 Sep 4 20:36 CrewLight -> /Users/lisias/Workspaces/KSP/runtime/_pool/net.lisias.ksp/CrewLight lrwxr-xr-x 1 lisias staff 79 Sep 4 20:36 KerbalObjectInspector -> /Users/lisias/Workspaces/KSP/runtime/_pool/net.lisias.ksp/KerbalObjectInspector lrwxr-xr-x 1 lisias staff 66 Sep 4 20:36 PartInfo -> /Users/lisias/Workspaces/KSP/runtime/_pool/net.lisias.ksp/PartInfo lrwxr-xr-x 1 lisias staff 69 Sep 4 20:36 VesselMover -> /Users/lisias/Workspaces/KSP/runtime/_pool/net.lisias.ksp/VesselMover lrwxr-xr-x 1 lisias staff 53 Sep 4 20:36 mkext -> /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/mkext My results: On KSP 1.3.1, the ore tank's drag was zero as long the Cargo Bay is closed (you open the cargo bay, you got the drag back) On KSP 1.4.3, same thing. Everything works as expected. On KSP 1.7.3, same thing. Everything works as expected. This settle the case for the Old School® guys. Now let's inspect the New Kids™ on Unity 2019 (unfortunately, the migration from Unity 2017 to Unity 2019 broke a lot of things, perhaps this would be one of them). On KSP 1.8.1, surprisingly - same thing. Everything works as expected. On KSP 1.12.5, same thing. Everything works as expected. Caveats: I can't call this a clean, pristine Test Session because I used my in house or development versions of everything (but Squad and SquadExpansion, of course), and not any Official Releases you probably used youself. So there's a chance that I had "fixed" the problem by accident somewhere on my code or assets. (I did this way because my test beds were already configured with them, so I could get results quicker.) However, it's also pretty possible that whatever is screwing with you, are installed on your rig and not on mine. In a way or another, I need to redo these tests on a clean, official release only installation to see what I get. At least I can get directly into the point, 1.12.5, as it's already known that whatever is happening, is not exactly on KSP this time.

Hi! Yeah… TweakScale has a hell of a big mouth, it yells on anything it find smelling funny. I heard of people that installed it, removed the patches and kept the DLL just to be yelled if something goes south on the rig. It's annoying sometimes, but still better than losing your savegames - what would happen eventually with or without TweakScale, because whatever affects TweakScale, also affects other add'ons. You may want to install Module Manager WatchDog too. It will yell on situations that TweakScale is not able to detect involving MM.

That's the interesting part: structural panels are excelent shock protections! When building things with command seats, I build a "tub" around the pilot using the structural panels - TwealScale helps a lot. My Kerbals survive rate on... "landings"... improved a lot. I still need to work on the vessel survivability, though...