LameLefty

Better shown with an example. This button should illuminate (change color) or act as a toggle or SOMETHING so that when I look at the part detail, I can tell at a glance that the part is serving as the control point for the vessel. Right now, you can click on a pod, probe core, docking port, whatever and all the button does is flash green as you click. But after the click, there's no way to tell which part in the UI widget is the control point. Changing the button color or making the button into a toggle switch instead would indicate clearly and instantly that the part is the control point for the current vessel.

Sent another mission to Duna per the current Weekly Challenge. Also, testing out my "standard" compact lander for Duna - needs some tweaks but it works.

I have that mod but haven't used it yet. Before I started using my massively-overpowered SWERV transfer stage design, I did have to resort to the Infinite Propellant toggle in Settings to have enough dV to correct the SOI transition error when returning from Jool to Kerbin. But I shouldn't have to. I've been playing KSP for literally more than 10 years as of this week (v0.19 on Steam March 21, 2013 per my Steam purchase page). I know how to do a Jool (or Duna, or Mun/Minmus ...) return burn. And my trajectory is utterly perfect before the SOI transition but completely wrong afterwards, I know there's a mathematical error going on in the game.

Please @Nate Simpson and KSP2 Team, if you do nothing else this weekend, please read this (confusingly and inaccurately) named thread - a lot of our independent bug reports have been merged into one thread and the title hasn’t been changed to reflect that. Please, for the love of Jeb, see for yourselves: plot a return trajectory from Jool, make the burn as precisely as you can, then screenshot the trajectory BEFORE you leave Jool SOI. Then leave Jool SOI and see how that perfect trajectory is completely and utterly wrong the instant you leave the Jool SOI. Something is getting changed during the SOI transition (probably a mathematical error). In my case, for instance, I am ending up with an AP higher than Jool’s own orbit (which should be impossible for a burn retrograde to Jool’s own orbital path). Others can repeat the same or similar experiences trying to return from Duna, Dres, etc.

There’s a lot of unwarranted optimism in these polls. Maybe if KSP2 lasts as long as KSP1, in 10 years (*) PCs capable of 1,000 part ships will not be uncommon, but until/unless there’s a fundamental shift in the architecture and how physics and lighting are calculated and rendered, it’s not gonna happen. (*) it was March 21, 2013 - 10 years ago - that I bought KSP and my MacBook Pro i7 struggled with 150 part ships. My current PC (i7-11700KF) can run those same ships at 120 fps.

Yes. Most of it is GPL3, some modules may be GPL2 or MIT License. https://github.com/MuMech/MechJeb2#license The code is on Github and Sarbian’s site too, I think.

If you do enough navball-only dockings (as we had to do from the time docking ports were added until Navyfish created DPAI), then it will have clicked anyway. It's still much easier and more intuitive to use the mod, especially if you align the roll axis as suggested before starting to align the velocity vector marker with the target. THAT step alone makes the actual closure-and-dock procedure a dead simple matter of just tiny little X/Y axis RCS burns using the keyboard docking mode controls (IJKL) plus H/N as needed to increase or decrease closure rate. If you're patient, you can dock using a ridiculously low amount of monoprop.

So noted real-life rocket launch photographer extraordinaire John Kraus captured this wonderful image of last night’s Relativity Space launch of their Terra 1 mission. The second stage failed to ignite and so the mission failed to achieve orbit, but the first stage seemed to perform nominally. To the point, this is what 9 small methalox plumes actually look like at sea level.

They were eventually added in KSP1, so I imagine it’s on their detailed internal roadmap to add eventually here too. I hope. It was a fun challenge to land on the VAB or whatever from high altitude, and it made for a fun way to deal with a falling apart airplane or spaceplane other than reverting the flight entirely.

No, please for the love of the Kraken, just … no.

Agreed. We have this but I have not yet tried out the updated version: I don't mind using the existing Maneuver Node graphical widgets to rough in most burns, and this to fine tune it: But I hate running the risk of screwing it all up be my fumble-fingers or missing the start/stop cues.

Fantastic! Pretty sure I have my old copy of that one around here in a box somewhere, too.

This is one (of many) things MechJeb does really well in KPS1. You can specify the precision required of the total dV added when you you ask MJ to control the burn through the maneuver node, and the code reduces the throttle at the end to try to hit that requested precision with good accuracy.

This thread is giving me flashbacks to my own undergraduate aerospace engineering degree (mumble mumble) years ago. Good job!

I disagree - please see my photos and read my posts about this. I made my Jool return burns on nearly the “perfect” optimum phase angle and with nearly the same dV as suggested by the long-standing available KSP transfer window calculators. In every case, the results of the burn show a nearly perfect Kerbin return transfer, exactly as expected based on a decade playing KSP. As soon as I leave the Jool SOI, the trajectory morphs to something physically impossible, including an Apoapsis greater than the orbit of Jool, which indicates an mathematical error occurs when translating the relative velocity as one passes out of the planetary SOI.

