Alchemist

Yeah, I guess secant is really more understandable in terms of "burn prograde at periapsis to raise the apoapsis" or "burn normal at descending node to match the orbital plane" than constantly fiddling with the start point as well. Timely start combined with dynamic burn prediction would be the best of both worlds (KSP1 and current KSP2 systems). As for the optimal integration mode, I'm not fully sure which one is the best, as both delta-v integration and end-velocity comparison have potential to get quite off if you drift significantly off the predicted path (although with dynamic TWR burn planning getting too off is not as easy as with KSP1 instant burn calculation). Also, combining end-velocity with dynamic long burns needs some smart accounting for gravity... Speaking of integration, here's another idea which is only applicable for ejection burns, but should be the ultimate answer for interplanetary transfers: velocity at ejection - similar to end-velocity, but aims to match the velocity (relative to current celestial body) at leaving SOI, rather than velocity at given time moment. But just comparing SOI-edge velocities doesn't work until you are already very close to desired trajectory, so it's more along the lines of "by how much I need to change my current velocity to have the desired velocity at the edge of SOI" (disregarding exact coordinates or time of SOI leaving: just matching ejection vector is typically more important if you're slightly off the initially predicted trajectory).

I second this. Additionally, I would propose the option to override TWR. It's all cool that it can take into account TWR changes during long burn, but it's not always what we aim for. Sometimes we just need to predict a maneuver vector to then prepare for it. I would imagine following set of switches: TWR: Dynamic - what we seem to have now. Also, switching to this mode should update engine status every time (in case you switch something on and off). Current - assumes current value constantly. Custom - input any value. Maybe you're planning for another vessel. Instant - KSP1 style, no integration, just instant change in velocity. (it's your own decision what to do if the burn gets too long). Burn mode: Direct - current option. Start from maneuver node and keep pointing in the same direction (as set from the initial trajectory at the point of maneuver) Secant - start half the burn before maneuver point and keep direction (as set from the initial trajectory at the point of maneuver) Relative - start from the point, but the vector is set in relation to the momentary velocity (like keeping prograde or keeping normal) at each moment of the maneuver (in instant mode should still integrate the way speed change affect further burn, just disregarding the ships movement along the orbit). Integration - to see how much still left. No, not the timer, give us a proper remaining delta-v reading as well! Projection - integrates the total delta-v spent along the maneuver axis. Does not react to off-axis component (if your thrust is off-axis or you turn too sluggishly - it's your problem). Full integration - adds all non-gravity acceleration and compares to maneuver vector. can adjust the remaining maneuver vector to account for any deviations from intended direction (For relative burn mode might require a bit different algorithm, like integrating vector-relative deviations). End velocity difference - KSP1 method, with maneuver vector being the difference between current and desired end-orbit orbital velocity at this point of time. (might not work for relative burn mode). Example of advanced application: a low-TWR transfer to Moho from LKO. (based on what I found most efficient in KSP1 for a heavy nuclear-powered mothership - but fully utilizing all these features) Step 1: Set maneuver mode to Instant TWR, Direct burn and Projection (so that maneuver direction stays constant). Calculate ejection maneuver vector (using prograde, normal and positioning along the orbit - feel free to add as much normal as necessary, you won't waste delta v on it in the actual burn) that gives you desired interplanetary trajectory. Step 2: burn prograde for a short time when passing by the node over multiple orbits, repeatedly raising the apoapsis until you get it to several thousands kilometers (at which point you can can go hyperbolic on the next pass Step 3: now use normal/antinormal at apoapsis to adjust the orbital plane with the ejection vector. Step 4: Set mode to Dynamic, Relative, Full integration - and recalculate with mostly prograde burn starting short before the periapsis - you should be able to find a solution that will give you about the same interplanetary trajectory you planned for. Step 5: just execute the burn! (And yes, this elliptical spiraling is more efficient than circularly spiraling outward because of Oberth effect - unless you're trying to move interstellar ship on ion engines, that might not have TWR even for this).

Continuing with trying out Shuttle Challenge in KSP2, this time the payload is... Apollo-style Full report here:

Alright. The next mission of what looks doable at the current condition of KSP2 is... something I actually haven't done in KSP1, but quite a logical stepping stone before long-range operations. Also this is already approaching the limit of the particular launch configuration (because I deliberately went for lighter launch assemblies for shorter range missions - the full-scale option would be reaching the LKO with nearly full internal tanks). Today, we are going to the Mun, but not with the entire shuttle. And now it's time to release the payload Commander Valentina Kerman steps upon the dusty munar soil. "No ladder? Who needs it if you can jump this high even without the jetpack!" The lander looks like a pebble from up here... We'll leave Val and Bill to check out the Mun. Meanwhile, Jeb has a reentry to aim. Meanwhile on the Mun... And this concludes the STS-5T mission. Although, to be fair, if we're bringing the shuttle that far, might as well go into orbit and skip the CSM part altogether. Reentry-capable reusable craft going to munar orbit and then handling the crew recovery from there would likely be a more optimal approach at this point.

Actually the craft files were already linked in a previous message: Oh. nm then Thank you.

That's the thing. Launching 2 instances of the same model at once results in complete loss of struts on the second craft launched. But launching one of them and then the other model, results in this on whichever is launched second: This is on the part of the orbiter that was taken from one model and directly used as the basis for the other (the launch assembly was attached independently and doesn't suffer from this cross-model effect). Even more, when this appeared, I tried reconnecting the affected struts in the VAB (as in, taking one end off and putting it back), but this effect still persisted as long as the other orbiter is in the world somewhere.

Yeah, we all can agree that autostruts going across half the vessel aren't always realistic and might be not the greatest option to counter wobbly rockets. But there are certain scenarios when in real-life assembly there would be extra structural integrity added between parts even without attaching external structural beams or notable extra mass. Reasonable limitations to effect: Same rigid element - no auto-connections going across decouplers or docking ports or (as future possibility) movable hinges - anything supposed to come apart at some point would still require specially placed struts if more rigidity is needed before that. Direct proximity - the maximum distance (as placed in the VAB) between collider surfaces should be no more than a certain value (maybe certain percentage of the larger part's size). This will only ever need to be evaluated in VAB, no crazy in-flight collider calculations needed. Contact length matters - side-by-side across full length should be stronger than barely touching near the ends. This, actually, should apply to directly surface-attaching parts as well (could be as extra connections along the contact line). Some options when it could come into play: Parallel stacks (with no decoupler in-between). For example, some tanks surface-attached to center stack and then longer tank stacks built off them. Or 1 to multiple stacks splitters/adapters. These stacks, running within touching distance of each other are 100% logical to be welded together without need for additional struts. Stack-attaching through several thin parts. The most common scenario is when under the decoupler (or a docking port) there are several parts like probe core, reaction wheel, battery - and only then go the fuel tanks. The decoupler should have some connection directly to the tanks through the thin parts. And, while auto-strutting shouldn't go across the decoupler, the decoupler placed below a shrouded engine should transfer most force not to the engine but to the part above it. Landing gear, legs, wheels. Should auto-connect to any parts within a certain range (could be larger range than in other cases) of the attachment point. Like landing gear right next to where a wing is attached to the fuselage should transfer the force to both the wing and the fuselage, no matter which of them it's placed on.

