B-STRK

Not sure if this has been answered elsewhere here: how does one upload an Imgur-hosted video or GIF as a live player? Insert Image From URL won't do it, and neither will typing the link in the post.

OMG this is really doing the math, and also made me realize I was undeniably lucky managing to pass trigonometry in high school (God, I don't want to go back there again, haha), and I am so sorely tempted to load up a clean KSP with AA, HSI, PAPI, Flight Indicators, and what was that mod that would live-track vessel path again (Persistent Trails)? and try to fly an instrument approach, just to see what path it would trace, if I wasn't too busy trying to complete an Elcano right now along with other real life stuff. I also know there's supposed to be a mod capable of tracking flight data, so combine that and we could have a way of checking this out, finding out what's up. Physical data analysis really isn't my strong suit (and to think, if I have to do a case involving vehicular accidents, that's the sort of thing I have to bank on), so I admit it'll take time for me to fish through your experimental data. One thing that came to mind though, The speed measurement and AA's speed control is the airspeed control (speed along the hypo, not the triangular base), which at this regime should be close to HS but not quite. I don't know if that should have an effect either, but like you said if you've controlled for the HS (or even the airspeed, for that matter), then the VS should be more or less fixed. You're right, once you've stabilized on the approach, including a fixed airspeed coming in, then the VS shouldn't be varying much. The only other thing I could think about is the autopilot playing catchup/matchup to the target speeds. at the time you're capturing the data--nothing is so instantaneous, after all, and vertical speed changes could be sensitive compared to airspeed or groundspeed changes (whether as a real life physics or KSP physics thing, but I think I recall something about that in the FSX lessons field?). All this, short of Ser actually popping the hood on his mod so we can see the details. This is gonna stay at the back of my head, I admit. If I ever do get the chance to try out tracing the HSI's glideslope as described above (and then the PAPI's for that matter, and maybe MJ's spaceplane landing guidance too), I'll come back to report the findings. It is not necessarily the hard numbers/data--unless there is that mod that is capable of tracking the live flight data like a black box--but at least the Persistent Trail will show whether or not there are any visually observable kinks in the glideslope. With the hard data tracking, though, we can see just exactly how varying the airspeed, VS, and ground/surface speed (if tracked), plus any control inputs, are while trying to track the ILS. Also, maybe the next time I fly a spaceplane in my main save (usually when I do a crew change), I'll probably be watching the instruments very closely to see if I can observe what you're observing. As a fellow FS pilot, I think you'll probably understand: oh God, the frustrations of hand-flying the perfect ILS approach.

I'm tempted to ask for the calculations you derived, but as the old joke goes, the reason why I went to law school is that I can't do the math (and then tax law came about and RageFace.jpg). However, both considering your disclosure that you're running an autopilot, and my own experience that I have HSI (this one), the PAPI mod, and one of the HUD mods that projects a flight path indicator, you raise an interesting point, but we may also need to check one variable. (Though please also note that I'm running with 1.9.1 at the moment, but I don't think there would have been anything drastically altered by 1.11 to have changed anything between the compatible mods, would it?) I can note from experience that the HSI's 3-degree glideslope does not exactly line up with the PAPI's 3 degree setting. What would be dead-center on the HSI is 3-white on the PAPI ("slightly high", but I know there is a specific slope range for that, like about 1.5 degrees I think?) . On the other hand, by the time I can distinguish the PAPI I'm close enough that reading both instruments would be quite sensitive. However, I can also note from a recent sweet run where from even before the outer marker, I managed to peg the HSI centered (glide and localizer, sweeet!), and planted the HUD flight path indicator dead on where the PAPI lights would cross the runway (in short, the expected touchdown point), and making sure that I can keep it there, and I observed that, for as long as I was correcting to keep the flight path indicator on the touchdown point, I was flying the HSI glideslope. And the only time I deviated was at the inner marker when I saw I wasn't managing my speed properly, I was coming in too hot, so I had to kill the throttle. Under those conditions then, I was more or less keeping (as humanly possible) a straight line. If the HSI glideslope indicator wasn't dancing around, then it was reading (the mod was projecting, to be more accurate programming-wise) a straight glideslope, which is exactly what a glideslope should be. Okay, time to dive deep into the fireworks. Spoilered because wall of text:

