Lisias

You know... I'm a retro-computer enthusiast. And I got some retro computer from the Soviet era and... Dude, they are "bad" (note the quotes), but also... Pretty good! Oukey, they were starting and, so, copycatting whatever they found in West and adapted to their needs, but still... I have here two home computers based on the PDP-11 architecture - damn, the best the West had at that time were Z-80 ZX Spectrums or 6502 Commodore C64 - the 68000 were being used on 50K USD (in 80s USD!!) HP 300 Mini Computers and high performance UNIX Workstations!! Looking on that Soviet tech, the conclusion I reached is that Soviet really excelled in Engineering (perhaps even more than the West), but failed terribly on Manufacturing. Going back to my retro-computers, the design and the ideas look pretty good for the era - but quality of the plastics and the reliability of the components are the problem on them. And what you said apparently corroborates my hypothesis...

Idiocy is "contagious" disease. There's a old adage from my time in which I thought it would be a good idea to try a PMP certification (yeah, yeah... I was younger and inexperienced at that time ): Good Managers don't work for Bad Managers. You see a Bad Manager, you can be absolutely sure all the managing hierarchy under him is equally bad, or in the way to be - because the good ones that haven't left yet, are working on their way out. This is not a new phenomena - it was always this way even before Management became a concept. Completely removing the remedies it used to exist to prevent incompetents from reaching the top brass. You see, idiocy and incompetence are the inherent state of the Human Being - we all born idiots and incompetents - we have to learn our way out of it. If we remove the very mechanism that allow people to learn from their mistakes, they will not have any incentive to do it - they will not even realize these are mistakes at first place. Ignorance is the root of all evils. I couldn't agree more. I started to see these things in the I.T. Industry from the late 70's. With the enormous successes they got, other Industries started to copy cat it, and this is the net result. Steve Jobs and Bill Gates are the new Jack Welch - the worst possible practices from manufacturing reached the IT engineering and computer science in the late 70s, and from there started to spread to everywhere. Now we have, essentially, two generations disconnected from best practices (that works) and professional ethics (and I'm not even touching the legal factor - some of these people should be in jail).

IMHO, that's the problem. You see, good engineering was always about finding the "good enough" sweat spot - money is a finite resource, trying to do everything perfect will bankrupt you before the end of the project. There're exceptions to that rule, but they are few. As an example, see Boeing Starliner - a unholy mashup of good engineering and bad engineering tied together and launched into space. That damned thing didn't killed anyone because there're very, very good engineers working on that thing. But it's failing to fulfill its role properly because there're some bad ones working unchecked on that thing too. You didn't realize the problem because the previous generation (the ones that came before you and me) did a really, really, really good job. It took decades until the bad ones managed to start to screw up things enough to the industry start to crumble. I know you know what follows, but some people around here doesn't, so I will go "condescending mode" from this point so they can be part of this discussion. We write software in layers. The best are the lower layers, most resilient they are to stupidities made on the higher ones. For some time, idiots on the higher management managed (pun not intended) to walk from their stupidity because there were good engineers enough in the field working on the lower layers of the Software, and these heroes carried on the burden on their shoulders and prevented the disaster. But as the good ones started to retire, their positions started to be filed by the stupid engineers that Idiots were hiring in the past - and then we have bad engineering happening on the lower layers of the Software Stack - and when this happens, there's no point on hiring excellent engineers to work on the higher layers, because they will be forever sabotaged by the stupidities on the lower ones. So, in essence, the problem is not being "good enough", but IDIOTS DECIDING WHAT'S GOOD ENOUGH. --- -- - POST EDIT - -- --- Anyone willing to bite this bait , we moved the discussion to this:

You are right, my apologies. I, indeed, ended up shoving DXT3 DDS files on the distribution, and KSP ignored them loading the PNG files instead - masking the problem. KSPCF is ignoring PNG files when a DDS texture is present (a reasonable decision), and then KSP, finaly, spits the warning on the log. Yes, this is going to done before the end of the day. Thank you!

