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!

Just a guess here, as I've had similar issues previously - make sure you have a decoupler between the upper docking port and the LES, and stick a small probe core on top of the decoupler as well. Then make sure that the LES probe core is the root part before launching. Currently, it appears that ANY docking ports above the root part can cause issues, as can control parts below engine plates. Not sure exactly which part of the "fix" actually fixes the issue, but this is the approach I've been taking lately and since doing so, haven't run into this issue further (though still plenty of issues docking/undocking once you get to space...but at least it launches and stages correctly now!)

Similar issues with landing legs at times (and especially the largest size ones for some reason). Also seems to randomly occur at other times than just on launch pad as well - just recently had a craft in orbit of Kerbin (Lander that had successfully launched, with its transfer stage still attached, but waiting to dock to carrier ship) lose two of its landing legs AND one small stabilizer just by swapping between the carrier craft and the lander (no collision, still well over 1km apart, getting ready to close for rendezvous and docking). Reload of save did prevent the random detaching that time, but there have been other instances where I've had to relaunch the craft entirely.

"Radial Out" basically IS "Up" when in orbit mode. Other than the name being different, is there a particular instance where setting SAS to "Radial Out" doesn't perform the same maneuver you would expect from "Up"? (I suppose there might be some strange edge case, possibly involving spaceplanes with 90 degree rotated probe/cockpit controls?)

I reported this as a bug through the launcher already as well - and it appears to be particularly bad in my case, as I keep getting repeated copies of "main menu kerbal" and his/her "disassembled craft" spawning over and over again as persistent debris... I reported this as a bug through the launcher already as well - and it appears to be particularly bad in my case, as I keep getting repeated copies of "main menu kerbal" and his/her "disassembled craft" spawning over and over again as persistent debris...

Not a Bug - Read the description of that part more carefully. It is in fact a methalox engine, that just happens to respond to RCS inputs instead of main throttle.

Yup, I'm regularly not getting the crew recovered with the craft - good thing that all of my vessels have probe backups anyway at least...

Will try to get pics uploaded tonight, but on a very limited (aka kbps instead of Mbps) connection at the moment, but the basic issue was very obvious on my end at least. Don't recall which was which, but the 1.875 cylindrical fairing (that appears to be just a rescale of the 2.5m cylindrical fairing at the moment - I've not seen the new one Daishi has been teasing included yet if that IS supposed to be there) was either far too large or far too small (especially in vertical height) and the opposite was true of the 1.875m conical fairing. Again, I'll try to get pics tonight, or at least note down which was off which direction. The much bigger problem is the solar panel mass code spamming the logfile though, leading to slowdowns as the log file size grows, until eventually leading to a halt or at least totally unplayable simulation rates (only solution currently appears to be not to use those fairings at all - same issue occurs whether the panels are enabled or disabled when the craft is constructed). Edit: 1.875m Fairing (Payload Variant) which is based apparently on the 1.25m fairing (4 primary bays) has appropriate diameter scaling, but is nearly double the vertical height per bay. 1.875m Fuelable variant (5 doors) also appropriate diameter, but about 1.5x too tall per bay. 1.25 to 1.875 conical bay (5 doors) is too short for either 3 or 4 bays, but too tall for 2 bays (the other conical fairings are all 4 bays tall I believe). https://imgur.com/a/HJpp1lh

There are quite a few problems with the latest iteration of payload solar panels - currently I'm just avoiding using any of the parts that have them as an option so as to avoid the issues, but hopefully they will be fixed again soon since that rules out quite a few useful fairings at the moment

Getting massive log spam from the new mass-adjusting code on the fairings with solar panels enabled - drops FPS to incredibly low levels: {excerpt from log} USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.521] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.521] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.521] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.523] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.540] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.557] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.574] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.617] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.633] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.649] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 [LOG 09:28:30.665] [Universal_Storage] USSolarSwitch.GetModuleMass, SolarCellMass: 0.02 {end excerpt} Would include link to complete log but...well, it's over 220MB. If it IS still necessary I can try to get a minimalistic example with just a few seconds of flight time and hope that ends up a managable size... Also the scale on the current 1.875m fairings is drastically off (though I'm guessing this will be moot once the new model is done?). And still not seeing that wonderful lander-frame-part progress

Oh I'm well aware that it isn't usually an issue - I've been using RCSBA for something like 3 years now, and I've been happy with imbalances of .01 or less. It wasn't until I started recently building complex, multi-launch, relatively lightweight but large ships and using EEX to try to get them as perfect as possible that I even noticed the issue. But yes, it IS definitely the issue as reported - if you read the edit of my last post, you can see that if I build a craft that is theoretically perfectly centered but RCSBA shows as off-balance, it is indeed centered in flight. However, if you actually DO shift the CoM (without changing anything else, done with a part-clipped test-weight in that case) so that it zeroes out according to RCSBA, then it DOES get noticable pitchover (actually, yaw-over?) in flight. Mind you, as I said, I've been working without that level of precision for years now, as until I started messing with the really fine-adjust tools in EEX I had no choice but to do so. And if it all comes down to a floating point error in display, then yes, it's probably not worth the effort to correct it - simple enough to use reaction wheels to counter the effect when under engine thrust. I'm rather curious as to why the offsets for RCS ARE more accurate than for engines though, even at higher levels of TWR/distance offset (the above test vehicle with 800kn of RCS thrust all arranged around the bottom of the tank still showed 0.0 torque in the "forward" direction, without the 0.001 error that the 206kn liquid engine gave. Then again, I suppose that is likely because I usually have RCS placed in symmetry that would tend to cancel out any floating point errors, while I often don't with engines...might need to do more clustered engine designs for the finicky designs mentioned above.)