Never gone that size yet, but you can test it by cheating a construction facility and resources and engineers into orbit and seeing if it can hold up to it. In theory, there should be no problem as, so as long as the deployment area for the Orbital Kit is clear, and you have the resources, microgravity means the entire setup shouldn't tear itself apart no matter how big the deployed box gets. That doesn't mean however it couldn't happen: the connection between the kit and the construction facility is a docking port, and if you try and maneuver the construction yard with SAS on, it can induce an oscillation feeding into the docked (and deployed) kit that, considering its weight, can build up destructively. I imagine if you leave the SAS off until the vessel is deployed, it can do so. Like I said: I never got to that size in my playthrough yet, but to give you an idea of what is going on, I'll drop in a couple of picks to demonstrate what I mean (spoilered to save space and loading): Also, please don't forget to ensure no autostruts between the Kit and facility (and no "To Heaviest Part" I think) to be sure, and also to ensure that if you're using any KJR, that it is marked compatible with GC. (There are a few posts about this earlier here where the wrong autostrut, or the wrong Kerbal Joint Reinforcement version, could muck things up as well.)

After landing on Duna (legitimately, as in no cheat/hyperedit) for the first time ever since June 8 2014 when I purchased 0.23.5 (too many Krakendamned back-to-square-one with every major update), made the foolish choice to start a Duna Elcano because why not, and discovered that in the intervening six years I've become more vulnerable to motion sickness while playing games, which is not helping my stomach endurance in running an Elcano. Especially on Duna.

You need to switch to a vessel that is not in the loading scene, meaning more than 2.2km away. Or to be safe, switch to a craft in another part of the planet. Or something orbiting the planet. Or another planet entirely. Or go to the Tracking Station, even. The vessel must be unloaded from the active gameplay because what BV does is it repositions the vessel while you're busy doing something else, along its calculated route until it arrives, or you interrupt it by loading/jumping into the vessel again before the destination. You can see this by running the autopilot, returning to the Tracking Station, then viewing the planet and watching the icon of your rover "landed" moving towards your intended destination.

Workaround: Click Setup; set the fairing pressure to a negative number. If yo want to only deploy fairings as stacked but not past a certain point: set your stage limit to any stage BEFORE the fairing you DON'T want deployed. Set the fairing deploy pressure to a negative number. ENSURE that your launch profile will use up the stages tight up to before the limit, including the fairing stages you want deployed. BE WARNED: setting a stage limit that is arrived before your apoapsis height has been established as desired will mean You Will Not Go Into Space TodayTM, please redo your Setup. EDIT: What I have not established yet is if GT will deploy fairings that are set to Not Staged in the editor (meaning only a PAW action can deploy them), but it is something to try.

Okay, I'm not the mod author, but in the spirit of assistance especially to Igor when he reads your post, more detail please. You mentioned KAS connectors. We're talking about the same KAS, right? The new implementation by Igor whose KAS connectors no longer do the pipes, and not the old KAS where they did do the pipes? Because the KAS connectors of nuKAS don't stack. Neither do the joint bars of nuKAS. Not at all. I cannot recall anymore if the old KAS connectors stacked, and if that memory dates back to when KAS also handled storage functions before it was spun off to KIS and KAS. Continuing on, I'd like to ask: when you say items used to be stackable, are we talking about an earlier version of KIS (you upgraded and they are no longer stackable), or in the same version of KIS? If in the same version of KIS, can you recall anything new you did between when they were stackable and they aren't? Finally, I do recall that the definition of stackability can be writ into the config of each part, using the KIS modules. I think, IIRC, that stackability is not the default for parts. (For this, I suggest visiting IgorZ's github KIS wiki for help on the modules involved.) But again, you're not providing enough detail to see if this is a mod issue, or an upgrade-between-versions issue, or even a restart-KSP-to-see-if-the-problem-goes-away issue. In the words of Jerry McGuire, "Help (Igor) help you. Help (him) help you."