I reproduced the problem pretty easily: Get a clean KSP 1.12.5 (Stock, DLC and Module Manager) Install KAX Fire up KSP - no problems Install KSPCF Fire up KSP - DXT3 problems on some KAX textures. [LOG 03:25:45.116] Load DDS texture: KAX/Parts/KAX_radialProp/radialPropBlu [WRN 03:25:45.117] LOAD FAILED : DDS: The 'DXT3' format isn't supported, use DXT1 for RGB textures or DXT5 for RGBA textures [WRN 03:25:45.117] Duplicate PNG texture 'KAX/Parts/KAX_radialProp/radialPropBlu' with extension 'png' won't be loaded [LOG 03:25:45.144] Load DDS texture: KAX/Parts/KAX_radialProp/radialPropChk [WRN 03:25:45.144] LOAD FAILED : DDS: The 'DXT3' format isn't supported, use DXT1 for RGB textures or DXT5 for RGBA textures [WRN 03:25:45.217] Duplicate PNG texture 'KAX/Parts/KAX_radialProp/radialPropChk' with extension 'png' won't be loaded [LOG 03:25:45.469] Load DDS texture: KAX/Parts/KAX_radialProp/radialPropRed [WRN 03:26:24.211] LOAD FAILED : DDS: The 'DXT3' format isn't supported, use DXT1 for RGB textures or DXT5 for RGBA textures [LOG 03:26:24.439] [ModuleManager] INFO: Loading Physics.cfg [WRN 03:26:24.447] Duplicate PNG texture 'KAX/Parts/KAX_radialProp/radialPropRed' with extension 'png' won't be loaded The trigger I found is having a PNG and a DDS with the sane name (for example, radialPropBlu.png and radialPropBlu.dds). Somehow, KSPCF decides to overwrite radialPropBlu.dds the with a new one, but on DXT3. I'm unaware if there're more triggers for this problem. Removing the PNG's dupers (and restoring the original DDS's) prevents triggering the problem (next KAX release will have it sorted out), but the problem is still there on KSPCF waiting to bite another one. IMHO, KSPCF should not silently rewrite 3rd party assets (would had allow me to diagnose the problem way quicker) and, yet more important, when doing it, do not use a texture format not supported by KSP (what would had prevented the problem at first place). === == = POST EDIT = == === I was wrong. KSPCF unmasked the problem, by ignoring PNG files when a DDS is present.

