MacGyverNL

Thanks for looking into it regardless -- I'm honestly not asking for a fix, just trying to understand the behaviour. If there's apparent shenanigans going on please don't spend any time and effort here. Pad aborts are such a niche thing anyway, as long as I have some way to predict what happens I'm fine with it. If that means I have to manually stage the parachute after the abort, so be it. All that being said, should anyone be interested in digging, I did some additional testing and sort-of hit a dead end. I'm on a heavily modded install and stripping out the mods for this test is one bridge too far, I'm writing it up in case somebody notices the same thing and has a hunch what to look for. In my craft I'm using a different texture variant for the service module which has a docking tunnel, and the chutes are attached to the sides of that tunnel. So they're surface attached pretty much like they would be to the sides of a fuel tank, except inside the shroud until it jettisons. Not surface attached to the bottom of the module. But I also tried it that way and didn't get a warning there either. I've attached two craft files which both exhibit the behaviour I'm describing. One with the parachutes attached to the bottom of the bay, which in my case *doesn't* give me any airflow warnings or red flashing icons. One with the parachutes attached my way (to the sides of the hatch tunnel). Also doesn't give any airflow warnings or flashing icons on my install. Also attached KSP.log, but the relevant excerpts between abort and hitting the ground (listed below) don't give me anything to go on. First craft: [LOG 15:43:15.098] Game State Saved as persistent [LOG 15:43:16.171] Unpacking TestChutes [LOG 15:43:16.219] [UIMasterController]: ShowUI [LOG 15:43:17.716] 5/16/2021 3:43:17 PM,ShipManifest-DfWrapper,Attempting to Grab DeepFreeze Types... [LOG 15:43:20.380] [ModularFlightIntegrator] MFI Start [LOG 15:43:20.380] [ModularFlightIntegrator] Start. VesselModule on vessel : ModularFlightIntegrator AxisGroupsModule CometVessel CommNetVessel ModuleStabilization BPB_VesselModule CLSVesselModule VesselDataManager ModuleDynamicBatteryStorage WorkshopManager RPMVesselComputer ParkingBrake VesselModuleSave ModuleLifeSupportSystem WOLF_CrewModule [LOG 15:43:20.383] [KCT] New recon_rollout at launchsite: LaunchPad [LOG 15:43:20.477] [Progress Node Reached]: RecordsAltitude [LOG 15:43:20.478] [Progress Node Reached]: RecordsSpeed [LOG 15:43:20.478] [Progress Node Reached]: RecordsDistance [LOG 15:43:21.357] [Progress Node Reached]: FirstLaunch [LOG 15:43:21.357] [Progress Node Complete]: FirstLaunch [LOG 15:43:21.358] [FlightTracker]: OnProgressComplete fired [LOG 15:43:21.358] [FlightTracker]: Found 0 potential candidates for World Firsts [LOG 15:43:22.945] [ModularFlightIntegrator] MFI Start [LOG 15:43:22.945] [ModularFlightIntegrator] Start. VesselModule on vessel : ModularFlightIntegrator AxisGroupsModule CometVessel CommNetVessel ModuleStabilization BPB_VesselModule CLSVesselModule VesselDataManager ModuleDynamicBatteryStorage WorkshopManager RPMVesselComputer ParkingBrake VesselModuleSave ModuleLifeSupportSystem WOLF_CrewModule [LOG 15:43:26.448] [RealChute]: RC.radial was activated in stage 0 [LOG 15:43:26.448] [RealChute]: RC.radial was activated in stage 0 [LOG 15:43:26.448] [RealChute]: RC.radial was activated in stage 1 [LOG 15:43:26.448] [RealChute]: RC.radial was activated in stage 1 [LOG 15:43:28.108] [RealChute]: RC.radial was activated in stage 0 [LOG 15:43:28.108] [RealChute]: RC.radial was activated in stage 0 [LOG 15:43:28.109] [RealChute]: RC.radial was activated in stage 1 [LOG 15:43:28.109] [RealChute]: RC.radial was activated in stage 1 [LOG 15:43:32.869] probeStackLarge Exploded!! - blast awesomeness: 0 Second craft: [LOG 15:44:30.346] Game State Saved as persistent [LOG 15:44:31.375] Unpacking TestChutes2 [LOG 15:44:31.387] [UIMasterController]: ShowUI [LOG 15:44:33.001] 5/16/2021 3:44:33 PM,ShipManifest-DfWrapper,Attempting to Grab DeepFreeze Types... [LOG 15:44:37.570] [ModularFlightIntegrator] MFI Start [LOG 15:44:37.570] [ModularFlightIntegrator] Start. VesselModule on vessel : ModularFlightIntegrator AxisGroupsModule CometVessel CommNetVessel ModuleStabilization BPB_VesselModule CLSVesselModule VesselDataManager ModuleDynamicBatteryStorage WorkshopManager RPMVesselComputer ParkingBrake VesselModuleSave ModuleLifeSupportSystem WOLF_CrewModule [LOG 15:44:37.572] [KCT] New recon_rollout at launchsite: LaunchPad 2 [LOG 15:44:41.794] [ModularFlightIntegrator] MFI Start [LOG 15:44:41.794] [ModularFlightIntegrator] Start. VesselModule on vessel : ModularFlightIntegrator AxisGroupsModule CometVessel CommNetVessel ModuleStabilization BPB_VesselModule CLSVesselModule VesselDataManager ModuleDynamicBatteryStorage WorkshopManager RPMVesselComputer ParkingBrake VesselModuleSave ModuleLifeSupportSystem WOLF_CrewModule [LOG 15:44:42.002] [Progress Node Reached]: RecordsAltitude [LOG 15:44:43.988] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:43.988] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:43.988] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:43.988] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:45.385] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:45.385] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:45.385] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:45.385] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:45.869] Unpacking TestChutes Debris [LOG 15:44:46.011] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:46.011] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:46.011] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:46.011] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:46.750] [TestChutes Debris]: ground contact! - error. Moving Vessel down -0.336m [LOG 15:44:46.750] Unpacking TestChutes Debris [LOG 15:44:46.766] Unpacking TestChutes Debris [LOG 15:44:46.782] Unpacking TestChutes Debris [LOG 15:44:50.647] mk1-3pod Exploded!! - blast awesomeness: 0.5 I also don't see any patches happening that would override the behaviour of the realchutes: > $ grep RealChute ChuteTest.log | grep -i "rc.radial" [16:12:08]: grep --color=auto --exclude-dir={.bzr,CVS,.git,.hg,.svn,.idea,.tox} RealChute ChuteTest.log | grep --color=auto --exclude-dir={.bzr,CVS,.git,.hg,.svn,.idea,.tox} -i "rc.radial" [LOG 15:39:14.120] Load(Texture): RealChute/Parts/@thumbs/RC.radial_icon [LOG 15:40:09.706] Config(PART) RealChute/Parts/radial_chute/RC_radial [LOG 14:39:28.822] Applying update BobsPanicBox/MM_BobsPanicBox/@PART[*] to RealChute/Parts/radial_chute.cfg/PART[RC_radial] [LOG 14:39:32.858] Applying update RecoveryController/RecoveryController_MM/@PART[*]:HAS[!MODULE[ModuleAnchoredDecoupler],!MODULE[ModuleDecouple],!MODULE[USDecouple]]:NEEDS[StageRecovery] to RealChute/Parts/radial_chute.cfg/PART[RC_radial] [LOG 14:39:33.104] Applying update ScrapYard/Patches/ModuleSYPartTracker/@PART[*] to RealChute/Parts/radial_chute.cfg/PART[RC_radial] [LOG 14:39:33.315] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to RealChute/Parts/radial_chute.cfg/PART[RC_radial] [LOG 14:39:34.770] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to RealChute/Parts/radial_chute.cfg/PART[RC_radial] [LOG 15:40:25.474] PartLoader: Compiling Part 'RealChute/Parts/radial_chute/RC_radial' [LOG 15:43:26.448] [RealChute]: RC.radial was activated in stage 0 [LOG 15:43:26.448] [RealChute]: RC.radial was activated in stage 0 [LOG 15:43:26.448] [RealChute]: RC.radial was activated in stage 1 [LOG 15:43:26.448] [RealChute]: RC.radial was activated in stage 1 [LOG 15:43:28.108] [RealChute]: RC.radial was activated in stage 0 [LOG 15:43:28.108] [RealChute]: RC.radial was activated in stage 0 [LOG 15:43:28.109] [RealChute]: RC.radial was activated in stage 1 [LOG 15:43:28.109] [RealChute]: RC.radial was activated in stage 1 [LOG 15:43:35.270] [RealChute]: RC.radial was deactivated [LOG 15:44:43.988] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:43.988] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:43.988] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:43.988] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:45.385] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:45.385] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:45.385] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:45.385] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:46.011] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:46.011] [RealChute]: RC.radial was activated in stage 0 [LOG 15:44:46.011] [RealChute]: RC.radial was activated in stage 1 [LOG 15:44:46.011] [RealChute]: RC.radial was activated in stage 1 The BobsPanicBox update is a module that allows BPB to check for explosions. RecoveryController adds a module that sets the controlling recovery module. ScrapYard adds a module that tracks the part. StationScience edits any StationScienceModule present to add a botany skill -- don't think that's relevant here. And finally, USI merely makes the part disassemblable. Interestingly, in the craft files, I see that there is indeed an ActionArm action in the RealChuteModules -- but that's always set to inactive, it seems. Maybe I'll try setting that active and see how it behaves next. Additional files (self-hosted, external links): TestChutes.craft TestChutes2.craft KSP.log