I have not encountered errors great enough to notice when leaving the SOI of any planetary moons for the SOI of the parent body. By contrast, I have encountered the issue repeatedly on transfer burn from inside one planetary body to another planetary body elsewhere in the system. Interestingly, the errors seem *much* greater when burning retrograde from an out-system body moving in-system. This past weekend I transferred from Kerbin to Duna, and from Kerbin to Jool. In both cases, it required well under 100 m/s in correction/refinement burns to setup a good encounter. However, the converse was vastly different - in both cases, I needed substantial correction burns to create proper Kerbin encounters for the return, Jool requiring about 730 m/s, Duna needing closer to 300 m/s. I also disagree with the notion that the error is the display of the trajectory within the SOI rather than being associated with the change of SOI itself. In the case of my Jool return experiments, I have been returning within hours of the calculated optimal phase angle, and my plotted maneuver node burn ends up within 20-30 m/s of the optimal burn to setup the encounter back to Kerbin. After that burn, the trajectory looks absolutely perfect, a textbook KSP planetary transfer of the kind of I have been making for literally a decade. AFTER the SOI change, however, the trajectory is completely borked, including an Apoapsis higher than the orbit of the planetary body I’m leaving, which is physically impossible for a retrograde return burn. To me, that seems very much like a mathematical error occurs during the transition between SOI’s, and the magnitude of the error increases the further out-system it occurs.

Trajectories - especially escapes from Jool and other bodies headed in-system toward Kerbol, are badly broken and have been since before Patch 1. Here's an example from tonight. Here's my return from high Jool orbit (past the orbit of Pol). This is AFTER my burn but before I had departed the Jool SOI: Yet right after exiting Jool's SOI this is what I ended up with:

This is the mess when you try to return from someplace as far away as Jool back in-system: Here's my trajectory AFTER my escape burn but before leaving the Jool SOI. Background: I was in a near-circular high Jool orbit (221,000km or so) after leaving orbit around Pol. FWIW, this was a near-pefect "canonical" departure burn of about 1,200 m/s. Yet somehow, after leaving Jool's SOI, and despite burning entirely retrograde to Jool's own orbital velocity around Kerbol, this is what I ended up with. I was able to salvage this one with about 700 m/s a few hours after leaving the SOI, followed by a ~30 m/s midcourse correction about halfway home to get a close Kerbin periapsis and better inclination for the entry.

Do it. It’s worth it.

I haven’t been to Eve since before Patch 1. But I’ve returned from Jool and the final trajectory after leaving Jool’s SOI was absolutely nothing like it should have been, as it was depicted post-burn but before leaving the SOI. As in, I needed to add over 1,100 m/s dV in subsequent burns to get the same Kerbin encounter I should have had after the initial burn.

For any vehicle with a reasonably-good TWR and where orbital altitude isn’t changing rapidly, I’ve found the burn timer to be pretty accurate. But those caveats above matter: if you’re burning out of an already-eccentric orbit, especially down low near the foci of the conic, the timer isn’t very good. Similarly, if you’ve got a low TWR and you’re in a low orbit where the burn time takes more than a small fraction of your orbital period, it’s not very accurate. I haven’t noticed any particular issues with radial-antiradial/normal-anti normal burns at all. For me, the single biggest issue I have is when I’m burning to leave an SOI. The resulting trajectory after leaving the SOI just seems wrong. It’s usually not completely off for me leaving Kerbin’s SOI for Jool or Duna, for example, but it’s TERRIBLE leaving an outer system for a body closer in. Kerbin to Eve, Duna to Kerbin, or Jool to Kerbin burns have all just been flat wrong once leaving the initial SOI.

Not all heroes … etc. That would be fantastic.

No, that’s actually multi-spectral imaging data. There’s also reams of data from Shuttle flights (both multi-spectral imaging as well as engineering development test data from internal and skin sensors); as well as USAF/DARPA blunt-body, lifting body and ICBM RV entry imaging and engineering data though most of that has been “sanitized” for ITAR concerns. Sorry to burst your bubble, but I’m an aerospace engineer by education and early career and not just making stuff up.

That’s … not true at all. There is plenty of non-classified imagery of re-entering spacecraft from NASA’s WB-57 aircraft, plus a lot of scholarly data available on re-entry heating and plasma from university, NTRS and DTIC sources.

If you can extend this to control the burn for ann existing maneuver node, that would be great. Having to rely on my own fumble-fingers and senses of timing to start/stop a planned burn is a pain.