It's still there in 0.1.4 - and I found another plot-twist to that. I have a pair of shuttles sharing most of the airframe - but with serious change of the tail section of the orbiter. If I try launching two of the same one at once, all the struts are broken, but if I launch one shuttle and then the other model, the second one is missing like half the struts on the orbiter (in many places one of symmetrically placed struts is there and the other is broken). And this isn't limited to getting them to the launch pads at once - I had that issue even when loading second shuttle while the first one was already in orbit. If anybody wants to test this behavior, here are the craft files: https://drive.google.com/file/d/1um_jcsRYRCw-NQiElMuRt-rHllj899iv/view?usp=sharing https://drive.google.com/file/d/1NIPwbFr0iwR-sek9I9Ciu04PyRYMcXY0/view?usp=sharing

@Anth12 I kinda didn't backup the original broken file, but since it's 1 simple edit, here's the restored version of that: broken save As a fun note, switching between the affected "landed" craft and the tracking station can nullify the groundspeed. And then it falls down. (edit: although, I previously had a case when a craft with same missing trajectory symptoms suddenly had its speed nullified on exiting timewarp when I attempted to fly it back to KSC anyway) Also, here's the fixed version I continued from: fixed save Note: yes, the affected active craft is still on suborbital trajectory, but reaching orbit doesn't fix the state. It was meant to rendezvous with the other shuttle in the higher orbit - hard to plot that when you don't have an orbit displayed. The events preceding to the bug were as follows: first launch attempt went normal, but then I remembered I forgot something, reverted to VAB, added another part and launched again (that included timewarping on the pad to catch the target's orbital plane) - and then during the ascent I found the trajectory missing. So the moment I was out of the atmosphere I made this quicksave and tried reloading - which didn't help until I tried editing the save. Other things probably related to the bug in question (found in both versions of the save): a launch clamp on the pad displayed as orbiting in tracking station the affected shuttle's external tank frozen in place above KSC - the tracking station claims it's orbiting... with 0.00 m/s speed.

Flew 2 HRO shuttles (different variants) together. The game didn't like it too much. Barely got them back home.

Now we have a modified configuration to test out. HRO-M03 is equipped with cargo ramp to deploy payloads on planetary surface. Of course, that also means a serious overhaul of the engine section. Also, equipped with a slightly heavier launcher configuration - that would be needed for longer-distance missions Wait a second! Who mishandled the paperwork, mixing documents for the two variants?! Why is there a crew of 8 on a shuttle that hasn't been fully reentry-tested? They were scheduled to fly on the other HRO shuttle! Now add another crew cabin and send it after this one (meanwhile, let the crew preform the full-scale in-orbit tests). In the light of the issiues uncovered on previous 2 missions, docking was not attempted, opting for EVA transfer instead. And mission complete! Ok, I think that's enough strut failures. Until this mess gets a bit improved, no more dockings or multi-shuttle flights. Will need to see which missions are less RUD-prone.

I recently caught the same bug with a cargo ramp. But after sending the craft to runway and then reverting back to VAB, the slider was there. At least the issue doesn't seem persistent.

Interesting thing I found about this bug (with orbit not displayed, the issue persisting on saving/reloading and vessel displayed as "landed" in the tracking station): I just got a newly launched vessel in this weird "landed" state. So I opened the save file in text editor, found the affected vessel and changed "Situation": "Landed", to "Situation": "Orbiting", - and it actually fixed it! Ah, one more thing, one of the launch clamps left on the pad was counted as "orbiting", while the actual vessel was "landed" for some reason. So could be status updating going to the wrong vessel. But how the heck it it fails to update even on reloading the save is a bit beyond me.

Finally managed to find a way (through all the strut issues) to do the one thing HRO is designed to excel at. Payload recovery. From here to here Full report here:

And finally, after so much stumbling into bugs I feel like an entomologist, the fuel pod recovery mission was finally authorized. But first, we had to deploy a new fuel pod, because the old one was impossible to secure. (Attaching it by the end resulted in in swinging through the cargo bay, attaching by 1 meter port in the middle just couldn't hold the weight, and multi-docking is apparently not a thing in this version. Also, the old one got non-retractable panels by mistake, but that's a dumb mistake.) Incidentally, the 2.5 m docking port in the middle (perpendicular to the force acting on it!) is enough to hold 43 ton payload during ascent. No struts between shuttle and payload. Deploying to the same 350 km orbit as last time. And... it loses struts on deployment. Will have to be gentle to not shake it apart. Alright, now to launch the actual mission. Anyway, payload back in the bay. Payload recovered