Tallinu

I'm sorry if it sounded that way. There's only one "complaint" and it's the very first paragraph, and it's in regards to what I assume is a normal behavior for the plugin, where it disables gimbals and re-enables them depending on throttle state. The issue has to do with that feature's implementation: Because the plugin controls the gimbal locks via the same toggle the player would use, you lose the ability to manually control gimbal locks (at least via the usual toggle). Since this appears to be "working as designed" behavior and there don't appear to be any errors to report, I did not consider it a bug or expect the log to be of any use. And the rest of what I wrote was simply an attempt to provide as much information as I could about the nature of the behavior I was "complaining" about and to describe my attempts to work around it. I don't remember whether the "show actuation toggles" option I used to do that is available in a stock game, which is why I mentioned TE. Oh, and the comment about a gimbal limit slider is just irrelevant wishful thinking, as in "wouldn't it be nice if the game had..." (Sorry for getting sidetracked and confusing the issue.) As for the Bobcat, that's a stock part from the Making History expansion, not a mod, so I just assumed you'd be familiar with the name (sorry again). It's apparently implemented with two separate gimbal modules -- I guess they couldn't give it roll control authority (as a single central engine) with just one module. I mentioned what I'd learned about it in my experiments because I thought the fact that the plugin only locks/unlocks one of those gimbals might be something you'd consider a bug. I don't know if any other engines actually have multiple gimbal modules, so maybe it's just an edge case that hasn't come up before. Either way, since one of them does get automatically locked/unlocked, the plugin clearly is "working," it just doesn't take into account the possibility that a part might have more than one gimbal module. The issue should be reproducible by launching any craft using an engine with a gimbal and attempting to manually lock any of its gimbals while the engine is running. The gimbal setting in the menu immediately changes back to unlocked and the engine continues moving in response to yaw/pitch control input. In the case of the Bobcat, providing yaw/pitch/roll control input while the throttle is off and looking at the engine and the part right-click menu, you should see that one nozzle still moves and the second gimbal hasn't been auto-locked (and can be manually toggled, whereas the first gimbal option will instantly switch back if clicked on, as previously stated). I ended up removing the plugin because I really needed to be able to lock some gimbals on a mission I had in flight (and couldn't use the workaround of disabling the actuation toggles due to being in flight already). But if you can't reproduce this, let me know and I'll reinstall it and create a log (would you want one where I'd launched a craft and moved the engine around? Just at the main menu? Or what? I haven't seen any error messages regardless of what I tried).

It seems like this plugin makes it impossible to lock the gimbals of certain engines the normal easy way, whether during flight or in the VAB. If you try to lock a gimbal while your engines are active, it instantly resets back to "free," and of course if you try to toggle it while engines are shut down they just go right back to "locked." Surprisingly, tweaking the gimbal range down to zero in the VAB (with Tweakable Everything) doesn't seem to have any effect either. (That seems to just be broken in general, but it most likely doesn't have anything to do with this plugin.) The only thing that does work is to use "show actuation toggles" and turn them all off. This may also be a Tweakable Everything feature though, I'm not sure. Sadly there is no "gimbal limit" slider available in flight that could be used to easily adjust them on the fly in the same way that engine thrust can be scaled for more precise burns... While investigating this I also discovered that this plugin only affects one of the Bobcat's nozzles, and the other still moves. This seems to be because there are two separate gimbal lock options on its menu (and a different, "0-100" gimbal limit adjustment -- which only affects one nozzle?!) and in the action group editor there's an entire extra set of gimbal-related options, one for each nozzle. Using these I was able to get both its nozzles to stop moving by toggling all six actuation toggles in flight, but that can't be done for both nozzles in the VAB.

Ah, thanks! I think the wording of "non-resettable" must be what confused me -- as in, "But why can't I reset it? How is that a good thing?" I guess it really meant "non-resetting" as in "it doesn't get reset when you switch away from them." And the hotkey in #3 is just a way of setting more than one of them to do that en-masse.

Sorry if I'm being dense, but what does this mean?

I am indeed playing Career, although I would expect the recovery of science and/or Kerbals (where applicable) to function in the other modes.

