Lisias

"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...

Hi, guys. I made a new release, 2.6.0.11, that again is essentially equal to the last one except by a little change telling the Weld Tool to ignore the ModulePartVariants, as I explained here. I still didn't investigated the CTB issue, but since any eventual fix will need to be done on KSPe, there's no need to postpone this one again. Other than updating the Modules Definition files, changing the dependencies to a All Batteries Included package and stating that I finally tested the damned thing on KSP 1.12.5 without creating an Armageddon, there's really nothing worthing an update on this one - if things are working for you right now, don't bother changing anything. https://github.com/net-lisias-ksp/UbioWeldContinuum/releases/tag/RELEASE%2F2.6.0.11 I think this release will help, as it make easier to use this on KSP 1.12.x . Keep in mind, however, that my fork is still an Unofficial one - due some legal restrictions I'm subject to, I need formal transfer of rights from the current Owner (not merely the last licensee) in order to really adopt this thing (sorry, really, but dura lex, sed lex.

I thought exactly the same when I read about: on KSP, my Kerbals were saved more than once by putting parts between them and whatever is approaching fast (usually the ground), and so that parts get destructed absorbing part of the impact, saving the green critters from pooffing,

Wait… Just by moving the game from the hdd to the ssd changed things so much? The only impact this should had is on loading times, nothing more!

This 90d rotating stunt is a pain in the SAS. I finally managed to animate properly a gimballed new… uh… 'engine' I'm doing. Man, what a fight. I managed to accomplish it by: Creating an empty node, calling it the name you will use on the Part config (thrustTransform, whatever) Rotate it 90d on the Blender's Z axis THEN you create/import/whatever the mesh and move it inside that node's hierarchy. In my case, I created a simple cone, resized it to fit inside the engine's mesh and move it there. I kept this cone without texturing, because I want to use it only as a reference, not to be displayed in game. Yet. Adding anything to the node's hierarchy before rotating it will completely screw up the results inside the game. And, yeah, I realised it by trial and error. About the engine, I'm reusing some game assets on the process - so the trick is to import the "source" into blender, create your changes on a different hierarchy, and then export only your hierarchy on a new mu file. And then stitch things on the Part's config MODEL sections, one fetching the original asset from Squad or SquadExpansion (or whatever you are using from), and other MODEL section for your customisations built over it (using rotate, translate and scale to make things fit as you want). Less things to redistribute (when allowed) with your package, less things to load into user's RAM. Now I need to learn how to deal with that GLOW stunt, to add cabin lights to some crewed parts…

The three of then? (Never understood how they work!)

From my side, while playing Career I found some contracts to rescue Kerbals from others Space Agencies, what IMHO implies there're other political entities around. Granted, I choose to see them as "Countries", but they may be also "Provinces" under the same Government competing from resources from the Central Government. Depending on your political and economical inclinations, one option will surely appeal more to you than the other. On the other hand, having different political entities disputing but also in need of cooperation have some interesting plot opportunities that I like to explore. I'm not exactly a prolific scify writer anyway, I need more common points on our and their culture in order to develop my gaming - and the Human History have absolutely fantastics plats that can be reused on this game! From my personal point of view, this would impose some serious limitations on their energy "budget" - there's only so much light per squared meter/foot/whatever that you can take from the Sun, and this gets even harsher as you fly away from this Source. Doing some napkin calculations, Kerbals would need a small RTG on their wrist (as wristwatches) in order the get the needed energy for moving around all the day (and night!!!). My take on the matter sounds more logical to me, and makes easier to achieve immersion on the game (for me, at least). Of course, there's so the problem of infinite Oxygen and Fuel supply - but this I try to work around with add'ons. I like to think that the Monoliths are there because someone (or something) needs the Kerbals for something. I'm spending more time coding than plotting in the last few years, so I really never developed too much this part of my gaming. Yet. This would add a bit of suspense (and perhaps horror) to the history, something that I would like to explore eventually. Not necessarily evilness - hardly, to tell you the true, as I don't enjoy this kind of plotline.

They will need to take a number and wait, as things are developing...