I'm at a bit of a loss regarding how radial RealChutes work in Action Groups, at low altitudes, when stowed in one of those "shroud explodable" service modules (SM-6A). Simply put, I have three action groups: Abort, which triggers the LES tower. Custom 01, which jettisons the LES tower, and explodes the panels off the service bay. Custom 02, which has the "deploy parachute" action for the radial chutes. The chutes are also in normal stages, which *aren't* the stage that the vessel is in when I trigger the abort (obviously). If I trigger the abort, then custom 01, then custom 02, the chutes never actually deploy unless I also stage into the stage with those chutes manually. There is no message saying they're not in the airflow or anything like that. They're light blue in the stage view, implying they're armed, but they'll happily fall through their deployment altitude without deploying. Only when I manually activate the staging s.t. they end up in the active stage do they finally deploy. Do they need to be in the active stage for them to actually deploy? If so, that explains the behaviour and I can stop pulling my hair out over this -- except then I wonder if there's a mod somewhere that allows automatic staging from action groups. Or maybe I should enable the "must go down to deploy" toggle and just activate them in the first stage, but that doesn't seem like a very clean solution either.

The crane should be controllable using Q & E (or roll keys) as mentioned in its description. A lot of the parts have instructions or hints about their use in their description, be sure to read them.

I just noticed something about this mod in my install, while testing some behaviour that killed a few Kerbals during a simulated pad abort, and I don't see this mentioned anywhere. It doesn't use the capsule's hatch's angle as you might interpret it, i.e. directly out from the hatch orientation -- it uses the angle between the capsule hatch and the root part. Whether that's intentional or not, it makes for some interesting pad aborts if you have e.g. a stack of two capsules and the top one is the root part: Kerbals get ejected into the ground. The fix is obviously quite easy: Just make the root part the bottom capsule, or even the heatshield underneath it if you want the ejection to lob the Kerbals up a bit.