I'm on KSP 1.7.3 with SR 1.9.1.3 and RecoveryController 0.0.3.8 and I have a couple of questions. 1: I don't know if this is actually a feature that Stage Recovery is supposed to have or if I'm remembering wrong. I thought that in the past I had been able to drop an upper stage or payload from orbit back onto a suborbital trajectory and have the mod recover it for me while I do other things (assuming it met the parachute, heat shield, and/or propulsive landing criteria of course), but recent attempts haven't even resulted in a "stage destroyed" message, as if the mod just isn't handling the event. It works fine for stages jettisoned as I launch a new vehicle, but it seems like once something has achieved orbit it stops paying attention (or at least doesn't generate the expected messages). 2: It was also tricky to figure out just how many parachute modules I needed to attach via docking ports to successfully bring down an older "space bus" craft for recovery (which was replaced by a larger model with better crew capacity and more delta-V). When attaching the parachute-laden probes to the old design in the editor, SR treated each of them as separate stages (even though no staging was enabled on the docking ports), and stubbornly kept telling me that the main craft was 0% recoverable. I had to replace the docking ports with structural connections and/or move the parachutes onto the main craft in order to figure out how many were actually needed. At first I thought that the parachutes all being on these docked probes might be responsible for SR not recovering the craft after I dropped it out of orbit, but then I realized that it still should have generated a "stage destroyed" message if that was the case, so it's probably just a separate usability issue. It's easy to find out if something like a docked escape pod ("MOOSE" etc) has enough parachutes to land safely by simply detaching it from everything else, after all, and I just keep coming back to that after trying to think up any use case that would require the current treatment of docking ports. I understand that it might not be easy to do anything about, but it would be a "very nice to have" feature/tweak/whatever if there was a way to make it treat unstaged docking ports in the editor as being one stage instead of separate stages and base its diagnostic report on the combined unit. Thanks for keeping this mod going, and all the others you maintain -- I use quite a few of them!

Alright, sounds like either there's a bug in MM or it's an intentional change and the documentation hasn't been updated to reflect it...

... But... if a mod is installed... then why would its "modname" not exist in step 2? Regardless of whether or not the mod uses FOR[MyModName] in all of its patches. Assuming it's installed properly, of course. From the very link you posted: The first and third bullet points. It has examples right after that. Although the DLL is called "Scale.dll" instead, "TweakScale" is the name of the folder out of GameData, so that should absolutely exist. Granted, the advice he gives about making sure of that by using FOR at least once is sensible, and making all of them use FOR for consistency (and to allow BEFORE to work) would also make a lot of sense. But AFTER, at least, should still be working right now, at least for TweakScale, even if its patches don't currently include a single FOR.

Ahh, I had suspected saved craft files might be susceptible too, that's why I checked the ones I'd made recently! I can see what you mean about the problem spreading between users. However, it sounds to me like there's an easy preventative measure. Any time you download a craft (from KerbalX or anywhere else), open it in the editor, and then simply save it, without touching anything. (After having the TweakScale update installed, of course!) That should trigger TweakScale's module duplication fix, and ensure that the craft file you have on disk is now a "safe" copy, whether or not it was "tainted," right? Which is why you said people needed to switch to all their ships (via tracking station, etc) to get them to be loaded up and then resaved in the persistence file. However, this is only necessary for craft which contain parts suffering from duplicated modules, right? Because those are the only craft which could be affected by TweakScale resaving them in a way that prevents future corruption when the module cache ends up fixed (has its "sanity" restored). So, it's not that every craft must be activated and resaved (in flight or in editor), it's simply that all craft which contained duplicate modules on some part must be. So in my case, my saved craft and persistence file contents shouldn't need to be resaved. (I'll still run through the important ships and stations in flight just to be sure, and I'm resaving all of my recent craft files even though they're mostly stock parts that were unaffected! Can't hurt to be safe, especially for the craft I was posting in case others liked them.) Ahh, now I understand what's causing those type and default scale entries to get doubled up. Thanks for pointing these out, @Tonka Crash! And for the explanation of the ordering: Wouldn't this be true only if the mod was trying to use :BEFORE[TweakScale]? If TweakScale's included patches run at step 4, and :AFTER patches in the last part of step 5 for each mod, doesn't that mean :AFTER[TweakScale] still runs after TweakScale's patches? Either way, it sounds like adding the % signs at least, and possibly using :FOR, would be good preventative measures to take. It might avoid some cases of a mod's included patches (being overly simple and/or not understanding exactly how to use the proper directives) conflicting with TweakScale's, since if they don't have any ordering directive they'd be applied first, and TweakScale's patch (being written with this possibility in mind) wouldn't introduce any problems (which wouldn't have been introduced in any case by patches from the mod itself). Does that seem reasonable?

Okay, I believe what you're telling me is that if any of my active craft (the ones saved in the persistence file and any quick saves) contained parts which suffer from this module duplication issue, "fixing" the duplication before installing the newest release of TweakScale would have caused the affected parts to experience issues like zero mass and other nastiness, regardless of whether or not their scale had been changed (simply the presence of the broken duplicate module is enough). Is that an accurate summary? Assuming that is true: Since I have not used any of these parts (the parts in which I found module duplication in the cache file) in any of the craft I've launched so far, none of my existing craft should experience any problems, regardless of what I do (because none of the parts they contain have duplicate modules saved). But now that I have installed the new version of TweakScale, it will prevent the duplicated module in those parts from eventually corrupting any craft I might launch that use those parts, because it renames the extra module to something else which won't overwrite the correct settings in the first instance of the module. Therefore, with the new version installed, I should be able to safely use any parts which are affected by that duplication, without having to try to manually fix hundreds of lines in the cache file every time I install or remove or update an mod (which happens frequently enough that it isn't really feasible). Correct?

