darthgently

What are the conditions under which ZeroMiniAVC would fail to prune a MiniAVC.dll file? I found some strays in the KIS and KAS subdirs and manually moved them to .pruned status

Is it a scanner that requires daylight? I'm not certain but I think if the sat is on the dark side and the scanner requires daylight then it may do that. Never noticed. I just let it scan and go run some other missions for a few weeks until it is done. Patience is the key Kerbal Alarm Clock can be a great friend when scanning. Just ballpark when the sat will need attention and set a time based alarm

On occasion. I got munarly lithobraked at 80+ meters per second the other day when I got up to do a quick chore. Pulled up the quicksave from right before engaging Landing Guidance and manually landed just fine so not positive what the issue was. I had come back to the game just as it slammed into the surface and I read a vertical speed of -86.xx m/s. I suspect that RCS had turned itself off and mechjeb couldn't get it to orient properly and lost control. The RCS mysteriously turning off is nearly always the reason Landing Guidance goes off the rail in my experience. Accuracy aside, it mostly works for me but I definitely have to babysit that RCS functionality. I don't know why it gets turned off sometimes by either mechjeb or something else, not sure, idk. TL;DR -> watch that the RCS stays on and turn it back on if it goes off, if your craft needs it for control authority I've also has situations where even though there is plenty of opportunity to land where I targeted, it wants to land me hundreds of kilometers downrange instead. It just brakes way too late. Again, I'm not sure this is a mechjeb issue. It might be getting starved of processing time or something by something else

Thanks for the info, I'll start coloring outside the lines in this regard and see what happens. I'm not certain, but it seems like, with asteroids, that the moment you get a second connection from a separate vehicle, even one with vague control authority, latched onto it the task becomes much, much more manageable as the flexing and whipping nearly always evaporates once I've done this even when the second craft isn't placed well and has very little torque or thrust capability given its position, angle, connection quality (grabber with one "toe" in the target etc). Almost as if the code tosses you a bone just for getting the second control point latched on. I'm not sure if a great connection that also targets CoM is really required in this sense at this point. But one still needs the main engine thrust in line with CoM at some point to get decent braking for placing asteroids into orbit

The problem with coming up with a default ExtensionRate is that "too fast" or "too slow" depends on how massive the object that the legs are attached to is and how massive the body of the surface is and that is unknown information for the default parts file. My gut tells me is that you want to keep the rate lower than escape velocity, ha ha, so that puts one limit on your tuning. But keeping it below the equivalent to thrust-to-weight ratio of 1 would seem to be a good start. The bottom line is that depends on the mass of the craft you put them on and the mass of the body you are deploying them on. You can also just use RCS to push the craft down while they deploy if they are too fast, but this can mess with accuracy of the autodeploy iirc if it ends up bouncing. Also, be aware that if you use tweakscale on the legs, then autodeploy is not a viable option. Autodeploy uses the unscaled size to determine autodeploy leg length based on slope and direction of the location. Scaling the part does not properly scale this calculation. You can always dive into kOS and code your own autodeploy algorithm, or to merely calculate and autoset the ExtensionRate if it is accessible in the PAW and to kOS (idk about that)

Yes, I've pondered that button many times. Welcome to the world of KSP. Make sure you F5/quicksave a lot. And get to know various was the save files are stored, you can back them up at the command line just like any file. The timestamps are the only real "index". The .../saves/default/Backup directory will also save your bacon on occasion.

1) Me too. 2) The only ways I've found is to a) type in the LAT and LNG into mechjeb for land at coordinates. I get the coordinates using the small scansat window and right clicking on the spot (right click zooms in and centers the window on that spot). The LAT/LNG displayed at top of small window are the center of the image, so zoom in until it is accurate enough for you. It will certainly be more accurate than mechjeb (100m at best). Then there is b), use the "click on map" button in mechjeb, then click on the planet in map view as close as you can to the spot, which is going to pretty far off probably, then adjust it using the fields and arrows in the target coordinates for mechjeb and using the target indicator (which appears after you select target by clicking on planet in map view) in the small scansat window as a guide.

I mostly dock on my own, but there are times when I'm docking several tugs to some big thing with a short window of time and I use MechJeb docking to ease the brain burden. But the biggest use case for this is asteroids but I can't use the current Docking Autopilot for that. What would be great is if the Docking Autopilot worked with the Grab units as a control from and targeting CoM were integrated into it also. Has this been, or is it being, considered? Thanks for all you do. Let me know if you have a coffee fund

Question: what are the ways that the science in the backpack experiment storage unit can be returned to Kerbin? Does it have to be on a kerbal or with a kerbal when it comes back? Can it simply be mounted on a probe that spashes down and is recovered? I did the last and didn't get a single science point out of the deal. I'm guessing I lost a few thousand points

They are in Duna orbit, and show as such, but the asteroids they are finding are all behind Duna so statistically are not going to be encountering Duna within the current orbit (unless really elliptical and catching it on the other side from the sat, I suppose). Thanks for responding, btw, much appreciated