I will admit that the whole sequence of my Kerbals calmly reporting an anomaly while a few thousand kN of thrust was raging below them for another 10 seconds, before shutting down all LF engines and then aborting with the LES brought a smile to my face. Fortunately noticed this when an SRB misfired, rather than when something decided to blow up. And thanks for fixing this so fast!

Sure -- the point was only that when loading a saved vessel in the VAB, that crew arm somehow seems to be confused about the state it's supposed to be in.

Sorry for this somewhat long reply, it just kept growing while typing. There's two potential bugreports about halfway down. Oh I should've mentioned, I'm running the latest github zip of AlphaDev's HEAD (re-downloaded today) alongside the current CKAN 1.3 release, and my question was based on all the AlphaDev V2 material. So if those generators are already supposed to be in the V2 bases and plates, my install may be borked? Unless you meant that that's something you'll be adding still. And thanks for making them crossfeed-enabled. One thing I wonder, since you mention the Almost Free Launch Clamps -- I take it such a generator will fill up a partly-fueled rocket to the brim? Not that I've flown with partly-fueled first stages, and second- and further stages don't really matter in this regard unless somebody is going full-realism and fueling on the pad. I'm mainly just curious about the mechanics. The advantage of my current "add a tank and fuel line" system is that it doesn't touch the fuel levels in the vehicle itself, it just draws fuel until the launchpad tank is empty while still on the pad. Not something to change the behaviour over, but maybe interesting to consider regardless: What would happen if you'd make the pads actually contain a certain tank of fuel, with crossfeed enabled, and then the vehicle draws from that tank, and the generator can fill that tank. But I guess that would still also fill up any attached vehicle if the pad tank is full, so eh. </brainfart> Hmm. If I filter the assets to the AlphaDev mod, I still see "American Launch Stand" and "Saturn Launch Stand v2" -- but the "Soyuz Launch Base v2" with its LF/OX generator, indeed. So this change may also be something you're still working on but hasn't made it into the AlphaDev release branch yet? Speaking of which, you may already be aware but if not, the current AlphaDev release (installed per the instructions of copying only the AlphaDev subfolder into GameData) throws the following Soyuz-related B9PartSwitch "Serious Warnings" at me during game load: The log doesn't really reveal anything else, except that it also has the same warnings on "part unknownPart" while PartLoader is compiling the SoyuzLaunchBaseGantry. I could get you the full log but that involves some advanced VM-guest-to-host-file-transfer-wizardry so I'm actually hoping this is enough info. Anyway, it scared me enough to not even try to touch the Soyuz launch items so far, so don't know what in-game issues would pop up, but I figured they're unlikely to be caused by my install and thus a bug in the current AlphaDev. And finally, I've noticed that the displayed orientation of a retracted General Crew Access Arm New v2, attached to a General Crew Access Elevator New v2, when saved and then reloaded later in the VAB, gets set to extended (or, one time, halfway between extended and retracted). Both retract buttons at that point say "Extend", and if you click one of them the arm will reset to the retracted position and then go through its normal VAB extend animation. It will then function as normal for that direction -- but the other direction still says "Extend" and if you click that it looks like it extends from the other side's retracted position. After that, it functions as normal. I haven't noticed a similar issue with other swing-arms. Maybe this is an artefact caused by it being retractable in two directions? Anyway, thanks for this amazing work! I've finished putting my (admittedly small) launch fleet of Katurn IB, Katurn V, and Titan II-variants on nice-looking launchpads. Not looking forward to the release day of V2, when I'll feel compelled to migrate the AlphaDev pads to actual V2 pads, but eh, that's my own fault for not waiting until you release

