Lisias

Do a google for Lippisch P.13a - a god damned COAL fuelled fighter. And the thing were intended to be unarmed, its goal (by using coal - yeah, bad joke) was to ram the poor bombers in their way. Can't be more steam punk than that!

Chatterer as we would like to see on KSP.

It's raining clicks! Hallelujah! It's raining clicks! Amen! I'm gonna go out to Forum and let myself get Absolutely soaking clicked!!!! (no click images this time, only one set per page, I say! ) 202309090459z

That "shady ass" MMWD is not Module Manager, but a watchdog to warn you if you screw up with Module Manager. Tons of problems can be avoided when you just prevent more than one copy of Module Manager on your rig, and this is exactly what MMWD does. If you cared to look into the tool instead of calling wolf on it, you would had noticed that it never touches Forum MM, au contraire - it protects it if the user install any other version, older or alternative. @JebIsDeadBaby, you have an older Module Manager lingering on your rig, and an internal KSP bug is electing the older one to be used. Note that on the top of the list you posted, Module Manager is saying you have two copies of Module Manager 4.2.2.0 , but below on listing the files, you will find Forum's ModuleManager.4.2.2.dll and ModuleManager-4.2.3.dll. Checking on Forum Module Manager's source, we have confirmation that it's being compiled with the right Version number, so it's definitively the older one your KSP elected to use. Since you was using an older version of MMWD (1.0.1.1), that have this check deactivated on KSP 1.12.x (because I was told KSP was handling this correctly - what revealed being not exactly true some time later), the MMWD didn't barked at you about the problem. MMWD 1.1.1.1 (the newest) would had detected this for you. Seeing the Forum's MM release notes, this last version fix two problems, one of them on "loading the wrong physics file when you use the faulty PDLauncher workaround". Are you using any PDLauncher workaround? If yes, we may have found an issue - using an older MM even by having the newest installed, courtesy of one of the many bugs on KSP that Module Manager Watch Dog aims to detect - that is leading to your KSP to load the wrong data files.

"Father!!!! The Sleeper has clicked!!!!" AGAIN!!!

Ladies and Gentleman, we have a diagnosis. #houseMdFeelinds Somehow, your craft managed to get royally screwed: See, the SEQ containers are attached on the Lab, not on the Cargo Bay! So the SEQ weren't shielded from drag, plain simple. But HOW this happened? How some user could manage to attach a Lab with parts attached on its top node on the bottom node of another part? Well, they coudn't. This craft was screwed by something programatically. And we have already an issue about the Editor where the ReRoot is known to royally screwed up the attachment nodes (issue #66 on KSP-Recall). @Krazy1, do you remember using the ReRoot from the Editor on your craft?

Ah, I just remembered this one!!! (the second best KSP video ever!)

"Father!!!! The Sleeper has clicked!!!!" 202309081042z

EXACTLY! And that's the real power of Open Source - some maintainer are not doing a good job in your opinion? Anyone can do something about. Most will fail, usually, but we only need ONE success to have things back to rails (pun not intended). Again, there're drawbacks too (there's no free lunch), but most of the time the cost-benefit is positive. On a side note - be cautious about the CC-BY-NC-SA - the NC bites where you don't see it, it can be really counterproductive.

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!