Hey again, allista! Couple of queries. First, are the docking ports of the dockable kit containers (particularly the construction ports) compatible with the USI Konstruction mod's weldable docking ports? (let's just say I've been having trouble with getting a craft's nodes to expose in the build scene for GC to identify, so I was thinking if I used weldable docks to somehow get around it). It doesn't seem like they're compatible, but this brings up another query. And second, as pictured below, I was testing if the kit can dock to a weldable dock. But when I set the control-from-here to the construction port, it was aiming backwards (the DPAI gives the better indicator of it, but even the navball shows that the construction port in this case is oriented antitarget). Was I doing something wrong here? EDIT 24 June 2020: The reason why I wanted to investigate if a dockable kit can dock to the weldable dock is because, like I said, one station module I'm making wasn't registering its bottom node as exposed by Global Construction. Some convoluted thinking on my part thought that maybe using a docking port would allow GC to recognize something, and I wanted to use the weldable ports to make a permanent connection if I was forced to use it. But I discovered what was causing GC to drop recognition of the bottom node, and I wanted to run it past you. The two pictures below represent the space station module I am constructing. The node meant to attach to the mother station is a Stockalike Station Parts Expansion/SSPx 3.75m crew tube structural, though that's not critical right now. What I found was that if I added one of the three large solar panels from the Near Future Electrical mod, the three being (a) the superlarge circular panel generating 125EC/sec, (b) the superlarge blanket array generating 250EC/sec, and (c) the hyperlarge blanket array generating 500EC/sec, all three being surface attachable only, Global Construction can no longer recognize the exposed node. (Picture below is the 125EC one) If I take the solar panel concerned away, however, GC will now recognize the exposed bottom node. As I'm not a coder, I can only run some hypotheses from intuition. (a) These are superlarge solar panels (you could see it in the first picture of this setup). Somehow their size causes GC to lose recognition of the bottom node. (Please note that this happens whether or not the panels are retracted; I extended them in the pic to give you the idea of the total size). But I note that there are other solar panels in NFE that approach the size of these, but do not cause GC to lose the bottom node. Is there a size limit to GC in the orbital-dockable construction mode? (b) Something in the code of these specific parts is messing with GC. But that means having to coordinate with Nertea on what's conflicting, if there is any conflict in the first place. But the other NFE solar panels do not cause this to happen. (c) Maybe there is another mod interfering with both NFE and GC. Haven't gotten to test that yet, admittedly. Again, running this past you in case I might have run into a GC limitation (this time, size, maybe).

Thanks for the compile/rerelease! Questions: I can replace the previous/pre-this-release KipEng folder with the one here without any issues? (as in there are no substantive changes between your rerelease and the original release that will break crafts built with the last version UDPs, for example?) And would you have plans or interests to make a 5m and/or 7.5m version of the megachonk UDPs?

I vote for keeping it, I bury my reactors in parts or in bayload bays (as though shielding it) and sometimes having to play with the camera to access buried parts is just a hassle. Also the control sliders are a little finer-tuned in the US than they are in the PAW.

Hiya maja, one proposal would be to add a settable offset (say x number of meters from target), maybe a cardinal direction or bearing from target as well. Or randomly within that circumference, but it does create the complication of arriving in a zone with multiple vessels, usually like MKS or Pathfinder bases which allows for discrete base/vessels in a given flight scene and range to interact; the rover could be targeted to arrive at an offset from the targeted but it just so happens that another vessel is on that same spot. Maybe add a conflicting traffic check as well prior to spawning, and then offset the rover to spawn clear of the vessel? Other than that, Paaaad, if you've got Waypoint Manager, you can set up a marshalling waypoint clear of your base for rovers to target, and have BV target that. Just make sure as well if you're sending multiple vessels simultaneously to that one spot to stagger their launches (and thus arrivals), or you'll have the same issue as targeting the base--this time with all the arriving rovers.