Is there a reason that only the American Launch Stand and the Russian Launch Stand have integrated LF/OX generators, and all the other launch pads / stands do not? If not, would you consider adding this functionality to all of them? I'm currently simply integrating some large tanks and then hooking a fuel line to the pad -- this works in all cases but the Milk Stool -- but it would be even cleaner if they were just generating the LF/OX directly. Regarding the Milk Stool, it only passes the LF/OX if I hook it up to the launch pad with another fuel line -- but since I'm putting it under an engine plate and not under an engine I have to run a fuel line from the LUT to the 1st stage tank anyway. But again, that means I have to run some external fuel lines between different sections of the LUT. Any chance of making them fuel crossfeed enabled?

I have a question and some issue with the Abort functionality. This seems to consist of the following: Only works if you actually click Abort!, there's no "situation checking" like "has a certain amount of TWR been achieved", right? First plays an abort audio cue (Apollo-style audio plays e.g. the Apollo 13 anomaly report) Then executes the Abort action group if set up to do so. I've taken to playing with, among others, OhScrap!, Bill's Panic Box, and now also Kerbal Launch Failure (because OhScrap! wasn't blowing up my rockets during launch, and I usually can take an engine failure). During flight, this works nicely. Sometimes, however, OhScrap results in an SRB not firing while the vessel is still bolted down. Somewhat unrealistically, I've designed my launch pads to be able to take the stress of a fully firing, bolted down SRB, but that does mean I actually really want to be able to do pad aborts. I'm trying to do this by just firing the SRBs 2 seconds before lift-off, visually checking them for the red failure highlight, and hitting Abort! if they fail. So here's the problems: The latency of several seconds that step 2 introduces is somewhat annoying -- would it be possible and desirable to switch around the steps to first execute the abort action, then play the audio que? More importantly, with Action Sets being introduced, it only seems to run the Default action, regardless of which Action Set is active. In contrast, Bob's Panic Box runs the Abort action from the currently active Action Set. I tried setting it up with Action Set 4 being all the "pre-lift-off" actions and thus also having the pad abort, but clearly this isn't working. I'd rather not use the Default Action Set for the launch-pad abort because then I have to replicate all the shared abort logic (shutting down LF engines, e.g.) in all the other Action Sets. Any chance of replacing the Abort-logic with that from Bob's Panic Box?