Lisias

U2. Nuff Said...

Yep. These are some pictures of the sister fuselage I found on the web: Source: https://www.mirror.co.uk/news/world-news/worlds-biggest-plane-finally-finished-17654724 Source: Google Image Search. There's still a lot to be done, but there's also a lot already done. I found somewhere on the net that 70% of the works is made, but that completing the remaining 30% can cost near 500M USD . The surviving parts of Mriya may help to mitigate a bit that cost - some hydraulics, engines, all the rear fuselage thingies. The Cockpit and avionics are pretty expensive, however - and these ones are a complete loss on Mriya.

Because otherwise add'ons that relies on the correct PartModule's life cycle to work will not work. I think you are completely equivocated about the source of the problem. Editor Scene (VAB/SPH) is broken, not Recall. The problems Recall was getting was due trying to correctly FIX the Editor problem at hands, what took some time as more than one time I misdiagnosed the problem - it took time to finally understand where the major screw up was made on Editor's code. Since you appear to be not familiarised with the problem, let me help you on the matter: On KSP 1.9 development [EDIT: nope!!! See the notes on the foot of this post!] cycle something got royally screwed up on Editor. The parts' Position and (allegedly , as I have reports but didn't reproduced the problem myself) Rotation are not being initialised when loaded on Editor if the root part of a craft (or subassembly) is not a variant one, and it is followed by another part without variant. When the root part has variants, nothing bad happens. When the root part does not have variants, but the part immediately after has, the problem does not manifest. But I'm guessing that whoever was in charge of fixing the problem never realised the root problem, because the solution Squad choose to implement was to simply OVERWRITE all the respective data using prefab as reference - completely screwing up everything and everybody that would be doing things right while changing these positions on a custom PartModule. This overwrite happens after loading/duplicating the craft [outside the normal PartModule's Life Cycle], so there's no clean way to overcome the problem, and the net result is this stunt obliterating any Position (and maybe Rotation) related data processed by every OnLoad handler of every custom PartModule. So, and this is another trick that cost me a lot of time to cook, the fix should not only inject back good and valid values while loading the craft (and so, PartModules' OnLoad handlers would have access to good, valid values), but also needs to inject back again these values on the first Update cycle - to overwrite back good values that were overwritten by the stunt after the craft was loaded. The whole (painful) process for developing a proper solution, now implemented on KSP-Recall, can be found on the following issues: https://github.com/net-lisias-ksp/KSP-Recall/issues/32 https://github.com/net-lisias-ksp/KSP-Recall/issues/34 https://github.com/net-lisias-ksp/KSP-Recall/issues/35 Fell free to ask any questions about the problem, if the information above is not enough. — — NOTES 2022-0926 — — It was (finally) realised on the current last release of KSP-Recall that the problem started to happen on KSP 1.4.3 (most probably on 1.4.2, but this one was so short-lived that for practical effects, 1.4.3 is the one) with the first implementation of the ModulePartVariants. It took me some time to respond on TweakScale, where I ended up forcing my hand on everybody else solving things my way. On KSP 1.9.0, another side effect of the same problem was detected on the new implementation of ModulePartVariants, and I wrongly understood it as a new problem. Only recently I finally correctly diagnosed the root cause of the problem - and only even more recently I correctly understood the whole problem: ModulePartVariants is flawed since forever.

There's one more reason that may help raise interest on bringing the Mriya's sister hull into operations: the current global shipment logistics are a mess. Lots of cargo ships were decommissioned and dismantled on the pandemics, many logistics operators gone bankrupt. Some industrial and commercials supply chains are operational nowadays only due aerial transportation - expensive, but better than break the chain. There're significant repressed demand for logistics already, and any special cargo demand is competing with the rest of the World for the available options. Any cargo that could only be transportated by Mriya (by weight or by volume) may not be econonimically viable by multi-modal nowadays. Raising the funds and securing manufacturing installations for the sister hull will be a hell of a challenge in the next years. But so is being the rebuilding of the World's logistics to the pre-pandemics level. It's weird, but I think there're better chances of building Mriya's sister now than if Mriya had crashed before the pandemics.

Well… It's hers the records of the biggest cargo load and the biggest single item load: ~560K pounds and ~420K pounds (250 and 190 Metric Tons). The range for a 200 tons payload is about 4.000 KM (but can ferry up to 15.400KM!!!) So, if you have many cargo itens weighting 250 tons, now you will need to hire smaller planes to do the job. The biggest planes after Mriya are, in order: Super Guppy - 24 tons, 2300 KM range C-5 Galaxy - military, not available Boeing DreamLifter - 184 tons, 7800 KM range AN-124 - 165 tons, 3700 KM range Source: https://www.popularmechanics.com/flight/g17805179/worlds-biggest-planes/ Supper Guppy is big, but carries light cargo only. C-5 is military. So we have DreamLifter and AN-124 to do the job. But none of them can carry a 190 ton cargo, so anyone in need to transport such an huge cargo will need to do it by ship - what can be a problem if the destination is way inland. Anyone on need to ship "door to door" this kind of cargo is screwed, there's nothing today that can do such a job. This poor stand-up guy will hire a ship, will deal with port loading/unloading, the huge time needed to travel from port to port - and still will need to find a way to transport that huge cargo from manufacture to port, and from port to destination. The costs piles up, I don't know even were to start to calculate them… For the jobs that still can be done, you will need to split your cargo on smaller planes. You will need to hire two Dreamlifters, or two AN-124 . The cost per hour of the DreamLifter and AN-225 is/was about 30KUSD/hour. Didn't found easily the price for the AN-124, but it should be near it. SO… Now you will pay TWICE the price you would pay before to transport 250 tons of cargo. And this is for the plane only - you will need to pay for airport services, for airspace crossing fees, everything - all in double. I had read that it's usual the total cost for operating an AN-225 flight was ~1M USD. Well, assuming you can split your cargo, you now will pay 2M USD for the same job.

Beautiful building, beautiful instrument, beautiful music, beautiful… Uh… Never mind.

The prize would be to much expensive for non USA residents - not to mention potential legal problems on allowing non USA citizens on some facilities that may be considered sensitive nowadays. May I suggest a hashtag for Hors Concours entries? Ok, we would be out of the competition, but it would be fun to participate anyway!

Well, you will loose the modules' features. Since you are playing luna multiplayer, I think you don't mind Funds. So you can remove Refunding for sure. The "cleanest" way is to to add this patch somewhere in your GameData: @PART[*]:HAS[@MODULE[Refunding]]:FINAL { !MODULE[Refunding],* {} } @KSP-Recall { @INSTALLED { @Refunding = false } } And the quickest&dirtiest is to plain delete the Refunding.dll (or the respective CFG file) . However, AttachedOnEditor is needed while Editing the crafts. Removing this Module will render your Edit Scene experience a hell. You can't even load a craft on Editor without risking this kind of crap when AttachedOnEditor is not installed (see the red arrows) However, if you are not going to use the Editor on your gaming, you can get rid of AttachedOnEditor the same way: @PART[*]:HAS[@MODULE[AttachedOnEditor]]:FINAL { !MODULE[AttachedOnEditor],* {} } @KSP-Recall { @INSTALLED { @AttachedOnEditor = false } } Or bluntly deleting AttachedOnEditor.dll (or the respective CFG file) . You can try to avoid triggering the Editor problem by avoiding starting any subtree with a part without variants, or by adding a part with variants immediately after the part without on the subtree (including the part you use for an Alt+Click). For craft files, use that rule for the root part - always start the craft with a part with variant, or add one immediately after the root. Note the on Flight scene this problem just doesn't happens, it's a very bad mishap on Editor only. There's yet another craft file size saving mechanism that it's going to be useful for you: the "Stealth" save. It will remove the TweakScale config section from every part not using TweakScale while saving the Craft file - the Upgrade Pipeline thingy will add it back when loading the craft into memory. (it doesn't affects SFS files, just .craft files). To activate the "Stealth" save feature, add the following patch to your GameData: @TWEAKSCALE:NEEDS[TWEAKSCALE] { @FEATURES { @AllowStealthSave = True } } Someone once reported that this may screw up some less than ideally coded Add'Ons that blindly relies on the module's position on an internal KSP data structure for working - the KSP Upgrade Pipeline will inject TweakScale back into the craft, and this (allegedly) may reorder the index of the module on the config file, changing its index on memory once loaded. I never managed to reproduce the problem myself, but since the report made sense, I choose to deactivate the Stealth Save by default. Since you have a very compelling reason to have it activated, I think it worths a try. It may reduce considerably the size of your craft file. Can you explain the reason? With a bit of luck, I may think on a stunt or two for further pursue the goal! Cheers!

The last information I had is that the second hull was about 70% complete, and about 460M USD were needed to complete the remaining 30% (the most expensive part are engine, avionics et all). At that time, it was not economically viable to invest such money, as there was not enough demand in the World for two AN-225. Mriya is gone now, but the demand is still there. Right now, I think it's unlikely that the second hull would be completed anytime soon, but it's not a pipe dream to have it eventually built neither.

As it appears, I was wrong about the nosecone being "popped" out by an explosion. It looks it just fell from its place, probably by the structure where it was attached being melted by fire. (uh, somewhat strong image for aviation lovers on the spoiler) I don't know why the nosecone survived the heat. I suspect the missile used was an incendiary, not an explosive one. The front landing gears appears to be there too (obviously, without the rubber). So the floor structure appears to had survived too. And, so, the main landing gears should had also - and these two facts explains why the tail looks fine and on the right place and attitude on the pictures on the previous page). So the missing metal sheet from the hangar's roof were due the rapid expansion of the air while the incendiary ogive started to burn - less intense than an exploding ogive, but intense enough to make sheets of steel to detach the roof's structure and fly away. With the (her) left wing intact and most of the main fuselage too, I think there's enough parts salvageable to help a bit building a new AN-225 using the sister hull. Not a big consolation, I admit. But something - better than nothing.

Overland Octoauto . Being Kerbal since 1911! https://scoutlife.org/features/20899/the-16-worst-cars-in-history/attachment/1octoautoweb-2/

Good catch. [snip] 'Lucky' strikes do exist, sir. I never said the missile was targeting the wingbox, only that I though it had hit it.

Humm… I was wrong on the (her) left wing (right one from who is seeing her from the front). This wing appears to be intact, so that "tilt" I thought I had saw on the nacelle was a misperception. The wingbox appears to have hold pretty well, otherwise the surviving wing wold not be there in its place. So the missile should had hit her slightly ahead of the wingbox, apparently more to her right - severing the respective wing's attachment to the wingbox. Perhaps enough parts had survived to speed up the building of the other fuselage.

Well, this image: Suggests the hit happened inside the hangar. It appears to the be Mriya's hangar, by checking the landmarks. Granted, the root of the explosion appears to be the tail, what we had evidences from other pictures is intact. But the smoke on the roof appears to be more or less in the right place. I'm guessing the missile's trajectory was more or less what's depicted below: (I don't think I managed to draw the trajectory accurately) I think the nose was blown away from the fuselage by the explosion, as a cork popped from the bottle. I don't think you can see the fuselage from this photo. It appears to me that there's no fuselage at all from the nose to the wingbox. The wings appears to be detached from the main fuselage, besides not being flat on the ground (I think they are superficially attached to whatever is remaining from the hull): The engine necelle appears to be tilted, suggesting the wingtip is resting on the ground. If I'm interpreting the image correctly, the wing box appears to had been destroyed. But this is where the wings are connected to the main fuselage, these are the strongest parts on the entire aircraft, being the reason I think the missile hit her more or less on this part of the craft - what also explains the nosecone being popped up from the fuselage instead of being consumed by the flames.

The left wing is leaning to the left. The right wing is apparently leaning to the right, and twisted. I think the missile hit her on her shoulders and broke the wing box. The front fuselage is not visible due smoke and shadows, and I'm pretty sure the nose is detached from the hull. Since the tail's stabilisers appears to be fine and not leaned at all (on the picture I posted), I think it's reasonable to conclude that or all main landing gears are OK, or all of them collapsed. — — POST EDIT — — Additionally, this is a screenshot from a moving picture made on a mobile, the framing is way far from perfect, the guy appears to be walking - so if you look to the ground carefully, you will note that the whole image is learning to the rigth, what makes the hangar and her remains look to be leaning to the left. Yep. But the wings are attached to the fuselage by the wing box, and this one is pretty solid. Since the engines are not on the ground, the wings should still be superficially attached to the main hull somehow. What means that the fire may not had spread towards the tail and wings.

If the nose is relatively intact, and the tail appears to be too, as this picture suggests: source: https://aeroin.net/imagem-por-novo-angulo-mostra-cauda-do-antonov-an-225-no-hangar-atingido-na-ucrania/ Then the missile hit her approximately on her shoulders. Apparently no secondary explosion due the fuel in the tanks igniting, but I think the cockpit was burnt or blown up in pieces in the process. I think I recognised two of the engines still in their places (at least one for sure), so at least the wings (or part of them) appears to have survived. However, the position in which the engines are pointing suggests the wings were violently detached from the main hull by the explosion. I hope some chunks of the fuselage were spared, the tail on the picture above suggests the rear fuselage my be intact, perhaps the main landing gears may still be there. But still the damages appear to be substantial…

Found it! [LOG 03:10:51.950] Load(Assembly): /999_Scale_Redist [LOG 03:10:51.950] AssemblyLoader: Loading assembly at C:\Kerbal Space Program\KSP 1.12.3 Modded\GameData\999_Scale_Redist.dll [LOG 03:10:52.027] Load(Assembly): MagicSmokeIndustries/Plugins/Scale_Redist [LOG 03:10:52.028] AssemblyLoader: Loading assembly at C:\Kerbal Space Program\KSP 1.12.3 Modded\GameData\MagicSmokeIndustries\Plugins\Scale_Redist.dll Remove the GameData\MagicSmokeIndustries\Plugins\Scale_Redist.dll file. Cheers!

It's not how Unity works. The nyan cat should being drawn on the Update callback, and every thingy you do on the Update uses time, delaying the next Update. It's the whole problem with stuttering on Flight with big crafts or clumsy input responses (as Unity uses the frame cycle to read the HMI devices). If the nyan cat is not running smoothly, it's because the Update cycle is overloaded. If the Update cycle is overloaded, everything else on Unity relying on the Update cycle is delayed - including the KSP loading, as the assets are loaded on the Update callback! It's the whole purpose of setting the Application framerate to -1 (infinite) at first place!!

Try sliced melanzana baked on olive-oil and garlic. You can even replace the pasta with it - besides intercalating pasta and melanzana is better IMHO!

Uh, wait… This means that the nyan-cats can slowdown the KSP loading?

ANNOUNCE KSP Recall 0.2.2.2 is on the Wild, featuring: Reworks: #35 AttachedOnEditor is not working for SubAssemblies. Handles some missing use cases that I let pass trough last release: Unleash the AttachedOnEditor's fury into every surface attachment (only radial were being handled before) Also recovers the attachment's rotation I'm not sure if it's needed, as I didn't managed to reproduce the problem - but I had reports that suggests this can fix their problem. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. Will not be updated. SpaceDock (and CKAN users). Will not be updated The rationale is that I'm not convinced I really need to handle one specific use case, and want to check the solution first with the early adopters before releasing it into the wild. 0.2.2.3 was released, deprecating this one.

Since KSP 1.8 (IRRC) there's code on KSP that prevents me to scaling up the Crew capacity, but KSP was still allowing me to scale the Crew capacity down. What you are describing is, apparently, something going wrong with the CrewCapacity scaling. Weirdly enough, I detected this behaviour right now while playing with KSP, and was trying to diagnose the problem when this thread came to my attention - saving me some work! Thanks for the report. I already have a KSP-Recall release scheduled for today. After releasing it, I will pursue a fix for this problem. However… The fix may be revoking TweakScale for crewed parts. Unless I have a bug on TweakScale's code related to Crew Capacity, this may be related to KSP trying to prevent TweakScale from scaling this attribute. But I'm guessing right now. I will come back to soon ASAP. — — EDIT — — It's not TweakScale!!!! I made some tests using Stock crewed parts and all of them worked fine! There's some parts that are causing the problem, I don't know why yet. Right now, I detected that SXT's KN-225 "Osaul Payload" Cockpit has this problem, but other's SXT's cockpits have not!!! Please send me the craft file where the problem happens. I want to compare your craft with mine to see if I detected something different from the working parts and equal to the Osaul Payload Cockpit that can hint me about the problem! In time, I reproduced the problem using Osaul Payload Cockpit on KSP 1.7 3 and KSP 1.9.1 - so this is something not exactly new… o.O

Let me fill you about what's happening. On KSP 1.9 (yep, that long), something got screwed up and I think that Squad decided to workaround the problem by brute forcing data from prefab after loading the craft. This royally screwed up TweakScale and anything else that needs to change the part's attachment positions. Worse, as you detected, it screws up also Alt+Clicks (duplicates) and SubAssemblies once you try to workaround the Editor's workaround. Originally I had brute-forced my way on TweakScale, but by doing that I "solved" the problem for me but started to create problems for other people. So I decided to really understand the problem and tackle it down on KSP-Recall. What you are seeing is the consequence of a partial fix, as by some weird reason I didn't detected that parts on mirrors would be suffering from the problem (I applied the fix only for radial attachments!). I'm cooking a new KSP-Recall release with this fixed today. In the mean time, I have a reasonable work-around for the problem (to tell you the true, I'll teach you how to to trigger the Editor's bug): 1) Never start a subtree with a part without variant, unless it have a part with variant immediately attached to it. or 2) Always start the subtree using a part with variant. In essence, the Editor's bug is that it's bluntly ignoring attachment's positions (and rotations, as I was recently told) when the subtree you are Alt+Copying or loading from a SubAssembly (or craft file) have as root part a part without variants followed by another part without variants. And this appears to be exactly the case you are suffering right now. Yep. I didn't forgot. I'm working on it. — — POST EDIT — — There's a new release for KSP-Recall with (hopefully) the correct fix for the problem. It's currently in "Early Access" because I'm not sure if this fix will really fix everybody problems. I kindly ask for people willing to try it in advance to report any mishaps. Cheers!

Just felt the need for playing KSP, remembering better days. Craft is not mine : https://kerbalx.com/FahmiRBLXian/Antonov-An-225-Mriya-Cossack-w-Buran

Iron Maiden, Flight of Icarus His eyes seem so glazed As he flies on the wings of a dream Now he knows his father betrayed Now his wings turn to ashes to ashes his grave Fly, Mriya, fly Now you are flying high as the Sun