Lisias

Send me your KSP.log. Let's see what's happening in your rig.

As a matter of fact, I like the struts. We use it on Real Life™, not rarely it is cheaper (in price and mass) to use a strut than to reinforce the internal structure, like what was done on the (utterly missed) Arecibo Observatory. Look the cables tying the towers to the ground!

Whoops… Too much debugging and too few playing on my part, it appears!!! I don't remember this one, it should be some small mistake that I fixed "by accident" while updating my fork. A lot of problems on the add'on scene are not exactly "bugs", mas small mishaps on doing the "right thing" on the "wrong time" (os just don't doing it). Humm… You make me remind of something - I made a library, that I call KSPe, that allows me to automatically use CTB on my toys: if CTB is installed, it's used, otherwise it's not and no problems happens (other than not having your clicks blocked by the focused window). If CTB was updated in a way that breaks legacy, then it will break KSPe, that so will break my toys… I will investigate it. There's a trick posted somewhere in the past where you tell Ubioweld to just ignore (and rip off) the ModulePartVariant. I really don't understand why I didn't included it on the distribution… Anyway, I'm going to publish a new release somewhere in the near future (after investigating the CTB issue) with it included, but until there you can download this file and replace the one in <KSP_ROOT>/GameData/net.lisias.ksp/UbioWeldingLtd/PluginData/.

The information I have is that the Titan had 50 test drives on Marianas and pressure chambers, "including to depths similar to those of the Titanic". No figures for how many of each. https://metro.co.uk/2023/06/22/how-many-times-has-the-titan-gone-to-the-titanic-and-how-deep-is-the-wreck-18994926/#:~:text=OceanGate has previously stated that,as in a pressure chamber. So we have 50 test dives plus 90 "effective" dives, but only 13 of the later were really successful (i.e., reached the Titanic). Some were aborted early on the way, and in some they didn't found the Titanic (they reached the Titanic's depth on these ones, but far from the wreck and ended up using all the time trying to find the thing without success and aborted). And, of course, some where they aborted half way down due technical problems. I think the only way to get real information is to find the dive logs of the vehicle, but I don't think this info is available at this moment.

That's one of the few consensus I had read about it: there was only one vehicle, and not two or three to do the stress tests, like that one NASA did with the SLS fuel tank: Good question. I will dig about on the Week End and see what I find,

Frankly, using the original is a lost battle. Too many changes on too many places, I don't even remember anymore the changes I did! Found nothing obvious. Other than an annoying log spam that I'm fixing now, I didn't found any Exceptions or visible evidences of misbehaviours. Your log looks similar to mine, and the thing works on mine. I'm digging in your log to see what I get, I will edit this post as I find something (or not!) Do you know something that will help even more? Try this. — — POST EDIT — — You don't need LoadingVSyncDisabler when MM /L is installed. My fork handles this way better that it, by the way, as it ensures restoring the user settings before loading the Main Menu. At least the last time I checked, KSP applies the user Settings before starting Loading things, and then only if the user changes something. LoadingVSyncDisabler only disables the VSync without restoring it later.

Everything I had read 10 years ago were predicting that Falcon9 would never be able to be reusable on an economical way… That's the problem: we aren't material engineers, so we need to rely on what people that (supposedly) knows the subject has to say. But people lie, some of them without the slightest remorse. One blatant lie about this matter is the Carbon Fibber acquired from Boeing being unfit to be used, what could bring liabilities to Boing for selling "rot material". What people don't get is that the shelf-life of a material is not what decides if the material is unsuited for use or not, but the sum of the shelf-life PLUS the useful life of the device that was made with it. If the Carbon Fibber is good for 20 years, it was stored for 6 and Boeing wants his plane to be fly worthy for 15 years, then that material is unfit for Boeing's airplanes, but it's fine to anything else those useful life is 14 years or less. Additionally, it's worth to note that that submersible had dive 90 times. NINETY. News were noticing the thing as it was its 14th dive. So, apparently, Carbon Fibber is not exactly unsuited for the task, it have a very small life span - perhaps 50 dives, 75 for unmanned dives - and then the hull should be considered unstable and only used for suicidal missions. Another thing that may be a factor on this tragedy was exactly the use of Titanium on the semi-hemispheres of the main hull. Titanium, as any other metal, expands and contracts with the temperature while Carbon Fibber don't. Airbus is getting some heat on their A380 from Emirates exactly due this reason (the paint expands, the carbon fibber hull doesn't, and so we have delamination). It was being cogitated that there should be remains of the Carbon Fibber hull on the Titanium semi-hemispheres, where both parts are bolted together, if the hull collapsed somewhere in the middle of the ship. Since there's any, some engineers think that the failure point was exactly where the Carbon Fibber is bolted on the Titanium, and this would had happened because the hull was taking a lot of heat from the Sun while being towed - the thing used to be carried onboard on a bigger ship, probably with better shielding from the Sun - and so the titanium heat dilatation would had fractured the Carbon Fibber, weakening the material prematurely.

