Lisias

I wondering what would happen if @HarvesteR made this announcement here, on Forum... (he did on Orbiter's one, when he announced KSP! )

I swear all my attempts to fire a archive there failed, never managed to fire up one with success - it always ended up with an error...

I noticed that rhe 502 errors have a Schedule, they usually starts at 23:00 GMT-3 and keep going between 3 and 4 hours. Maybe this is the reason? People doing personal backups? Perhaps it would be a better idea to allow Web Archive to do it? It would save a lot of bandwidth, and with Forum using the same infra as everything else on TTI, wasting such bandwidth on a frozen game at expenses of the profitable ones is surely something that will not be seen with fond eyes. Another idea would be a static export of the site into a torrent? (Assuming Invision does something like that)

I think a Mars Cycler would be the next logical step. That would cut transplanetary costs to a fraction.

This thing made me remind of this french craziness: Leduc 022. And... Yeah, the cockpit is essentially almost inside the intake!

KSP2 Crazy Train! And we already have the OST!!!

I think he's right, but I don't think this is going to happen unless TTI is forced to somehow. You see, the unpublished assets are a good bargaining chip while trying to sell the IP, because they are an potential source of incoming in the future - the new owner can try to sell them as new DLCs. An expectancy of incoming is better than nothing. Something must convince TTI that it's more profitable to them to release them now in Beta than to keep these assets close to heart as bargaining chips.

Right now, I will be happy to be alive when (or if) KSP3 is launched...

Your KSP installment is well configured, nothing is put on the wrong place. But it's missing a dependency: [ERR 07:32:21.803] AssemblyLoader: Exception loading 'MoleUtils': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.Refle at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <4b449f2841f84227adfaad3149c8fdba>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'WildBlueTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its depe File name: 'WildBlueTools, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' It's that old "friend" Assembly Loader/Resolver bug again. Something fails to be loaded, it got nuts and then screw TweakScale and everybody else that uses Reflection and/or Loads a DLL (and, as usual, TweakScale is not shy on complaining when it isn't felling well, so it ends up taking the hear! ). Install this thing: https://github.com/Angel-125/WildBlueTools/releases I think this will do the trick - unless the WildBlueTools asks for something else that it's not installed... Let me check... <hack hack slash & hack again>.... Nope, didn't found any Dependency other than Unity on the WBT source code. Install this WildBlueTools thingy and this should do the trick - if anything else blews, it's another missing dependency. Hit me here, we fix it, rinse, repeat! Cheers!

What settings? It's only a few of them, or it's everything? If only a few, it's probably my fault - tell me what's nor persisting and I will try to reproduce here and see what happens. If everything is lost, then I'm inclined to think it's something environmental. In this case, please: Send me your KSP log Tell me how you are launching the game CKAN Steam It's the launch command line the default or did you customized it? By a shortcut in the desktop Others?

KAX 2.8.1.1 is on the wild! https://github.com/net-lisias-ksp/KAX https://github.com/net-lisias-ksp/KAX/blob/master/CHANGE_LOG.md https://github.com/net-lisias-ksp/KAX/blob/master/INSTALL.md https://github.com/net-lisias-ksp/KAX/releases https://legacy.curseforge.com/kerbal/ksp-mods/kerbal-aircraft-expansion-kax https://spacedock.info/mod/2150/KAX Changes: Fixes a pretty stupid mistake I let pass trough related to duplicated textures in different formats. Closes issues: #18 There’re DXT3 textures on the distribution (errata: on the fillesystem - errata’s errata: is really on the distribution), but KSP likes DXT1 and DXT5 only Thanks to @Nophallus for the report that leaded to this fix! === update === SpaceDock was updated (I forgot to do it on the WeekEnd). I will work on a CurseForge release ASAP. === update² === Now also on CurseForge!

I have one. Have a MiniPEB (great device), some software, lots of cartridges. And TI 99 Calc. I fired up the thing, and loaded a SpreadSheet I had created for fun some years ago. Everything is still working as expected. Then I fired up Office 365. Tried to open an old Office 95 spreadsheet I found on an old backup. Bleh. The I tried to install my old copy of Office 95 so I could open that spreadsheet. Bleh. Then I fired up LibreOffice to read that damned file - now it works, but the last stable doesn't export Office formats in a way that Office 365 fully understands (graphs, advanced scripting, etc - even some more advanced text formatting), you need to have the latest LibreOffice Beta - but it doesn't support my version of MacOS anymore, and I don't want to upgrade because I will lose 32 bits support and I have lots of 32 bits applications I still rely on and I don't see why in hell I would buy everything again. excrementsification. Even on Open Source. I have this one to tell you guys: on Day Job, we are commissioning new ProxMox VM hosts to replace our VMWare, we are done with VMWare. For good. By historical reasons, our Firewall and Router are pfSense (used to be OpenSense, but when we migrated, we had to use pfSense or we would lose support from the datacenter). Well, we can live with it. The old VMware servers used pfSense 2.5.1, we installed 2.7.2 on the new (obviously). And I got screwed. On pfSensse 2.7.2 they ditched ICS and started to use KEA as DHCP server. But... KEA is still in Techonologial Preview, and it's missing a awful amount of features that ICS were providing up to 2.7.1. Yes, they broke a lot of features on DHCP from 2.7.1 to 2.7.2 - and had I mentined they shoved a Preview application on the STABLE BRANCH? Features that I was relying when I made my migration plan. Features that I need in order to have two similar environments running at the same time under the same infrastructure, and redirect clients between the environments by simple DNS magic (exactly what's KEA doesn't support). And this damned pfSense version is, allegedly, homologated by IBM to be used on the DataCenter. Now what? I'm screwed, as always. And we had paid for being screwed. The rationale is that by using anything else, we will no get support from NetGear. But I don't need support for a product that I can't use and end up relying on something else, so... Yeah. excrementsification. === == = POST EDIT : 2024-0705 = == === I forgot to mention: The 2.7.2 release notes doesn't mention the withdrawan of any features, neither that KEA is in Preview. Today I had time (and patience) to look into KEA's documentation (completely defeating the need of pfSense, that are supposed to shield me from this) and realize that KEA's missing features are, in reality, optional plugins that weren't activated when they integrated KEA into 2.7.2 (and, again, on a minor version bump). Interesting enough, KEA is a complete rewrite using C++ (using Boost, by Kraken's Sake!) and PostGRESSql or MariaDB as data back end (JESUS CHRIST!!). ISC published a migration tool, KEAMA, that supports migrating DDNS entries (one of the missing features), so I conclude that the new KEA have support for it (I'm losing my temper already, I'm still really liquided off with this stunt). In a way of another, everything pinpoints to the fact that the missing features are there on the daemon (besides hidden on some bloat - Boost and SQL, Jesus) and they just didn't activated them (neither created the GUI for them). Yeah. excrementsification.

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.