Are you sure? On the same file, on the OnStart, you can find: switch (accidentRate) { default: accidentRate *= 100; break; case < 0: accidentRate = 0; break; case > 1: accidentRate = 100; break; } And this is there since the creation of the file, apparently. The accidentRate is a double, it's a KSPField filed up by a config value on OnLoad. The value for it, when defined on the config file, is from 0.0 to 1.0. Then later, on the OnStart, it's "converted" to a percentage (for example, 0.15 -> 15), and from this point I fail to see how this would be a problem. I think this "coder friend" is wrong... --- -- - POST EDIT - -- --- When accidentRate is 15, that IF will fail only when localDouble is 14 or less. Since localDouble can be from 0 to 100, in reality we have a 85% of success here. (I agree that the variable naming is bad, but the functionality appears to be working as intended - I'm guessing the author worked over a previous work where accidents were being simulated)

Guys... KSPCF is replacing DDS from 3rd parties with DXT3 ones (that KSP doesn't supports), preventing the textures from being loaded. I consider this way less than ideal - because, again, KSPCF is replacing working textures with borked ones. I found at least one trigger for the problem - if there's a PNG file and a DDS one, both with the same texture name (the filename without extension), KSP will ignore the PNG and load the DDS, but this triggers KSPCF into replacing de DDS with a DXT3 one, and we get black textured parts instead of the intended texture. Ideally you should not replace working assets, at least without a solid reason (not to mention that you should warn about the action in the KSP.log). But if KSPCF would not be using DXT3 on the process, the truth is that nothing bad would had happened. So I suggest: Log a warning when KSPCF replaces something on the GameData; and DO NOT USE DXT3 when creating textures that will be loaded by KSP. Counting with your support. === == = POST EDIT = == === I misdiagnosed the problem. KSP was masking a latent problem on the distribution (I was really shoving DXT3 files on the thing), KSPCF unmasked the problem by ignoring PNG files when a DDS is present. I stand corrected on this one - I ended up shooting the messenger by accident.

Thanks for the feedback. I don't use anything from OPT, and I really doubt OPT would use anything from KAX - so apparently OPT "fixed" the problem by collateral effect. Or perhaps something else that you had installed together OPT, but since you were intending to install OPT, you associated the fix to OPT. In a way or another, I'm giving this a peek. Thanks for the report. === == = POST EDIT = == === Opened a ticket: https://github.com/net-lisias-ksp/KAX/issues/18 Didn't found anything on the latest release that triggered the problem that bit you (DXT3 textures). I found a mishap on the package, but it wasn't the source of the problem for sure. --- -- - POST POST EDIT - -- --- @Nophallus, it's a bug on KSPCF. By some reason, KSPCF is thinking it's a good idea to overwrite KAX's DDS's with their own regenerated versions (from the PNG file). But they are doing it using DXT3 by some reason beyound me. Why installing OPT induced KSPCF to fix the problem it created it's beyound me. In a way or another, this is a bug on KSPCF, and it's beyound me to fix it. I don't think it's a good idea to overwrite 3rd parties assets as they are doing. I really think they shouldn't be doing it. And why using DXT3 at first place? KSP doesn't like it... === == = POST POST POST EDIT = == === I WAS WRONG!!! ("surprisingly"... ) The DXT3 textures are on my shoulders. KSP was silently ignoring them, loading the PNGs files instead. KSPCF change the loading process by ignoring PNGs files when a DDS file is present, unmasking the problem. So, yeah, I shoot the messenger by accident. Why OPT fixed the problem is still a mystery - but, anyway, this is something I need to fix. Ping @Nophallus

What downgrades the physics to KSP2 levels. The whole point of bending is that you are overloading the joints beyound their strength - i.e., you are building a bad designed craft that doesn't respects the limitations of the part. Without bending, your choices is to just break the joints abruptly without warnings, and let the user scratching their head trying to guess what in hell happened, or you just throw the simulation part of the game trough the Window, dumbing down it - as building a 100 meters flying stick with 1.25 fuel tanks and pretending this is a minimally realistic rocket. Admission of guilt: UbioWeld does exactly that. So much for the game mechanics.. Ubioweld was intended to cut down part count, not to create generic and reusable consolidated subassemblies. So it welds the parts for a craft in a way that it's useful for that craft, without further worries. Trying to create reusable consolidated subassemblies explodes the complexity of the solution exponentially - because someone would need to code support on the Weld Tool for every possible combination of MODULEs and PARTs. For example: You are welding 3 parts, each part have 3 possible variants. Currently, the Weld tool just ignores the problem, applying the current selected variant of each part and letting KSP trying to handle the mess. The alternative would be to create a dedicate code that would carefully combine the different VARIANTS into all the possible combinations, or 3 x 3 x 3 = 27 variants. You ware welding 2 stairs. Each stair has a ModuleAnimationGeneric tied do a named mesh from the part's mu file. So you have multiple copies of that meshes, all of them with the same name The ModuleAnimationGeneric doesn't knows how to handle multiple meshes with the same name, the WeldTool would need to find a way to create a new mesh, renamed, and then update the respective ModuleAnimationGeneric. You are welding a stair and a spotlight. Both use ModuleAnimationGeneric but for different purposes (one interpolates a mesh, other a texture) Do you want them to be animated at the same time, or you want to have many toggles, one for each? If you have a stair and 2 spotlights, do you want 3 toggles, or want to consolidate the spotlights into a single one? If you want to animate them separately, you have the duplicated named meshes problem again, and additionally. And I will not even think on talking about the Robotics. And so goes on. It's a hell of a work for too few gains in exchange - it's easier and more effective to weld the "dumb parts" together, and let the smart ones be operated as single parts normally. The real gains are on welding the dumb parts, as they are - by a mile - in greater numbers. My suggestion is to combine welded parts with "smart parts" into subassemblies if you need reusability.

<please ignore. hit Save by accident>

And then, when the site's owner scaled down the contract (probably to save some bucks, as TT2 is on a cost cutting spree), that load that until the moment were being supported by the CDN suddenly became too much... Makes sense. --- -- - POST EDIT - -- --- Corolary: the site's owner should condigure the CDN to block access from Chat GPT and similar services. There're LGDP (and my own Country's GDPR) issues to comply!

IMHO this was unavoidable, once evidences pinpointed that the franchise is headless and no further development is going to happen - there's a lot of invaluable historical content here and people are afraid of loosing it. Perhaps allowing the Web Archive to, well, archive the Forums contents (and then regularly synchronizing the contents on it) would alleviate the problem? Or, perhaps better yet, export the site into a static but functional website and let Web Archive archive the statics, and then you guys would reexport it regularly - this would allow you to have some control about what is going to Archive. You know, once people realizes that, if the worst happens, the content will be still available they will not feel the need to salvage things themselves. This will, at very best, help to keep heads cooler as that pesky 502 Bad Gateways will not happen all the time anymore, what help to worse the problem by feeding back the fears that triggered them - and we get a vicious self sustained cycle. Please consider discussing the matter with the current site's owner.

I'm unsure if I understood it correctly, but... Had you tried -EVE_CLOUDS:AFTER[StockVolumetricClouds] { } (Assuming StockVolumetricClouds is the name of the directory where it lays) The problem you will have is that it will remove ALL OF THEM, being defined by the StockVolumetricClouds or not. You can try to limit it by using :HAS looking for something that only exists by the nodes created by StockVolumetricClouds.

Well... On this installment, things looks fine: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\000_KSPe.dll ^^^^^^^^^^^ And there's no GameData/GameData in this installment neither. This log of yours is pinpoint the KSP managed directly by Steam. So it's almost sure you have another KSP installment in your rig, and CKAN is pinpointing that other one. Open CKAN and check the Title Bar to see exactly what KSP installment CKAN is using at the moment. Look on the screenshot below, it's the top line where the buttons the Red, Orange and Green buttons are - of course, in your Windows this Tittle Bar will be slightly different. I have many diferent KSP installments on my rig, the one below is the on a directory called /Users/lisias/Workspaces/KSP/runtime/1.12.5 where I develop, test and diagnose things (I don't use my "productivity" KSPs for testings, for obvious reasons! ). On yours, it will show exactly where is the KSP CKAN is using. In File / Manage Game Instances (where "instances" is just a fancy name for "copies" ) you will find a place to register and manage different KSP installations. But, at this point, I think it's best to ask for further instructions on the CKAN's thread, as - to be honest - I'm not exactly an expert on it, I'm essentially a command line guy and use it very little. Cheers!