How do you know for sure if you are affected by the problem? That doesn't seem very clear to me. None of the craft files I have saved recently seem to have any duplicated TweakScale modules, but when I hunted through my ModuleManager.ConfigCache file I found some parts where this was the case, matching what you showed on the GitHub issue even down to the duplicated type and defaultScale settings in the first module. The affected parts don't seem to include any that I have actually used in my craft so far. And as I said, I didn't find any evidence of this issue in my saved .craft files. Does that mean I don't have to worry, and once I install this TweakScale update, there won't be any problems if these corrupted extra modules do get added to things in the future? I actually don't use TweakScale very often, funnily enough. I'm usually able to do everything I want without changing part scales. The only thing I can really remember doing most recently is increasing the size of the micro landing legs one time when I needed longer legs for a lander but only had those legs unlocked, and that craft was recovered a long time ago.

The Klaw is the (official!) nickname for the Advanced Grabbing Unit, in the Actuators (160) research node. It's capable of latching onto other vessels/parts without needing a docking port on the target (and can latch onto asteroids in order to stay attached while mining or moving them). (Ninja'd!)

You can actually change which direction they point their helmets by switching camera modes using the V key (pretty sure that's the default). In "Orbit" mode, "up" is north as bewing said. But in "Free" mode, "up" is away from the planet, and pressing space will orient EVA Kerbals that way instead. If your target is significantly above or below you in one camera mode, or you're having trouble getting a grip on a ladder because of the target craft's orientation, switching camera mode may make it significantly easier to maneuver to or around your target.

Right. I just didn't understand that when you said "this is a special case" you were referring back to this constellation setup again, rather than orbit segment time scaling in more general terms, which is where my mind was leaning (as in that last paragraph) as I'm learning how these things work. I always understood intuitively why the TA of 90 was needed in this case, even when I was originally describing it wrong, lol! It needed to be symmetric, with the AN/DN equidistant from both Pe and Ap. Anywhere else would not put the nodes in the right place, the orbital plane would be tilted around the wrong axis, and sufficient error would prevent 100% coverage.

Actually, the biggest issue I'm addressing by having all four satellites be deployed by a single carrier vehicle (second to interplanetary encounter/capture) is to get the correct relative timing between the four satellites. Each must reach apoapsis at a different time, staggered by 1/4 of their period and in proper sequence. Deploying them from a lower circular orbit that makes 1/4 less than a whole number of full orbits in that amount of time allows each satellite to arrive at the target apoapsis from its deployment burn with the correct timing, raise its periapsis and tweak its period to be as accurate as possible, and from then on remain synchronized with the others, even as they all later perform their inclination changes -- the orbits are fairly high even at that point, so the delta-V cost of doing inclination last was acceptable. A small lightweight relay satellite can easily have 2000 to 3000 delta-V with just a few oscar tanks and a spark engine, though relays meant to reach Kerbin from the outer planets would by nature require larger, heavier antennas (or arrays of them) and therefore more fuel and thrust -- although a better way to go about it, especially around Jool, would likely be to have a pair of large, powerful relays as the main link back toward Kerbin, while small satellites with RA-2 antennas like the ones I've been experimenting with provide local coverage of each moon, bouncing signals around to reach the larger relays as needed. Really? Let's see, the SMA given in his thread is 3,625,000m and according to the wiki, Laythe's SOI is 3,723,645.8m and its radius 500,000m. So that's 5/6 of Kerbin's radius. Scaling 4,350,000 by that factor does indeed give 3,625,000. Despite the fact that Laythe's SOI is vastly smaller than Kerbin's, that result is still lower, but the orbit isn't circular, so... Okay, I think I finally found what I need to do to figure out the Ap and Pe (to center of mass) from eccentricity and semi-major axis. Google was all like "Here's how you calculate the things you already know!" Eventually found https://jtauber.github.io/orbits/017.html and managed to piece it together from various pages there... Focal distance c = a * e 3625000*0.28=1015000 It looks like Pe = a - c/2 3625000 - 1015000 / 2 = 3625000 - 507500 = 3117500 And then I think Ap = 2a-Pe 2 * 3625000 - 3117500 = 7250000 - 3117500 = 4132500 Dang, it's less than 10% outside the SOI! And for the most interesting and science-rich of Jool's moons, too... Well, that one will just have to make do with three equatorial satellites. Anything landing on the poles will probably be able to see the strong primary relays north or south of Jool. A set of three of those, equidistant in a polar orbit, should ensure that one or more are always visible. Indeed, I was just thinking that as I read the previous paragraph. (Also: I get that reference! High-five! ) Good, I had a feeling it was something like that. And now I'm confused. I'm not sure what the difference is, compared to what you said earlier in that paragraph. How does "being Pe" or "being AN/DN" change anything, compared to going from, for instance, 30 degrees to 45 degrees TA on two orbits with the same eccentricity but different periods?