Send the KSP.log and I will check what's wrong on you rig.

By the Krakens!!! The Pitts Special is already a over powered machine, and this krazy <piiiii> shoves two additional jet engines??? Damn!!!

Last time I checked, it worked - but with a glitch, by some reason I didn't had time to diagnose yet, by reverting to Launch the plumes fails to be scaled back - somewhat annoying. Interesting enough, if you quit the savegame and reload it, then the plumes are scaled normaly. Didn't tried switching vessels, but I think that if you switch to a vessel far enough (so the reverted vessel got into rails), by switching back the plumes are scaled again. In a way or another, it's a known issue and will be worked out Soon™. —— POST EDIT — — For the sake of completude, I just fired up 1.12.5 with Waterfall and TweakScale. The thing is working: But still with the Revert to Launch glitch: Switching vessels don't work, the only way to fix the plumes is to switching Scenes.

You (too) got bitten by the (in)famous Assembly Loader/Resolver. The trigger this time is Romfarer. [LOG 07:22:10.566] AssemblyLoader: Loading assembly at D:\Games\Kerbal Space Program\GameData\Waterfall\Plugins\Waterfall.d ll [LOG 07:22:10.575] AssemblyLoader: Loading assemblies [ERR 07:22:11.032] AssemblyLoader: Exception loading 'Romfarer': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. 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.TypeLoadException: Could not resolve type with token 01000004 (from typeref, class/assembly ImageEffectBase, Assembly-CSharp-firstpass, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null) System.TypeLoadException: Could not resolve type with token 01000004 (from typeref, class/assembly ImageEffectBase, Assembly-CSharp-firstpass, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null) Romfarer is a pretty old add'on that as far as I know is not supported since KSP 1.2 times (more or less), so there's no other choice but to remove it from your rig. Or downgrade KSP to a version where Romfarer works, (almost) everything I maintain runs fine downto 1.7.3, some to 1.4.3 and I managed to make a very few to work too on 1.3.1 - so if Romfarer is very important to you, downgrading KSP is an option.

What have its drawbacks - besides none of them being so bad as tipping over, of course! The lower the CoG, the bigger is the distance to the top floors, and so bigger is the linear distance the floor is moving given an angular movement. (at least the piano was firmly bolted into the ground - that one would cause some damages by wandering around). So, in heavy seas, is usually better to shelter yourself on the lower floors. But they have their own problems, however: We have invented transoceanic airlines for a reason!

