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

It think it may be double-toggle issue. It's a pair (or group) of symmetrically placed parts, so that if you click deploy in parts manager both are affected, right? If both parts are assigned to action group with toggle action, it seems to fire twice and not do anything. If you leave only one part toggle action in the action group - they should deploy and retract normally. (but if this symmetry behavior gets broken by docking - you'll have to reapply the action for the second part to work). Still a buggy behavior

Went investigating options for payload recovery with a shuttle. Found out 2.5 meter docking port can hold 40+ tons even on ascent by the side. that's good. Practiced docking a bit. Wrote addition to a bug report on struts and docking. sounds not too promising. There seems to be a way to dock the payload without completely borking the shuttle. However, the payload loses its struts on deployment and becomes quite bendy... Tried flying with it in such compromised condition. Turns out it is still landable if I go gently about reentry. Don't pay attention that while troubleshooting the main gear (half of them got stuck!) I ended up touching down on a taxiway... and forgetting to deploy the nose gear... and sliding off the taxiway as well. Also, intakes somehow decided they are in the payload bay and I had to open the front section in-flight to ignite the jets I'm not so sure anymore if this still is Heavy Recovery Orbiter or if it has evolved into Huge Ridiculous Overkill

OK, another test - and it's even weirder. Same shuttle, different payload (this time probe-controlled). The payload is attached to 2.5m docking port on the bottom of the bay (so both root part and probe core of the payload are 90 degrees to the shuttle's cockpit) The moment I undock the payload, the struts on the payload break (those are struts within the payload. incidentally there are no struts between the shuttle and the payload - the docking port can hold sideways 43 tons through ascent!) Now, here are several options I tried after undocking the payload test a: control from payload. flip it 90 (end ports) or 180 degrees (opposite middle port) and redock to the port on the bottom of the bay. struts on the shuttle are intact. but if the payload is then undocked again - struts on the shuttle break test b: flip the payload the same as in test a dock to the same port, but controlling the process from the shuttle. struts on the shuttle break the moment the payload is docked outcome stays the same whether the shuttle is controlled from the cockpit or from the upwards port test c: maintain the attitude control from the payload redock the payload (with end port) to the port in front part of the bay results are identical to test a test d: maintain the attitude control from the shuttle translatejhh backwards and redock the payload (with end port) to the port in front part of the bay results are identical to test b - struts break on docking test e (intended mission profile simulation): quicksave after releasing the payload and load control from the shuttle. redock the payload just as it was. struts on the shuttle break again test f: quicksave after releasing the payload and load control from the payload. redock the payload just as it was. results identical to test A quicksaving and reloading after redocking doesn't help with struts breaking if the payload is undocked again so far, it seems like this has something to do with how the structure is handled on docking/undocking and whether the root part orientation changes - but the logic is quite weird.

Deployed a telescope. Caught a pile of bugs. Filed a bug report on all struts breaking loose. A bit more detailed mission report here:

Preface: it was a huge mess this time. Starting with planning to swing by another orbit and grabbing a certain thing to bring down - but the preliminary testing showed that that fuel tank is impossible to secure by a docking port alone. (Might still investigate a bit different payload design design. HRO is perfectly landable with a heavy payload.) Ending with being unable to land the ship due to a weird structural failure, to the point of redoing half the mission and filing a bug report The payload revealed TLDR - a fancy telescope and a full hive of bugs

Reported Version: v0.1.4 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz | GPU: NVIDIA GeForce RTX 3060 | RAM: 32 GB Version: 0.1.4.0 Severity: Medium (can render the vessel unusable, but can be circumvented by changing mission profile) Consistency: Consistently reproducible, but under particulate circumstances Here's the the relevant picture of the payload bay: The intended mission profile at this point was as follows (the mission is STS-3 from Shuttle Challenge): redock the maneuvering modules (the ones with Kerbals in the seat) to solar panel assemblies (packed on the bottom on the bay) use the maneuvering modules to extract the solar panel assemblies and dock them to the telescope (released from the shuttle just before the screenshot was taken return the maneuvering modules to the shuttle and go back to Kerbin The problem appeared on the first step: the moment a maneuvering module was docked to the up-facing port on solar panel assembly (with control point of the resulting assembly becoming the command seat), all the struts on the shuttle were broken. No matter how many times I reloaded, the struts kept breaking. And let's just say without the struts this shuttle falls apart under its own weight even on gentlest landing But then I found a solution that worked: Release the solar panel assemblies. Catch them with the maneuvering modules and dock them to the telescope. Return the maneuvering modules to their original place in the payload bay If I do exactly this and return the maneuvering modules to the backwards ports in the bay (control scheme still switches to the seat, which is backwards relative to the shuttle) the struts remain intact. But if the maneuvering modules get docked to the upward-facing ports the solar panel assemblies were docked to - the struts immediately break. (No matter how many times the game was saved and reloaded/restarted between deployment and return of the maneuvering modules). Probably needs double-checking/verifying on different vessels, but the craft file is in attachment if anyone wants to replicate it on this one. Just get it to orbit and experiment with the maneuvering modules (the RCS modules might need to be switched on through part manager) Included Attachments: HROSTS3.json

Welp, I managed to rebuild my HRO shuttle (it involved tons of yelling at VAB technicians. Maybe even more tons that the vessel lifts). More details here: P.S. fun part about hardware - I was going to replace my 7 years old pc (bought it when KSP1 stopped properly working on 4 GB RAM), but after comparing it with what's for sale in the similar price range... I ended up replacing RAM and graphics card. It was exactly "What do you mean I can plug this stuff in my old motherboard??!" (as for CPU, what's the point of more cores, if most stuff can't fully use the ones I have?) Although, after getting the graphics card, I spent another week getting the power adapter for it. Even managed to buy a wrong one that looked identical, but did not fit.

Well, I haven't flown these in quite a while, so might as well start with basics, given how much flight testing such vessels require. Pilots, Engineers and scientists, I present you... Heavy Recovery Orbiter! Wait a second, isn't this the good old HRO just with new paintjob? Yup, it totally is. And it's such a pain in the S to make it not fall apart with this new VAB. To be completely fair, I'm not exactly satisfied with VAB in KSP2, especially with what it takes to get symmetry working properly. But HRO flies again.

Well, I recently found myself messing with my good old crew shuttle Hydrargyrum. Originally, it turned out capable of getting to Mun orbit and back to Kerbin. Or with an orbital refueling at either moon go full Kerbin - Mun orbit - Minmus (well, nearly anything can land there) - Sun orbit - Kerbin route. And with over 90% refund due to full reusability. Even made a cargo version for running recovery contracts. Here are both shuttles and their launcher: But running tourist contracts around Kerbin gets a bit boring, especially after you unlock everything (and unfortunately it requires almost entire tech tree and couple millions for part unlocks and building the shuttle - even if 49% of launch cost is refunded in less than 10 minutes!) So I tried refueling it at the Mun orbit and... getting it down there. Even if it never got any special implements for landing anywhere except Kerbin. OMS engine was sufficient...https://imgur.com/ElmVsxMhttps://imgur.com/ElmVsxM But today I went a bit overboard. It was meant as crew training and tourist flight using previous expedition's landers, but a certain lander would require a bit too many trips there and back, so after refueling at Ike... are we sure this is how you fly a shuttle? And... Honestly, I didn't really expect this to work.

The way kOS handles it, vessel:position returns the center of mass. And the coordinate system is ship-centered, so for current vessel ship:position=v(0,0,0) Not the most obvious thing, but that's how it works