Excellent, thanks, i just need to be more patient. On another thread someone just told me that only encounters in the current orbit show and since all my Duna sentinels were recently launched and are behind Duna so far (the inner one should pass it soon) that they haven't seen any asteroids that could encounter Duna in the current orbit yet

Will the Tracking Center display non-Kerbin encounters for tracked asteroids? I've got over 1000 tracked now, many in Duna's neighborhood and yet I never see any of them displayed as encountering Duna. I have a contract for orbiting a Class C around Duna and just want to know if I'm looking for information I'll never see in the tracking station. Thanks!

You can also consider how much power they use and how much they cost, and what are the other altitudes that other equipment on the craft will require. The SCANSat equipment seems to divvy up in to high altitude "passing through" survey category, and a low altitude (deeper in the gravity well) more suitable to a more focused interest where a lander and rover might be involved. I've never found the distinction all that useful personally and don't do the "passing through" thing and don't care if I have to start at a high altitude so I just use whatever is available that works best for me. I send in one sat, start at the highest altitude required by equipment on board in a polar orbit, then drop down as required to get scans for other equipment. When all this is done, I put the sat into a highly elliptical/vertical polar orbit with the planet at the bottom or top foci and the other foci way north or way south and use it as a solar system wide relay (because I put big long range antennas on it in prep, or added them later using KIS/KAS). I mention all that because you might want to consider the uses of the polar sat once the scanning is done and polar long range relay for any equatorial sats, and planetary bases/craft on the surface when the polar sat is in view, is a common re-purpose of a scanner sat. And this may also affect what scanning equipment you choose given weight and cost etc.

Will do, thanks!

Combined with DeepFreeze and one of the life support mods, this could be a great game challenge.

I get that remotetech, if installed, should require a connection to change the programming on the freezer units, but I find it very hard to believe that a civilization capable of doing a freeze/thaw wouldn't have simple timer based thaw functions on the units. You know, like microwave ovens and alarm clocks? If I still messed with RT that would be a deal breaker for me. In fact, any information that the ship computer/sensors would know of, like time, or an SOI change, should be enough to wake the crew, or at least, in KSP, allow the player to wake them without a remotetech connection

This may not be a KAC specific question but I'm not sure. It happened with KAC so I'll ask here. Some how during GUI lag and trying to drag the KAC popup window I managed to elongate/resize it to an overkill width that takes up most of the screen. I can't figure out how to get it back to normal size. It is only oversized for the ship that was active at the time I ganked it. I was incorrect, it is oversized everywhere now. bleah

If cryogenic pods are introduced to stock then aging would fit in stock. Otherwise, they are little green immortal frankenhobbits. A mod that only added cryogenic pods and aging is probably the most likely approach

Autoboarding a ladder doesn't make much sense because there are too many ladders and rails near hatches and airlocks. Having EB ignore the ladders makes a lot of sense. Personally, for game play, I'd rather have a separate button in the PAW for ladders with the option to "Clip in", just like rock climbers, sailors, and real astronauts do. So you grab the ladder, then clip in, at which point warp is safe. It would be frosting if, when clipped in, the kerbal is bumped off the ladder, he is restricted by a tether from going far. In fact, the lack of tethers is really a big deal for realism. ( I keep trying to remember to try to use a KIS/KAS winch cable for a tether and if the kerb gets in trouble he can use the remote control for the winch to pull himself in )

I have zero understanding of that dev environment. Well, maybe not zero, but might as well be. If the API provides a call for Kerbal.BoardSeat(seat) and it doesn't work, then any other solution is probably no where near as good as someone somewhere fixing that API call, lol. Hello Squad? a quick additional thought: no matter what method you use to set the occupant, it is surely a good idea to continue calling BoardSeat for whatever else it may do right. Additionally, you might want to code with someone fixing that down the road in mind and not do the reflection unless an occupant doesn't get set. That way you don't have another problem emerging when the reflection technique ends up tangling with some future solution. That is all shotgun in the dark though. You clearly know a lot more about the context than I do. I'm just throwing out what I see as "rules of thumb" type stuff

This, in hindsight, clicks. Mechjeb has not been as stable as normal lately, pushing me deeper into the kOS fold. The link gives an "Access Denied" message, btw

After multiple reloads without it having an effect (this has been going on for a few days), I just tried "leave seat" again and it worked. Just another Kerbal struggle.

Quick question: I'm trying to decide what node to spend some science points on. Do the Extensible Crew Tubes allow resource transfer? Thanks!

Maybe reloading the scene has helped in similar situations, but not this one.

FYI, when typing into a kOS pop up terminal, typing underscore character on linux [RShift][-] triggers the [Alt][-] behavior for Hullcam. I'm not sure if that is a kOS issue, or a Hullcam issue, but one would not expect chars typed into the popup terminal to affect things outside the terminal. I'm mention it over on kOS also