Are you sure you are looking in the right Directory? Do you know where to find the KSP.log? Check this post if don't. Publish it on dropbox or something, and I will give it a peek.

"Helium leaks are not a reason for scrubbing a launch."

Well, if KAX works fine wihout a 3rd party mod installed, and then works bad with that 3rd party, usually the problem is that 3rd party mod. But I can try a quick check, it's probably someone mangling with the propellers textures. Can you send me your KSP.log, the MMPatch.log and the ModuleManager.ConfigCache using DropBox or similar? With a bit of luck I can detect who is doing it without having to install everything and trying myself, what would demand some more time than just checking these logs looking for the KAX textures being mangled. Cheers! --- -- - POST EDIT - -- --- Add a screenshot with the problem too, just be absolutely sure about what I'm going to diagnose!

Just found this Chicas, and boy... These gals are good!!!

A Mexican Band. These gals are great - really.

You see, they are part of the ecosystem I mentioned above, and they have expenses too. I remember someone on their github mentioning they had paid for one more year of a license for a software the project uses before leaving. Someone has to pay for this party.

Blohm & Voss P 192 This is another one of that crafts that someone needs to build on KSP! https://en.wikipedia.org/wiki/Blohm_%26_Voss_P_192 (http://www.luft46.com/bv/bvp192.html) I want to know how in hell the pilot would bail out of this death trap... (or in how many pieces...)