I know what you mean. I don't use Restock myself, but what I can show you is what I hope can help you as a workaround: What you're aiming to do is to make a subassembly of your docking ports with some sort of removable "guide" to indicate which way is up. In the picture above, that would be the 1.25m battery with a Communotron 88-88 surface attached to where the "up" point would be (A). For the basic docking port, it's stacked to the "working"/front end so the back is free to be connected to your craft, like in (C). When you're done attaching, you take out the battery and you're done. (Remember: this works because when you first pick a part from the menu to place, it is (I hope this is the case for all parts stock and mod) always oriented Z+-up and facing forwards as it is programmed to in its configuration. In making the thing above there, the only thing I ever maneuvered/rotated was the flat silver platform thing out of the Buffalo mod so I could make some sort of multicoupler to show everything simultaneously (in reality, you'd just be using a simple tank as your root part in creating the subassemblies). In mounting the docking ports above, no part rotation was applied before placement--hit spacebar multiple times if you have to to ensure it is in the default position.) For the shielded docking port, where there is no "front" node to attach to (B), the guide is attached to the back and saved as a complete subassembly (port, battery, and antenna). The battery is what attaches to the craft, but after doing so, pull off the docking port--and hope to God it does not reorient itself when you do so; this usually happens I think when you mount a part to a parent, rotate the parent with the gizmo, then pull the first part off, so avoid using the gizmo to position the subassembly until after completing the following steps--pull out the battery, and reattach the docking port (which we hope has retained its pre-pull-off orientation) back to its mount. In placing the ports on station and spaceplane, orient the antenna (rotate the port in case of (A), the battery in case of (B))in the favored direction, so that when the ports are docked, the antennas are facing the same direction. For example, you want the antenna on the station docking port facing away from other structures and out into open space; you want the antenna on the spaceplane pointed downwards (if mounted on the nose, for example) or the direction away from the empennage (if mounted as a dorsal docking port). In the case of the shielded port where using the rotation gizmo on a parent part will cause the child part to reset its orientation when pulled off, you may have to use WASD to rotate the part before placement so as to prevent the dock from resetting its orientation when pulled off. This does not help in surface-mounting the docking port, I know. I am not sure if surface-mounted parts may be saved as a subassembly. If they can be, try to set up your root part so that things can be surface attached while pointing "forwards", but I am not sure if parts rotate themselves as you surface-mount them. This one will be more experimentation than anything, sorry. One tip however I can repeat from my last post is that the gizmo tool in Local mode orients itself to the part's XYZ axis locations. See picture below; your Z axis passes through the intersection of the red and green rings. It doesn't help you identify which of the two is "up", but it does reduce your DPAI (and Mechjeb docking autopilot) alignment solutions in flight to 0o and 180o. Finally, and I really do mean this, we can ask the Restock designers to add some sort of indicator or guide in the design of the docking ports to ID which direction is Z+/up. I really do mean it. I know Nertea contributes to Restock--his design for the docking port there is the remesh of the standard docking port made when one installs Stockalike Station Parts Extended to a stock KSP install, and yes it has that symmetrical "problem". But the extendible docking port provided by SSPx has a design asymmetry I could use, and Nertea designed that one as well (albeit the asymmetry was a consequence of the design of the extension animation). ADDENDUM: whoops, my original instructions for how to point the antennas on the station and plane are mixed up, this would cause collisions. Actual instruction is to imagine the final placement of the ports relative to each craft so that when they are docked and aligned, the plane empennage/tail is pointed towards open space from the station's perspective.

