Deimos Rast

well done; oh and b9 updated.

FYI: starting a new game, the difficulty options for workshop cause a massive wall of NRE's. 161029T090742.764 [ERROR] [DifficultyOptionsMenu+<CreateDifficultWindow>c__AnonStorey158.<>m__250] Error calling custom Enabled method in type Workshop.WorkshopOptions: 161029T090742.766 [EXCEPTION] [Workshop.WorkshopOptions.Enabled] NullReferenceException: Object reference not set to an instance of an object at Workshop.WorkshopOptions.Enabled (System.Reflection.MemberInfo member, .GameParameters parameters) at DifficultyOptionsMenu+<CreateDifficultWindow>c__AnonStorey158.<>m__250 () at UnityEngine.Debug:LogException(Exception) at <CreateDifficultWindow>c__AnonStorey158:<>m__250() at DialogGUIBase:Update() at DialogGUIToggle:Update() at DialogGUIBase:Update() at DialogGUIVerticalLayout:Update() at DialogGUIBase:Update() at DialogGUIVerticalLayout:Update() at DialogGUIBase:Update() at DialogGUIBase:Update() at DialogGUIVerticalLayout:Update() at DialogGUIBase:Update() at MultiOptionDialog:Update() at PopupDialog:SpawnPopupDialog(MultiOptionDialog, Boolean, UISkinDef, Boolean, String) at PopupDialog:SpawnPopupDialog(Vector2, Vector2, MultiOptionDialog, Boolean, UISkinDef, Boolean, String) at DifficultyOptionsMenu:CreateDifficultWindow() at DifficultyOptionsMenu:Create(Modes, GameParameters, Boolean, Callback`1) at MainMenu:OpenDifficultyOptions() at MainMenu:<CreateNewGameDialog>m__25F() at DialogGUIButton:OptionSelected() at DialogGUIButton:<Create>m__6F1() at UnityEngine.EventSystems.EventSystem:Update()

Inspired by your efforts, and by the fact that I couldn't sleep, I decided to sit down and crank out a 1.2 update for RLA. I went through every item in the mod and compared it to stock counterparts. It's mainly adding in the new stuff, plus some tag adjustments, but I did some very light balancing as well. Honestly, the most extravagant thing I did was capitalize the "P" in MonoPropellant in all the things....it was a long night... A lot of parts didn't need to be touched at all, and I resisted the urge to make changes for the sake of changes ("Propellant" excepted). Anyway, the configs are all done, I just have to test things and write up a changelog, then I'll post a github link and shoot @hoojiwana a message. Then I will take a nap.

sorry for the late response. I knew this would happen as soon as I mentioned it, but...now I can't reproduce the issue. I've tried since I last posted, to no avail. I'll keep at it, but don't hold your breath. It's possible I uninstalled the offending mod on accident, or added in another mod (such as Toolbar), that caused things to start working again. Solar panels are still being a bit weird. Also, for your consideration, since I'm here: you already have a bypass RemoteTech feature. What about "bypass CommNet" ? I ask not so much for the sake of cheating, although that's definitely applicable, but because there have been times when AGExt doesn't work due to "limited pilot ability/control", whereas clicking on the very same item I want to use and activating it manually, will work fine. That might be a design choice, but it seems a little artificial to me, and I'd like to bypass it on the rare occasions it comes up. Cheers.

Probe butt category = Utility, not Payload? Likewise, Probe core is Utility also, not Command? You know what they say about mod devs who stick all their parts in Utility... Also, the RemoteTech patch will need to be updated since you added an antenna. I believe currently you'll get both the RT antenna and stock antenna if you have RT installed. A !MODULE[ModuleDataTransmitter] {} should do the trick. Cheers.