Please no Capitalism sucks, but the alternatives suck more. They have a successful business plan (at least, successful enough to had survived all the Studios that were ever involved in KSP development, I suggest to respect at least that). They inspect the packages for known malwares before publishing the zips also, they have a proactive curation of the library - something that we are lacking right now on the current alternatives. And this is really worrying me given the current International Relations in this Pale Blue Dot. I understand their business model distastes some people (advertising is not my favorite entertainment media, to be honest), but - and again - someone needs to pay for this party. There's no free lunch.

IMHO they are intimately related. If there's no one on top, there's a really high probability of having no one paying bills around here, and so we are flying on fumes. Who pays the bill call the shots. If there's no one calling the shots...

There's a lot of missing RESOURCEs from KSPI, but if I understood it correctly, you just want the Interstellar Fuel Switch and the WarpPlugin, I'm right? I'm reproducing your setup here and seeing what's wrong - I don't think you did something wrong, I think we are dealing with some undocumented dependencies. Stay tuned, I will edit this post as soon as I have some answers. --- POST EDIT --- @MixelFan95 Well... It's something you didn't installed. But, granted, there're no instructions about how to install only what you want from that packages. From Kopernicus, you forgot to install ModularFlightIntegrator. You want to use Interstellar Fuel Switch, right? So please download the latest version from SpaceDock here (assuming you didn't did it already) then copy the following directories to your GameData: CommunityResourcePack CommunityTechTree InterstellarFuelSwitch DO NOT copy ModuleManagerWatchDog, TweakScale, neither the others DLLs not inside a directory - they are outdated. I didn't copied PatchManager neither. To get the newest copy of Warp Plugin, download the latest KSPIE, also from SpaceDock, here (assuming you didn't did it already), then copy only the directory WarpPlugin (assuming, again, you didn't did it already), as well the DLL Interstellar_Redist.dll . By doing that, I got a KSP installment similar to yours (except by Parallax, my rig doesn't withhold it) without perceptible issues: Folders and files in GameData: 000_Harmony 000_KSPe 999_KSP-Recall CommunityResourcePack <-- Here! Note this directory! CommunityTechTree <-- Here! Note this directory! InterstellarFuelSwitch Kopernicus ModularFlightIntegrator <-- Here! Note this directory! ModularManagement ModuleManager ModuleManagerWatchDog Stock folder: Squad Stock folder: SquadExpansion TweakScale TweakScaleCompanion WarpPlugin __LOCAL Stock file: .DS_Store 000_KSPe.dll 001_KSPe.dll 666_ModuleManagerWatchDog.dll 999_Scale_Redist.dll Interstellar_Redist.dll <-- Here! Note this file! ModuleManager.4.2.3.dll ModuleManager.ConfigCache ModuleManager.ConfigSHA ModuleManager.Physics ModuleManager.TechTree [LOG 04:22:45.677] Done patching [LOG 04:22:45.677] Saving Cache <-- HERE! MM only saves the cache when everything if fine with the patching! [LOG 04:22:59.214] Done! And, since we are here, how about giving WarpDrive a chance? It looks promising.

Excellent question. Right now, this is going to be our major concern - there's a whole ecosystem (not only Forum) that needs money to keep ongoing, and we don't know where this money will come from. You know, who foots the bill is the one that will call the shots. This is not necessarily evil, but it's not necessarily good neither - uncertainty is a Sun in our Beach. p.s.: I'm afraid that, perhaps, Curseforge would be the only reliable source of mods in a couple years...