For the stock docking ports, their graphical design is actually not symmetrical in the vertical/z axis. For example, when looking at the "front (SPH)/top (VAB)" or the "working end" of the docking ports in question, the Docking Port Jr. has the '__' look on its face (the classic "Docking Port Jr. Is Not Amused" face ) with the "eyes" being Z+. For the other two docking ports, there is this black bar on the center that is above the (imaginary) horizontal/lateral/X-axis bisecting diameter of the disc face, and the side this bar is on is generally treated as the Z+. All these are based on how these parts are deployed into the SPH as a root part, or how its pre-placement "ghost" graphic is oriented when you bring it into the build scene without rotating the part using WASD, meaning that the working end is pointing "forwards" towards the SPH doors. If you want your two craft to be docked in a specific orientation, you have to get these "up" directions pointing the same way on both the docking and dockee craft when you build them both. How you can test it is to build the craft separately, load one into the VAB or SPH (SPH is better because of the camera freedom), MERGE the other craft into the scene--but don't worry if there is no exposed node to snap the new craft into place because the root part is buried between parts, this is where the next step comes in), place it into the scene as a "ghost" (no attaching to the main build craft), REROOT (keyboard #4) THE GHOST CRAFT TO ITS DOCKING PORT, which will expose the port's node on the working end, then snap it into place on the docking port of the main build where you plan it to dock, in the orientation you want it to be docked (WASD, or use the rotation gizmo (#3) after placing). You'll know it's zero-zero aligned when the faces of the two docking ports "reflect" each other; e.g., the faces of the Jr. ports are "kissing each other" literally --> <-- . If they're not, you will need to adjust the placement of either docking port in its parent craft to the right orientation. Alternatively, when you build the crafts involved, build them as one craft, making sure that where they dock they are properly oriented and the ports are mirroring each other, then break the build craft apart and save the parts separately by using the reroot function. (Reroot to Craft 1's planned Root, delete Craft 2 from its docking port down, Save; reload the main build, reroot to Craft 2's planned Root, delete Craft 1 from its docking port down, Save). Alternatively alternatively, if you're okay with it you can download DockRotate which allows post-dock rotation of docked ports (and their attached crafts) and do it by eye post-docking. For non-stock ports, you'll have to inspect the part to see if they're non-symmetrical. One nice tip is to use the rotation gizmo in relative (I think) mode: the ring's orientation is fixed to the XYZ axis definitions of the part and you can use this as a guide for aligning the axis of the port relative to their parent craft. End of the day though, zero-zero port alignment really is just that the ports "mirror" each other graphics or design-wise when docked.

Hiya Nils, I would agree with technik here in that a mobile GC part would be dandy. I'd probably suggest though, in keeping with allista's concept for GC that available space per kerbal in the workshop dictates their efficiency/productivity, I'd probably disagree with using the lab module as a workspace (else it'd have to be limited to two engineers only), but maybe make the module expandable like the KPBS Mk2 Habitat/Greenhouse/Lab, and/or similar to camper vans and trailers that unpack/expand for use, so that at least it contains the same total volume as the KPBS GC workshop. I'd however state, technik, that, while the GC workshop is quite mismatched to the FUR profile, with some creativity in offsetting, a few additional mods, and by rethinking about the architecture of your Mobile Construction Vehicle (we're going to have to act, if we want to live in a different world [Frank Klepacki intensifies]) it can even look somewhat decent. If I may suggest? The idea here is that the MCV is the workshop and batteries only (as well as living quarters modeled in using the crew cabin, especially for life support purposes), while Matkits are brought down in disposable USI containers to the construction site by skycranes, and hooked up using KAS. So you wouldn't have to worry about Matkit tankage onboard the MCV, especially if you're constructing something a very wide ground base that is past the 300m limit of GC (wait, there's a limit? Or are we talking about distance of workshop from kit-efficiency of construction here?), if you can bring the Matkits in separately and dispose of the tanks afterwards when there's no further need of them. For a FUR-profile resource tank to hold the Matkits needed while still being reasonably within the size profile (e.g., a FUR fuel tank), and have enough kits to construct a megabase (like a hundred thousand Matkits) you'd be towing a lot of trailers, that it'd be more parts and space-efficient to just use the largest tanks you can get out of USI/NearFuture/Configurable Containers (instead of the rover tanks from FUR/Buffalo or Bison, for example) and bring them in separately. Not even the basic GC Mobile Workshop can hold that much Matkits for what I think you're trying to suggest, even if all the internal tanks were converted to Matkits. Trust me: back in 1.4, a Minmus megabase I built required THREE of the 3.5m USI Matkit Kontainers (the one that look like shipping containers, not the circular one like up above there), and I picked the 3.5m profile only because making a skycrane for the 5m profile Kontainer was a nightmare. And I think I had required two KPBS GC workshops so I could get it done fast (as in a week's work). Not that I'm disagreeing with your petition to Nils to include a FUR GC workshop, Nils, he does have a point there. But in order to keep to allista's space-use philosophy while giving the FUR GC workshop the same efficiency as its KPBS counterpart, we'd have to either reduce the number of kerbals inside, or make it an expandable campervan to match the KPBS GC's internal volume. And admittedly, I haven't even thought of the possibility that GC isn't programmed to take into account expandable parts, unless it is possible to establish the efficiency of a part independently of any formula? EDIT: also a good idea to include Matkit production in FUR's ISRU (I can't recall right now if FUR has a drill and ISRU, but if it does, then yes, KPBS already has a setup made for OSE after all I think?). Alternatively, technik, you can ModuleManager patch it into the appropriate FUR part with the appropriate module provided in GC's config files that plug the functionality into the Squad ISRU, you'll just have to get the ratios between the Squad ISRU and FUR ISRU right to make sure it isn't too OP. I know I did one for the Mining Expansion's S3 ISRU, but I cannot locate that patch anymore (and I think the functionality was already patched in by suicidalinsanity in the MEx mod, so I didn't have to anymore nowadays).

Hiya Stone, thanks for getting Wyvern up to speed again! One issue I found after testing the part, the IVA seems inverted vis-a-vis the pod's control point orientation: (The navball being "upside down" when the pod is maneuvered IVA is rotated heads up). I'm not sure if this is a mod conflict or not? (RPM is the adopted version as you suggested.) Edit: One thing I notice however is that the door on the IVA matches up to the door on the exterior model. Only thing is that when the part is loaded in the SPH build scene, it appears "door side up" which usually gives me the impression the door is on the "upper"/dorsal side of the craft in a horizontal flight/SPS orientation, similar to how a cockpit canopy is the "up" of that part. And that is reflected by the door side oriented towards the sky blue in the navball above.

I can also confirm this for 1.9.1. I don't recall that development or curation was ever passed from CaptainKipard or anyone else, and the one I'm using is from a user's unofficial hosting (I don't know if he made any changes) from my last post a couple years back. We could try asking one of the present "professional" mod curators (linuxgurugamer or zer0kerbal) if either is interested in trying to get in contact with CaptainKipard about this. (And also if he or at leat the present license will allow a 5m and 7m UDP to be added to the set--I've been missing those lately.)

No worries on the question, if there's anything anyone can answer, we do try. I think this one though can be asked as well to allista over at the Global Construction thread, to find out how far the Ground Construction (which he built up) and MKS modules interact. But my suspicion is that GC just isn't equipped to handle MKS's distributed logistics logic. It'll only read resources (and crew) in the vessel housing the Workshop for purposes of construction, although maybe (and I haven't tried it yet admittedly, plus I run GC independently without MKS so I'm speaking from this experience) you could team up other workshops in nearby vessels on a single kit project once it gets going (I had gotten it going with workshops in the same vessel, so that is a go).

Don't we all appreciate a good function when we see it? https://github.com/UmbraSpaceIndustries/MKS/wiki/Modules#weight-distribution The link should take you to the list of modules the MKS system uses. I think you're looking for USI_IntertialDampener. I think? Further context: the module should be transplantable to a part by patching, maybe. I recall seeing ground tether in the Offworld Rocket Pad of Kerbal Hacks (the one with asphalt tiles).

Admittedly I'm running a mod heavy run, also KIS/KAS (but IIRC Rover never intended any integration between them and Konstruction), but this is what it looks like on my end. I also confirm it was this way back in 1.4, and in fact trying this out on Minmus led my insurer to jack up my insurance premiums on all Minmus operations faster than a Falcon Heavy can yeet a Ferrari into Pluto (translation: hilarity with momentum). As noted, there is the Magnet Strength slider in the PAW, and again I really don't think it would be the case that KIS/KAS is adding it, I believe it should be inherent in Konstruction. Can anyone else confirm if they've got the same PAW as here, just in case?

Just to rule out some preliminary stuff, sorry, are you also seeing a Magnet Strength slider in the PAW, and is there juice in the batteries?

Yep! Actual propellers (and rotors). And with 1.9, the blades have independent pitch variance for differential collective and cyclic control (meaning they can torque the aircraft on their own, even without relying on SAS torque). (Yeah, I kept the SAS on because I'm lazy that way ) Whatever black magic the devs did in getting all of the physics to work in such compressed physical and temporal space, it works (To be fair though, stock bearing-based rotorcraft have been on the market, I think even before Breaking Ground, so even then the game could handle rotating lift surfaces, maybe that's where Squad got the idea, all they had to do was make a part to rotate said blades. And I was running my game on default physics timeframe settings, that didn't get touched at all in Settings) And it can get crazy in there: each rotor can have up to eight nodes for blade attachment. As to whether an autopilot could be developed to handle BG rotorcraft or VTOLs... okay, I promise I'm not pitching for the feature from TCA. Rotorcraft like this versus how TCA handles thrust-based VTOL craft are an entirely different kind of flying altogether, and we're quite thankful with the suite we have with TCA as it is. As a thought exercise, though, one shortcut I think could help for programming such an autopilot is to just leave RPM at a set rate when on, then just vary the blade pitch to vary lift. Then it's just a question of adjusting pitch to change lift force to achieve the desired vertical speed for a given vector of lift, similar to how TCA in VTOL/surface flight mode would vary thrust to achieve target speed whether in hover or moving to target. Although in my experience, I get faster responses mixing RPM and blade pitch adjustments, but then again that might be down to me personally feel-gutting the rotorcraft maneuvers. This is just a thought exercise though, I really really promise. And that goes for everyone else reading this too, please, no pressures at all!

I recall in the past that Firespitter based propellers might work--then again I only used the electric prop from that set. But my suspicion is that the props and rotors that use Firespitter (is KAX still active and working?) model them as thrust based engines and that's why they can be read by TCA. (Notable in that the FS electric prop for example, if I'm remembering the past right, is being read by RCS Build Aid in engine torque measuring mode.) I am not sure that the BG rotors are ModuleEngine based, and even if they were, the implementation of them is rotational, not linear. And BG rotorcraft, like non-DLC stock "props", work on the basis of (control surface) "lift", not engine thrust. A whole new set of logic is required that accounts for RPM and prop pitch, plus cyclic/collective when enabled, against instantaneous prop lift rating and vector vs aircraft weight/gravity for an autopilot to get the most out of them. At least, that's how it feels to me when I'm testing rotorcraft performance. In that sense, thrust vector vs aircraft vector is way simpler. There are a number of other props (or proplikes) out there that I think are not Firespitter based but may also be using an implementation of ModuleEngine. Suggest try downloading them and see if they would work out--e.g., Buffalo/Heisenberg, not sure if the Mk2 expansion also uses FS or not...

Using the wrong containers. Those containers are from Breaking Ground and are designed to be used with the ground deployable science experiments. The KIS containers are those that have the "Inventory" button in their PAW and bring up a wholly different interface for cargo loading. Also there should be a separate category called "Containers" IIRC that has all of the KIS containers.

Will existing crafts with the old scanners will still work as they used to pre-update, and only the new parts will use the new mechanics, or will crafts carrying the old parts after the update be carrying the new mechanics as well? (I guess this may also apply to other mods with SCANSat functionalities, e.g. your own science pack where the experiments double as SCANSat scanners--will they carry the old mechanic or the new (or not even work at all) if I update just SCANSat to the latest?)