I have an issue that I've already seemingly solved, but I mention is because I'm running the dev version, so it might be important. One of my landers, "Minmus DIRECT v2", is en route home from Minus (due in a few days or so). TACLS registers the lander and the occupant as being Prelaunch status, and thus doesn't show/update their life support requirements/needs. Switching to the vessel in question seems to have fixed things, and now when I go back to the tracking station, TACLS accurately reports things, and all seems well. You can see in the picture the TACLS screen and the lander/crew in question. Below are attached a log and my persistence file if you're curious. Cheers. EDIT: Oh, I'll also mention, since I'm here, maybe change the Life Support containers to all read "Life Support Food Container, 1.25m" since currently half refer to their diameters. Also, looking at the food containers now, they at least seem to be missing the bulkhead profiles. Github issue? http://imgur.com/a/24ZWN Log Save

The KAS I have has the Magnet and Winches, so the old one. Here is a log if you're curious.

me again, with another patch for you. So you have these lovely "Nuclear Fuel Tanks" that only store LiquidFuel, but when you use a mod like Kerbal Atomics that converts atomic engines to using LH2 instead of LiquidFuel, these tanks are left in a bit of an awkward state. Anyway, I "borrowed" the fuel tank switching patch from Nertea's CryoEngine's mod (see below), and modified it slightly so it would work with the fuel tanks in question. The original patch uses B9PartSwitch, as does this one, but luckily you have a version of your mod for that. It specifically won't work for versions with IFS or Firespitter. You have a head for these things (I don't), so I'm sure you could rework it as needed or desired. As it stands, the tanks in question now have the option of storing LH2, LH2/OX, or OX. The Size3 drum, for example, stores 72,000 LH2, or 43,200 LH2 / 2880 OX, or 7,200 OX - whereas it originally stored 7,200 LiquidFuel. Since they are dedicated drums for storing this type of fuel, I also went ahead and gave them the full CryoTank module (with cooling to prevent boiloff). Normally, they lack the cooling option (which costs EC). If you dislike this, I believe all you have to do is remove the "CoolingCost" line in the ModuleCryoTank below, to restore default behavior (the CryoTank mod adds the module to all fuel tanks). Considering that visually, your tanks and the tanks from CryoTanks look quite different, none of this might make any sense from a realism perspective. But it made sense to me from a gameplay perspective; at the very least it gives the tanks a purpose. Since I basically copied and pasted the patch (albeit with edits) from CryoTanks, I feel it fair to mention its license, which is CC-BY-NC-SA-4.0, which incidentally is the same as your's, so I don't think it matters in the end. But if I'm to plagiarize, I should at least give credit where credit is due, and that is entirely with @Nertea, as I changed very little. As always, tested and working. If you have any suggestions for improvements, let me know, as I feel I went about it in a bit of a ham handed manner (I'm not the cleverest of kerbs when it comes to such things). (see below for code) Link EDIT: I run the patch first thing (at the 000_Rast level), so the tanks already have ModuleCryoTank by the time the CryoTank mod sees them and therefore doesn't add it in again, but your mod comes after that mod, so you might get a second ModuleCryoTank, added by this mod. Unsure about this though. Could probably over ride the other one easily enough. //FTP Nuclear Tanks @PART[TPtank?mL0*-Nuke]:HAS[!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[FuelTanksPlus&CryoTanks]:NEEDS[!modularFuelTanks&!RealFuels] { %LF = #$RESOURCE[LiquidFuel]/maxAmount$ //%OX = #$RESOURCE[Oxidizer]/maxAmount$ %OX = 0 %totalCap = #$RESOURCE[LiquidFuel]/maxAmount$ //@totalCap += #$RESOURCE[Oxidizer]/maxAmount$ %massOffset = #$totalCap$ @massOffset *= 0.000625 // standard dry mass per units of LF/OX // 0.000025 @massOffset *= -1 @LF *= #$@RESOURCE_DEFINITION[LiquidFuel]/unitCost$ //@OX *= #$@RESOURCE_DEFINITION[Oxidizer]/unitCost$ %costOffset = #$LF$ @costOffset += #$OX$ @costOffset *= -1 !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} MODULE { name = ModuleB9PartSwitch moduleID = fuelSwitch switcherDescription = Tank Type baseVolume = #$../totalCap$ SUBTYPE { name = LH2/O tankType = LH2O addedMass = #$../../massOffset$ addedCost = #$../../costOffset$ } SUBTYPE { name = LH2 tankType = LH2 addedMass = #$../../massOffset$ addedCost = #$../../costOffset$ } SUBTYPE { name = Oxidizer tankType = OX addedMass = #$../../massOffset$ addedCost = #$../../costOffset$ } //SUBTYPE //{ // name = LiquidFuel // tankType = LF // addedMass = #$../../massOffset$ // addedCost = #$../../costOffset$ //} //SUBTYPE //{ // name = LF/O // tankType = LFOX // addedMass = #$../../massOffset$ // addedCost = #$../../costOffset$ //} } MODULE { name = ModuleCryoTank FuelName = LqdHydrogen FuelTotal = #$../LH2$ BoiloffRate = 0.05 // in % per hour CoolingCost = 0.08 // in Ec per 1000 units per second } }

howdy stranger - I was futzing around with the latest LETech, when I spied my old RealChute patch hiding as a txt amongst the files. Informative, but doesn't do anyone much good (it also only covered one of the three chutes). So I made another patch, which I tested successfully. As a disclaimer: like last time, I just compared the drag of your chutes to stock chutes, then looked at what the diameter the RealChute's patch gave them, and scaled accordingly. This doesn't take into account differing Drag modifiers, which you lean on heavily. Granted, neither does it remove those modules, so they still apply, but I was under the impression they tied in directly to the drag applied by the Module Parachute, which has since been replaced by the Module RealChute. As I mentioned, I tested all of them successfully - the largest one is quite large in diameter; the cord for the parachute alone is 1.25m thick! Slows a Mk1-2 Pod down to something like 1.4m/s iirc. I made them all procedural, meaning they can be edited in the vessel editor with the RealChute editor, and to a lesser extent on the fly. If you decide not to use the patches, for whatever reason, consider at least adding the line "category:NEEDS[RealChute] = none" after your "category = Utility" in your configs. The RealChute mod adds its own Parachute editor category, and currently your parachutes appear there and in the Utility category as well. The above line should, in theory, remedy that, as it's what is used in the patches below. One last thing: you might see in the editor when first selecting/placing a chute an error in the console, "Error: cannot find transform 'canopy' in the library." I don't know what that's all about, but stock chutes do it too (RealChute's included chutes are the only ones that don't); rest assured though everything works fine. Cheers. The link and the code (in case I clean house). Link //LET-SP-1X24 Parachute (1.25m) @PART[LETchute1m]:NEEDS[LETech&RealChute]:AFTER[LETech] { maximum_drag = 0.32 @category = none @cost = 1600 @mass = 0.9 !sound_parachute_open !sound_parachute_single !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.9 timer = 0 mustGoDown = false cutSpeed = 0.5 spareChutes = 5 PARACHUTE { material = Nylon preDeployedDiameter = 10 // 2 deployedDiameter = 200 // 50 minIsPressure = true minPressure = 0.01 deploymentAlt = 1000 // 700 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 6 preDeploymentAnimation = chuteSemiDeploy deploymentAnimation = chuteFullyDeploy parachuteName = canopy capName = cap } } MODULE { name = ProceduralChute textureLibrary = StockReplacement currentCanopies = Main chute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } //LET-SP-3X24 Parachute (2.5m) @PART[LETchute2m]:NEEDS[LETech&RealChute]:AFTER[LETech] { maximum_drag = 0.32 @category = none @cost = 3000 @mass = 1.5 !sound_parachute_open !sound_parachute_single !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 1.5 timer = 0 mustGoDown = false cutSpeed = 0.5 spareChutes = 5 PARACHUTE { material = Nylon preDeployedDiameter = 10 // 2 deployedDiameter = 800 // 50 minIsPressure = true minPressure = 0.01 deploymentAlt = 1000 // 700 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 6 preDeploymentAnimation = chuteSemiDeploy deploymentAnimation = chuteFullyDeploy parachuteName = canopy capName = cap } } MODULE { name = ProceduralChute textureLibrary = StockReplacement currentCanopies = Main chute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } } //LET-RP-1X24 Radial Parachute @PART[LETchuteR1]:NEEDS[LETech&RealChute]:AFTER[LETech] { maximum_drag = 0.32 @category = none @cost = 1600 @mass = 0.75 !sound_parachute_open !sound_parachute_single !MODULE[ModuleParachute]{} MODULE { name = RealChuteModule caseMass = 0.75 timer = 0 mustGoDown = false cutSpeed = 0.5 spareChutes = 5 PARACHUTE { material = Nylon preDeployedDiameter = 3.5 // 0.7 deployedDiameter = 68 // 17 minIsPressure = true minPressure = 0.01 deploymentAlt = 1000 // 700 cutAlt = -1 preDeploymentSpeed = 2 deploymentSpeed = 6 preDeploymentAnimation = chuteSemiDeploy deploymentAnimation = chuteFullyDeploy parachuteName = canopy capName = cap } } MODULE { name = ProceduralChute textureLibrary = StockReplacement currentCanopies = Main chute } EFFECTS { rcpredeploy { AUDIO { channel = Ship clip = sound_parachute_open volume = 1 } } rcdeploy { AUDIO { channel = Ship clip = sound_parachute_single volume = 1 } } rccut { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_cut volume = 1 } } rcrepack { AUDIO { channel = Ship clip = RealChute/Sounds/sound_parachute_repack volume = 1 } } } }

good to hear back from you. Airbrakes = why did you go with lifting surfaces instead of the actual aero surface that the stock airbrake uses? Just curious. There are a couple of fields it has that you don't, which may be of negligible worth. To clarify the probe thinger: I was in Kerbin orbit, and didn't have any issues with control. The CommNet icon registered it as a probe, but that's the only icon I got, no connection bars or anything (this was with the airbrake model). I have the option "requires connection for control" enabled, so I'm pretty sure everything is working as you'd like. It just seemed slightly odd to me, is all. The decoupler thing: I think the issue is you're not using an AnchoredDecoupler, which all stock radial decouplers are, in the triple decoupler inline piece. That's my take on why it didn't decouple for me. Otherwise, if it is like you say, requiring precise node snapping, that seems a tad difficult. It also doesn't leave much room for a parachute (I had moved mine down a bit). One final point: I noticed the antenna on the one pod has a windresistance rating, meaning it can be broken at high Q. It used to be with RemoteTech that if the antenna being broken off was a part of the root part, it would cause a kraken attack, so I thought that might be the case here as well. I tested it out, deploying it during reentry, and surprisingly no ill effects happened when it broke off. Cheers.

@Thrimm FYI: all your domes have a typo in the bottom node, and read like so: node_stack_bottom = 0, 0, 0, 0, -1, 0 , 3 And naming your airlock "airlock" sets you up for part conflicts with other mods, as I can think of at least one other mod that also name their airlock "Airlock". Obviously, if you change the internal name now, you risk save breaks, but you could keep it as a legacy part. Just a thought.

I moved them all to Control in my game. Made sense to me. I don't think we need another category.

for clarity, what do you mean by: - If I can't get the stock science modules to treat kerbal experience correctly I'll have to create a plugin to do it instead Just curious. Is it a problem you currently have or functionality you're looking to add? I haven't had a chance to poke around with it yet.

those were the two I saw that I remember off hand. Who needs planes anyway. glad to help; no rush.

Reading through this thread is kind of tragic, looking back over it. Everyone, myself included, hyped for new shiny things. But...no one pointed out the obvious: you don't release the assets to something that's going to be a central feature in a new release. The license is also that of a mod, if I remember correctly, not SQUAD assets. Now with Porkjet's reported departure...I hate to say it, but I think this is it boys and girls. This is our part revamp. RIP.

Do you mean 1.2.2? That's the version on Mediafire currently, and the last version on the KerbalStuff torrent, and what the title says. The plugin I referred to is the one below. It's up to date, but I'm not sure these old pods conform to the new standard entirely. It has to do with meshes and shaders and that type of witchcraft, or something. The plugin has undergone some revisions since I last looked at it, so it might be working better than when I played with it. Or worse. The only real issue was some things that shouldn't have been transparent (like the frames around the windows) sometimes went transparent, generally after launching. There are also a few micro landing legs and a micro claw in the pack. These are the old legs, so they might just benefit from a straight conversion to ModuleAnimateGeneric. They're too tiny to really have any suspension anyway, if they ever did. I seem to remember some nodes, specifically the bottom ones, being inverted, as is typical for older mods; but I could be wrong (going by memory here). JPLRepo put together a pretty solid wiki article about what a pod mesh/transform/thinger needs to qualify, which I also linked. Overall though, it's pretty solid (at least it was a few versions ago). https://github.com/JPLRepo/JSIAdvTransparentPods/wiki/JSIAdvTransparentPods

@Qberticus Not seeing any icon for Haystacks with the latest version. Also seeing errors in log related to missing icons. More importantly though is this error, below. Relevant link below, I think. Cheers. NotSupportedException: The invoked member is not supported in a dynamic module. at System.Reflection.Emit.AssemblyBuilder.GetExportedTypes () [0x00000] in <filename unknown>:0 at ToolbarWrapper.ToolbarTypes.<getType>b__0 (.LoadedAssembly a) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable+<CreateSelectManyIterator>c__Iterator12`2[AssemblyLoader+LoadedAssembly,System.Type].MoveNext () [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Single[Type] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.SingleOrDefault[Type] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0 at ToolbarWrapper.ToolbarTypes.getType (System.String name) [0x00000] in <filename unknown>:0 at ToolbarWrapper.ToolbarManager.get_Instance () [0x00000] in <filename unknown>:0 at ToolbarWrapper.ToolbarManager.get_ToolbarAvailable () [0x00000] in <filename unknown>:0 at HaystackContinued.HaystackResourceLoader.Awake () [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelLoaded(Int32) AddonLoader:OnSceneLoaded(Scene, LoadSceneMode) UnityEngine.SceneManagement.SceneManager:Internal_SceneLoaded(Scene, LoadSceneMode)

looking at the old thread, there is a nice close up picture of one of the labs - maybe add that to the thread? Currently it's hard to get an idea what they look like. I'm pretty sure these would already be compatible with TACLS, as I don't think it does anything special with labs (like add recyclers a la USI), but are there any issues that you know of with TACLS? I'll give it a test eitherway and let you know. Cheers (and thanks for maintaining this).

holy cow you've really grown this mod since I last checked in here. Everything looks great! Now I just have to build rockets worth reusing, haha. Keep up the good work. As for your question: which are the ITS legs? The one on the left, correct? I haven't used them in game, but looking at their profile in the picture, I'd assume they fold down similarly to the Falcon legs - and if they're the same size, then you have unnecessary overlap. Not saying you can't have that, just might make more sense to make them more unique. I guess I would vote larger, as they seem - visually - like they could handle more weight. But like I said, I'm not terribly familiar with their real world counterparts, and I have yet to try them in game; I'm just giving you a generic opinion, take it or leave it. I really like all of what I see though!

thanks for maintaining the mod, and the update. It's a must have.

a lot of pods have retro rockets for braking, but airbrakes?! Madness! I like it. that being said, the fact that you included landertrons is awesome, as I am a big fan of that mod. My only suggestion is move some of the pictures from the dev thread over here, since the ones here currently don't show it off that well (i.e. either covered in flames or at a distance). Cheers. EDIT: I got a chance to play with it a bit; here's my feedback. - Really like the Tri-Decoupler idea, but when I used it, it didn't work (pods stayed attached). Activated via action group; saw the smoke fire - pods stayed firmly in place. This might be user error - will try again. (EDIT2: Turns out I may have forgotten a decoupler or three). Although, looking at the configs, it should have worked without the decoupler. Maybe switch it to an anchored decoupler instead of a regular decoupler? - Your attachnodes are where your hatches are. This makes it impossible to EVA from an attached pod. - Add airbrakes to Brake actiongroup? I can see pro's/con's either way. - EVAing = sliding off the "ladder", almost impossible to climb back in after a couple of seconds outside - Is it a probe or does the kerbal have command? CommNet seems to think it's a probe, but it's connection was non-existent. - Only tried the Airbrake REKT, but it sinks in water. - Add Kontainer to FuelTank category. Tags on Kontainer seem to be from Hitch-Hikers? - Airbrakes work perfectly and I measured their drag on the way down - it successfully slowed my pod to safe parachute speeds. - Consider using "GenericSpace1" for your placeholder Internal IVA. It'll give you a portrait and a barebones IVA. Request: Would like to see custom parachutes that fit under the decoupler head. REKT Kontainer has a missing "{" in the ModuleFuelJettison, which seems to have been converted into an extraneous "}" down below. RESOURCE { name = Ore amount = 0 maxAmount = 90 } MODULE name = ModuleFuelJettison } } }

So " Fixed Rescue and tourist kerbals. NREs. " in the dev version would apply to things like the below (crew member is a tourist)? Man, here I thought I had a juicy one. Off to grab the dev version to find out. Congrats on assuming direct control - TACLS is in good hands. Reading the last few posts...things seem to be turning interesting. -WARNING- Tac.LifeSupportController[FF8EF84A][10261.72]: Unknown crew member: Desby Kerman (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42) NullReferenceException: Object reference not set to an instance of an object at Tac.CrewMemberInfo..ctor (System.String crewMemberName, System.String vesselName, Guid vesselId, Double currentTime) [0x00000] in <filename unknown>:0 at Tac.LifeSupportController.ConsumeResources (Double currentTime, .Vessel vessel, Tac.VesselInfo vesselInfo) [0x00000] in <filename unknown>:0 at Tac.LifeSupportController.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) EDIT: Yup. https://github.com/KSP-RO/TacLifeSupport/issues/52

Well now. Here we are again. I was about to tell you what's what, how your version file was incorrect, how AmpYear was spamming my Debug Console incessantly, how it wasn't registering Power Producers (e.g. solar panels) - and goodness knows what else! But apparently you fixed all that, and 14.2.0 works marvelously... Rather disappointed now. Carry on. EDIT: Ahaha! Found something (maybe). I noticed that adding an NFE reactor to my prober didn't increase the power production numbers. However, it does correctly register when you launch the vessel, and actually turn the reactor on. That does make sense, but is slightly inconvenient. Also, I found this, which I don't think actually means anything, but it might! [LOG 14:32:07.692] 10/27/2016 2:32:07 PM,AmpYear,Ampyear - KAS Interface Failed

Dear SirDiazo: thanks for the update! Mucho gusto. Two things, one which might not be related to this addon at all. It's a little embarrassing, but for the life of me I can't get solar panels to retract with this mod anymore. I think it might be that it takes too long for them to deploy, and the toggle state in AGExt doesn't flip over. Or something. The only time I got it to work was by mashing the button repeatedly for a good minute straight. Normally, nothing happens when I hit it. As I said, I'm not sure this is specific to AGExt, but PartCommander has no issue, nor do I when doing it via right click context menu. Antennae, which you would think would be similar, don't have the issue. I can try to make a video or do screen shots for what the setup looks like, if you'd like, but it's a pretty minor issue. More importantly, and you'll remember this one, I'm sure: I'm still getting the "EVAing a kerbal acts as docking a vessel and clears the action bar" bug. I have been all along, ever since I mentioned it, but figured it was just a me specific issue (which it probably is still). However, I am now on Windows, the land of supposed milk and honey() and KSP 1.2, and I still get the same old bug. KSP has been installed fresh, along with my mods, many times over. Last we talked about this, we/I decided it was a mod conflict. I don't play with many of the same mods any more (RIP), but there is still a fair degree of overlap. I will add of note that EVAing the kerbal a second time restores the issue as well, and is often faster than navigating through the menu and clicking "next docked vessel". As always, I know you're busy, but say the word and I'll throw some logs or even a video at you, highlighting the issue (incase you can't repro).

you added mesh switching? This is an outrage! Now I have nothing to complain about... #TooMuchFoil #NeverForget