To tell you the true, the autostruts adds problems by their own - you have more points to calculate stress, and as the CPU gets overloaded, these calculations fail to be done in time (a simulation is a real-time computation, besides mostly developers failing to acknowledge this properly). One thing that could alleviate the problem (autostruts and also the regular joints) would be to wave the fixed 30 physics frames per second, and addint a delta-time between each physics fame update. This would allow the physics to be calculated on an arbitrary amount of "PFPS" (physics framer per second) and this, by itself, would solve about 80% of the Krakens on this game (rhetorical stats, pulled the number from my SAS - but it's not too far from my perceived reality). About the joints, a possible solution would be something as Ubioweld automatically being applied to the craft - some parts could be automatically welded together as a single rigid body, saving computation (and joints). This would work way better with the wobble being replaced by rigid bodies bending under stress. On Real Life™, we have spars and support frames, and KSP bluntly abstracted them, replacing them by the attachment points. We can track down almost all the conceptual problem we have on KSP (both on them) to this simple fact: we had replaced spars and support frames for something else, but we still want them to behave like the things we had replaced. Some compromise is unavoidable.

ANNOUNCE Release 2.1.1.13 is available for downloading, with the following changes: 2023-0718: 2.1.1.13 (LisiasT) for KSP >= 1.3.1 An embarrassing memory leak was detected and fixed. See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. Right Now. Being a simple fix release, I published it on everything and the kitchen's sink at the same time.

Well. It allows reinforcing the structure's stiffness, as a real engineer would do by reinforcing the spars or whatever is the structural workhorse of the thing. You see, KSP¹ is a Simulacrum, not a Simulator - as long some resemblance to the Real Life™ constraints is achieved, we are good. But you touched an interesting point: Auto-Strut to the heaviest part should not be dynamic, it should be set on stone at Editing time. (Not to mention the use of auto-strut should tax the user on Funds and Mass) Shove the ISS on a launch pad and see what happens. (This last argument of yours is an insult to our intelligence at best, and a intelectual dishonesty at worst).

And exactly how you intend to make it look good for KSP2? You are praising Juno:New Origins better than I could ever would be able to!!! (I didn't knew they were just 7 devs!!!) Do you have positive feedback from the Juno devs about not going to implement colonies and multiplayer? I fully agree on this one. IMHO, KSP2 should walk away from such game model, and this is the reason I'm advocating for some kind of structural challenge. KSP¹ can be way more challenging than Juno exactly because of these constraints. And for people that want to play without these constraints, there's Juno. Exactly, see my Agena video somewhere in this thread's previous posts. Interesting enough, structural abuse on KSP¹ is "punished" by the wobbling, so yeah.. KSP¹ is way more similar (or less dissimilar) to Real Life™ than Juno. So, if wobbling it set to go, it must be replaced by something else - otherwise we would have… Sugared Juno On A Golden Plate, and not a KSP¹ sucessor.

I agree. There're some on KSP¹, very minimalistic and even naive - but better than nothing. It's the auto-struts. The auto-struts can also be seen as a tool for structural reinforcement. My problem with it is it being dirty cheap - using auto-struts should tax the user both on Funds and Weight on every part affected by it. Using your ISS example (that bends 2 to 3 millimetres each 100 meters), you can bet your Slide Rule it costed NASA a lot of money in reinforcements, that by their turn taxed the whole structure with mass. But still better than nothing! Where I'm saying it does? I'm pinpointing how ridiculous would be a 220 meters, 7.5 meters wide rocket standing on the launchpad to be considered "realistic", as the people advocating for the plain removal of the wobble are telling. But since we are here, let's put your claims on check: So you have a point, but it's (frankly) irrelevant to this discussion because it didn't impeded me from doing something more or less similar from what we would do on real life: reinforcing the structures. In a way or another, my argument stands: KSP¹ behave way more similar (or less dissimilar) to Real Life™ than Juno:New Origins, the model that some people is willing to see KSP2 taking. My complain about the AutoStruts being dirty cheap, however, still holds - reinforcing the MK0 parts should had taxed me on Funds and Mass. Perhaps, but so what would be the difference between KSP2 and Juno:New Origins? Real differences, not the sugar coating that rich game publishers use to make up simple, lousily designed dumbed down games. — — — — It essentially boils down to what kind of game we want: a KSP¹ sucessor, with the building challenges improved; or a glorified, sugar coated, gold plated (and way more expensive and buggier) Juno:New Origins clone. (that Lego versus Modelling Dough paradigm I had talked about). On a side note, Juno:New Origins is already on the market, it's cheaper, it's fun enough and it runs perfectly fine on my current rig (not to mention being way better reviewed on Steam - they just released an update with propelled craft, by the way!!!). If KSP2 is going to be a Juno rip off, why bother buying it and still wait months and months until be able to play it?

And that's the difference between a "Modelling Dough" model from a "Lego" one. You need to respect the bricks limitations, otherwise where would be the challenge? On KSP2, for sure! I find hard to believe that people really want to dumb down the game to the point in which a 7.5M wide, 220M tall rocket being able to even take off is… "realistic". That damned thing would not even manage to get on its feet on real life, what to say take off????? Where is the "STEM promoting" thing of the game?

ANNOUNCE Release 2.4.7.2 is available for downloading, with the following changes: A new Feature was introduced that automatically deactivates the Auto Scale and the Chain Scale features every time the user enters the Editor, creates a new Craft or loads one. Aims to minimize support tickets opened by users that forget the features active and then thinks it's a bug on TweakScale Default is On, can be turned off on the TweakScale Settings dialog. Updates KNOWN ISSUES with workarounds for the following Work In Progress bugs: #297 #283 Updates MMWD to 1.1.1.1 Now and then an User opens a Support Ticket about an issue on TweakScale that, in essence, it was the Auto Scale or the Chain Scale forgotten active. Since this is happening with some frequency, I decided to code this Feature. Now, every time the user enters the Editor (VAB or SPH), or clicks on the "New" button, or loads a craft, all the TweakScale features are reset to disabled - unless the user unchecks the respective option. This dialog, as usual, is available by clicking on the TweakScale's button on the Toolbar: When scaling is available, and no features are enabled. When scaling is available, and at least one feature is enabled When there's no TweakScale support for the last part you selected (or opened the PAW). Know Issues https://github.com/TweakScale/TweakScale/issues/297 Under a certain, more or less convoluted, sequence of movements on a Part, TweakScale starts to misbehave the placements of cloned parts of such convolutely edited part. It's a pain in the SAS when it happens, but the work around is simple enough: instead of Alt+Click the displaced part, take a new one from the Part's Palette. I intend to fix this (it's a bug on TweakScale for sure), but I will priorize some TweskScale Companions first. https://github.com/TweakScale/TweakScale/issues/283 This one is a crappy one. When scaling parts with resources under symmetry, only the "original" part gets its resources scaled correctly, the cloned ones get the prefab values. This is unrelated to the previous one, by the way - the reason this is happening is completely different, I checked it. However, by saving and loading back the craft, or by launching it from the Editor, the values are "fixed" - this strongly suggests that TweakScale is doing its job right on this one, and since this started to happen only on KSP 1.11.x (I tested only 1.11.2 and 1.12.5), the matter is settled. HOWEVER The freaking bug vanished while I was Smoke Testing this release. Kraken knows why, I'm currently clueless about the reason the problem is "fixed" I don't even know how and why, but I had updated some other add'ons that were smoked tested together. Anyway… Let's see what happens on the field.. Your Attention Please Due a major screw up of mine (hate you, Windows!!), you will need to manually remove the following files before updating - unless you install things manually, when you will overwrite them anyway! <KSP_ROOT>/GameData/666_ModuleManagerWatchDog.dll Disclaimer By last, but not the least... This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right Now. SpaceDock. Right Now.

ANNOUNCE KSP Recall 0.4.0.2 on the Wild, featuring: Implements a missing use case from TweakScale, OnPartAttachmentNodesChanged. Updates MMWD to 1.1.1.1 Your Attention Please Due a major screw up of mine (hate you, Windows!!), you will need to manually remove the following files before updating - unless you install things manually, when you will overwrite them anyway! <KSP_ROOT>/GameData/666_ModuleManagerWatchDog.dll — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Right Now. SpaceDock. Soon™.

Fantastic! Source:

This is a NOTAM about a NOTAM About the problem reported by @AccidentalDisassembly here, I just found that if you keep the scaling parts' PAWs opened (clicking on the pin), then all parts scales all right! I'm guessing we have yet another new race condition on the Editor (between the numerous ones) (from KSP 1.11.x and forward), and the PAWs being active probably injects some delays somewhere and then the Kraken damned screwing code from Editor "loses" the sweet spot and don't screw up TweakScale anymore - as a matter of fact, it's possible the thing is screwing with KSP-Recall, undoing whatever TweakScale was did on the cloned parts. Saving and loading the craft "fixes" the problem. Launching directly from VAB ends up with a valid craft on the launch pad - at least using Stock parts. https://github.com/TweakScale/TweakScale/issues/283 Still working on it. Additionally, I think I diagnosed the problem also reported by @Krazy1 here, and formalised on https://github.com/TweakScale/TweakScale/issues/297 . When you clone a Part, the attPos is not "refreshed" from the prefab, but used as is. This affects the calculation of the attPos0, but TweakScale uses the prefab as reference to rescale things. The difference between the cloned attPos and the respective prefab appears to explain the end result. Still working on it².

Please send me your KSP.log. Without it I'm on the dark! Wait! Did you have the "Enable Auto Scale" option active, link on this image? If yes, we found the "problem": deactivate it and I think you will be fine! If you have the problem even with all the options above UNCHECKED (ie., deactivated), then we have a problem. Send me your KSP.log and I will inspect it!

TweakScale scales everything - including the bugs!!

Yes. It's not a good idea shoving experimental/unofficial forks of something that CKAN handles. Speaking frankly, CKAN is already prone to borkage on updates if you do everything by (their) book, replacing CKAN managed packages with "alien" ones is a certain path to disaster, unless you really know what you are doing - but, then, you would be probably handling your GameData without CKAN...