RaccoonTOF

Is there actually any way to access the internal "biome" data even (edit: without physically being directly in/over the biome in question that is)? I started playing around with this mod just before the For Science! update, looking ahead to when the biomes would be important info to have - unfortunately the OS "biomes" aren't actually useful at all for science locations, as mentioned above. But I also can't seem to find what resource the game itself is using to determine biome location either, so not even any way to "pre-generate" a biome map, like you can with the visual maps, that I can figure out - could be a nice "halfway" option between the currently completely useless (though pretty) biome maps, and actual precise biome info for exact coordinates - do the current "biome scan" and it slowly overlays the rough orbital "biome map" like it does the low-detail visual-map currently.

Also keep in mind that not all science experiments are simple, free, one-click-and-done affairs. Some take time spent continually in a particular biome (like the atmospheric experiment, and to a lesser extent, surface sampling.) Others have an ongoing resource drain when being run (currently only EC that I know of, but plans for future experiments after the ISRU stuff is implemented could certainly include other specific resources - perhaps even "using up" the results of prior research experiments, like the above mentioned surface samples). Simplifying it to automatic might "make sense" now with the extremely simplified experiments we have currently, but it would be a headache to not have the manual interaction down the road...

It's also possible that the COOLING mechanics are not working as intended, contributing to some of the perceived HEATING effect issues. My last launch, I was riding the very edge of part immolation with my nose-mounted docking port during ascent (fairings still being useless, and no shielded ports available yet in the tech tree). After finally achieving orbit, I expected it to cool off within a few orbits or so at most - but instead it was still giving glowing orange (though not red) overheat warnings all the way through TLI and well through the actual flight, only finally cooling off a few hours before Mun INTERCEPT...definitely seems to be holding heat much longer than it should be.

Even at 1500m/s, at 55k or so on ascent, the stock lander capsule will explode, behind fairings or not. I'm sadly back to just making single-ship launch/travel/lander/return systems again, rather than attempting to duplicate Apollo-style landers in KSP2 for now. (EDIT: And I don't even want to get started on the issues facing independent DUNA lander systems currently...)

It doesn't help that parts which SHOULD be shielded, are not being shielded - especially an issue are lander (or other "space-rated-only" parts) that are behind fairings/payload bays/etc. Re-entry heating on your mun excursion isn't really an issue, when the lander blows up in the fairings during ASCENT...

Just a minor niggle: When using the resonant orbit tool, you are using the semi-major axis as the altitude for synchronous orbits, not the adjusted altitude. Haven't checked the semi-synchronous orbits, but the other altitude-related burns and calculations appear correct.

Yup, that's what I meant by my edit above, but good to know you found out why it fails on the target tab too

So, good news is that targeting docking ports works great now. Bad news is - setting new AP in the Target Relative Maneuvers tab doesn't seem to work at all. It seems to accept the entered value - but actually sets the node to the default 200km Ap regardless of the entered value. EDIT: Note that it works fine when done on the Ownship Maneuvers tab, it's just the Target Relative Maneuvers tab that it fails.

Manual install working fine, but could not find it listed in CKAN at all. It does not even show up as a manually added mod in the CKAN modlist for me. Are we still just waiting on repo updates, or is there something else I am missing here?

Still having issues where if selecting a specific part on another vessel (such as a docking port for docking) ALL tabs vanish. Even after docking/undocking, it does not restore the functionality - although selecting another "valid" target does bring them back. Any way that it can treat individual parts-as-targets as being the same as targeting the vessel itself?

No I get that, I just have never had an ascent profile (other than suborbital sounding rockets) that just burned straight up for long enough that it would matter (nor can I see an actual use case for such, since that is just about the LEAST efficient means of achieving orbit - even a very draggy craft will still benefit from having a significant portion of the delta-V spent being "forward" rather than "up", even if that pitchover doesn't occur until later in the launch than a streamlined craft). Basically, I can see the theoretical issues involved - I just don't see any actual practical scenario where it actually makes much difference for a real ascent profile...

Sometimes you need to go back a "stage" in the fairing construction, and start from a slightly wider diameter (especially seems to be the case when going around landing legs/wheels, and radial-attached engines for some reason). Even though it seems to visually clear the boundaries of the parts, the game doesn't always treat it as such. Another thing to be aware of is that to "complete" the fairing (capping it with a nosecone, instead of leaving a circular opening at front) it appears you need to bring it down to minimum diameter in the final "stage" of construction, before clicking the button to finalize it. If neither of these helps, try posting an image of the craft both with and without the fairing construction in place (or better yet, a full craft file).

This can occur with any maneuver, though it is definitely most common with maneuvers that are not pure pro-/retro-grade burns. The maneuver marker TRIES to always point the direction the burn needs to continue in to result in the expected pre-burn planned outcome. The issue comes in that it is an instantaneous update, and thrust and actual reorientation of the rocket takes non-infinitesimal time. The same issues can be observed with extremely long low-thrust standard pro-/retro-grade burns - it's just that the margin of error is usually significantly (sometimes orders of magnitude) smaller for inclination changes.

I realize that once actually having an established orbit, "Radial Out" and "Up" can be vastly different, as you described. I was thinking of during the ascent specifically though - I've not encountered the nearly 90 degrees swap you've described before - "Up" and "Radial Out" are usually within a few degrees of each other when it transitions from surface to orbit mode (much like the "Prograde" changes during the surface/orbit shift as well, and usually by about the same amount.) I suppose I've just never flown whatever specific ascent profile you are looking to do, and so I've never really noticed any extreme differences as you have described (again - only referring to the ascent here; as you've described already they are quite different in an actual established orbit).

Just about the exact opposite of most vehicles I build (I overbuild just about everything, with goals of maximizing kerbals/cargo carried in one flight...) but I do love to see the capabilities of minimalistic craft such as this. Very well done!