Weird problem when launching heavy crafts when there's a Inventory part (SEQ9), a cargo part (Service Bay) between the heaviest part and the root part when the root part is crewed! #162
Labels
Milestone
Comments
Lisias
changed the title
Lisias
changed the title
Lisias
changed the title
|
I wonder it's something related to auto-struts? There must be a reason to wheels be involved on the mess... |
|
UNBELIEVABLE... JUST FSCKING UNBELIEVABLE!! I rebuild the same craft from scratch, using a 1.11.1 created savegame. And the Kraken damned thing works fine.... (sigh)
Craft file: |
|
I copied the old craft into the new savegame, and it exploded as... "expected". Then I copied the new craft into the old savegame, and it worked fine!!! There's something wrong on using KSP 1.10.x crafts on KSP 1.11 !!! My guess? Something missing on the upgradepipeline.... |
|
Marking it as "Not my fault" for obvious reasons. |
|
Current known work arounds:
|
|
Well, a setback on my hypothesis of this being something 100% KSP related. I made this monster on KSP 1.10 and loaded it on KSP 1.11: Craftfile: And the damned thing worked fine on the spot: This is not straightforward as I was thinking. Apparently, vanilla KSP is not suffering from problems on loading previous version's savegames and files, add'ons must be present somehow on the process. I still think this is not something specific to TweakScale as I could reproduce the problem with TweakScale uninstalled, but apparently having it installed at some point triggered the problem, and once the problem is triggered, having TweakScale installed or not doesn't matters. I'm heavily inclined to pinpoint the upgradepipeline on this - having TweakScale present triggers the problem, even when the parts are not scaled (see previous tests). But if you never installs TweakScale, the problem is not triggered and so nothing bad happens. My current (updated) hypothesis now is:
WHY the craft is being placed at PQS ground level on unpack? Good question. Looking into how World Stabiliser works, my guess is that KSP always unpacks grounded crafts at PQS ground level, and them immediately looks for colliders in order to move the craft above them. By some reason, heavy crafts are not being moved in time, and then the physics engine kicks in and BADABOOM. The way Vessel Mover behave on the affected crafts supports my hypothesis: such craft when spawn are placed into the ground on a excruciating slow speed (one meter each some seconds), what I think is a good explanation by the problem I'm describing. Finally, the move of the craft should be getting hindered due something wrong when some module is initialized, perhaps an empty try catch - and this by some reason renders the craft infinitely heavy, taxing terribly the code that moves the craft into the right spot after being unpacked. My goal, now, is to determine exactly what module is borking up - there should be a reason for the problem happening only when the craft have wheels, the root part is crewable and there's a SEQ and a Service Bay between the root part and the heaviest part. |
|
Possibly similar problems reported on Forum: |
|
The upgradepipeline hypothesis was wrong. I just KDIFFed the Mark2Cockpit, ServiceBay.125.v2 and cargoContainer parts looking from something wrong and I found that these parts are virtually identical on both files (the one those crafts blows up, and the one with the rebuilt craft that works).
Whatever is the problem, it is somewhere else.... (Interesting info available on this post on forum) |
|
Well... back to square one. Let's try again. This is a KSP.log exercpt from the *sucesfull craft file: I just launched the (good) craft, and reverted to the Editor once the thing didn't exploded. Now follows the same for the (bad) craft file (once the craft exploded, I reverted to the Editor): |
I was intuitively on the right path, I think. It's a fact that moving the SEQ9 and ServiceBay out of the path between the (crewed) root path and the heaviest part "fixes" the problem. And it's a fact that by removing the wheels, the ICA doesn't happens. The detail I missed is that every wheel is autostruted into the heaviest part. So the first chain on the chain of events that leads to the ICA is the wheels, finding its way into the Heaviest Part. I'm guessing that in order to reach the Heaviest part, the Wheel's code needs to start on the root part. And this closes the link I think:
So, whatever is blowing up at first, it should be on the autostrut code that finds the heaviest part. On a wild guess, perhaps there's something wrong on the Inventory Module and Cargo modules? Perhaps this mishap is being triggering by the order in which the parts are searched? Or perhaps by the order in which the Life Cycle callbacks are called, and the we have a race condition? |
|
Well, something in common with the affected part is the use of the ModuleInventoryPart. It's essentially incompatible with ModuleCargoPart (as Cargo is removed from parts that have both). So I decided to try something: I removed the ModuleInventoryPart from all parts of the game to see if something changes on the bugged craft. Well... On loading the craft, the GUI became unresponsive for the most part - I could not load, launch, make a new craft or even leave the editor, as these buttons were disabled. Looking on the KSP.log, I found it being spammed with what follows: This may corroborate my (new) hypothesis with something wrong with ModuleInventoryPart - there're hardcoded support demanding it on some parts of KSP (bad move, if you ask my opinion). So it's perfectly possible that some hardcoded support is failing to handle some borderline situation (still to be detected) and causing the ICA. It worths to mention that one of the triggers for the ICA ie having a crewable part as the root part. Yeah, it's a guess and it may be just a coincidente - but at the moment, it's the best guess I have. Now I need to figure out a way to test this properly... |
|
Oukey, another shot into the water. I used this patch to remove PartModuleInventory from the parts I used on the Bugged craft file: But the ICA is still happening. Hardcoding support for |
|
Removing ModuleCargoPart and ModuleCargoBay from the used parts didn't improved the situation neither. I will keep butchering these parts to see what I get. |
|
Removing crew support from the Mark1 Cockpit didn't improved the situation. DAMN. I'm running out of options... |
|
On a side note... In all these years in this vital industry, is the first time I noticed that the Mk1 Inline Cockpit is called Mark2Cockpit on the config file.... =P |
|
Aw, crap... Let's go nuclear on this shit. And, nope. It didn't improved the situation. Whatever is going on here, it's not related to crew or any module. I being able to solve the problem by NOT using a crewable part it's probably due a coincidence - the affected parts (Mk1 Cockpit Inline and Mk1 Crew Cabin) have this problem and they only happen to also have crew.... |
|
Well, back to square one again. Modules and Crew are not part of the problem. POINT. I reduced the affected parts to be essentially Meshes with Mass, Colliders and Attachment points (and resources when available), and yet my bugged craft file insists on blowing up on launch. Humm... Resources... |
|
Nope, removing resources from the affected parts didn't improved the situation. |
|
Oukey, now really back to square one. What we know to this point:
Referencing the KDIFF3 screenshot here for convenience:
Obviously, the order in which the parts are listed on both files also differs, but I reordered the bugged craft to mimic the working one, and it didn't improved the situation - so the order of the parts on the file appears to be not an issue here. The remaining options are the values mentioned above. One (or more) of them are the cause of this problem - they must be injecting some problem on the code that looks for the heaviest part triggered by the wheels. |
|
HA!!! Gotcha! it's not a problem on importing crafts from previous versions, it's a problem on the KSP that it's affecting all versions - but the problem is manifesting itself at different times on each KSP release!!! :D I simplified the craft to the minimum where the problem is triggered - disregarding functionality or purpose. The following posts will depict each use case! |
|
** For the KSP 1.10 made craft** This is how the craft made on KSP 1.10 ended up: And this is the very same craft made Ok to work on 1.11.1! To make things easier on KDIFF, I repositioned the LargeTank to be on the same line of the Bugged version. And this is what KDIFF tells me about the differences: On the whole file, the only difference on the parts are small variances on the This is the second relevant set of differences from these two files: Only minor "cosmetic" differences are present on the LargeTank part ( The source of the problem appears to be on the strutOcto's faulty config: good config: On a wild guess, we can't have wheels and heavy parts together on the octoStrut.... |
|
Now I'm going to check the craft remade from scratch on KSP 1.11.1. This craft file works fine as is on KSP 1.11.1: Then I just moved the LargeTank on the hear octostrut as I made on the "bugged" craft file: To make things easier on KDIFF3, I mangled this file to make the LargeTank be on the same line of the original craft file: Simplified Craft Ok 1111 Still OK.craft.mangled.zip Interestingly, this thing still works! KDIFFing both files revelated only the obvious: the So I decided to try to break this craft file again, and came to this: And the thingy blew up on an ICA! This is the "OK" file with the front wheels removed. Yet more interestingly, by removing the front wheels from the "Still OK" craft file, ICA doesn't happens!! But by reverting to Editort and then moving the LargeTank back to the front octoStrut, we have ICA again! And I think this settle the matter! My last hypothesis has proved wrong, the problem doesn't happen by having Wheels and a Heavy Part on the same octoStrut. The problem happens by having wheels somewhere, and having a heavy weight on the octoStrut nearest the root part! |
|
Well, we have a deterministic way to reproduce the problem on two different craft files. Besides having the same vessel, the different from the two different craft files is the order in which the parts were cloned and attached to the craft being built. I don't remember the order I used on the original one I made on KSP 1.10.x (I think I started with an octoStrut....), but I'm pretty sure that when I rebuilt the craft on KSP 1.11, I built it "on the right" order:
The key is the root part - by some reason, rerooting the Made Bad craft to the LargeTank, fixes the ICA! I tried to reroot this craft to the noseCone, that worked before but this time didn't - the ICA was still happening with the noseCone as root part. |
|
Marking this as unrelated, as I zeroed the problem inside KSP's attachment code. Something is not working properly when heavy parts are being placed on octoStruts under certain conditions. |
|
This is to remind me to keep an eye on this issue on bugs.kerbal: |
|
Interaction with the same vessel parts appears to do not play a role on this bug.
I think that the issue 27194 may be misdiagnosed. Or perhaps, happening on a very specific set of parts completely unrelated to my issue. |
|
Moving this one to the 2.4.9.x series, following the ROAD MAP. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
So, I came to this craft:
It was working fine on 1.10.x, but on 1.11.0 (and now on 1.11.1) the thing is just blowing up while being launched.
Instantaneous Craft Annihilation - ICA .
Further tests revealed that the craft is being placed at the PQS ground level nevertheless having something with a collider below (the runway, the launchpad, anything).
World Stabiliser does not helps.
Using VesselMover to spawn the craft solves the problem, however. But if you change the focus to another vessel, when returning to the problematic one the craft blows up again - as long it's over the runway, the launchpad or any other static with collider. When the craft is over the PQS ground, ICA does not happens!
So it's not something happening on spawning the craft, but when changing the focus to it (what happens at launch, by the way!).
I simplified the craft to what follows:
This craft as is blows up. However, I realised that:
On the example below, the root part is the Nose Cone (and this vessel does not ICA):
By removing the SEQ9 part, ICA doesn't happens even with the MK1 Inline Cockpit as root.
By removing the Service Bay 1.25 part, ICA doesn't happens even with the MK1 Inline Cockpit as root.
By replacing the Mk1 Inline Cockpit to any crewed part, ICA do happens! The part doesn't needs to have control (a probe part works fine), the problem is with crewed parts.
By removing the Ore from the containers, the weight goes from 130tons to about 30. And the ICA doesn't happens
By moving the SEQ9 and/or ServiceBay to be after the heaviest part, ICA doesn't happens.
By removing the wheels, ICA doesn't happens.
By creating a somewhat similar craft without using TweakScale, ICA doesn't happens.
So, this is the Modus Operandi:
Craft file:
Ore Train Bug.craft.zip
The text was updated successfully, but these errors were encountered: