Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by LameLefty

  1. 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.
  2. 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.
  3. 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:
  4. 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.
  5. Do it. It’s worth it.
  6. 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.
  7. 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.
  8. Not all heroes … etc. That would be fantastic.
  9. 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.
  10. 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.
  11. 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.
  12. There are multiple threads on this bug since shortly after release. I was hoping it would be fixed in Patch 1 but it wasn’t.
  13. My best and most common use for it was to dock to arbitrary docking port locations on large, multi-port stations. I would typically have an orbital refinery/propellant depot station orbiting places like Minmus, Ike, and Vall. Each station would have anywhere from 4 - 8 radial docking ports and two axial ports (one on each end). I would dock things to these stations that may themselves not have their docking ports on the nose - for instance, spaceplanes with those neat little extendible ports that close up under covers. DPAI allows me to abstract away a lot of the confusion and turn docking into a couple of very simple visual steps, no matter which docking port I’m targeting.
  14. We might get something basic, as we ended up with in KSP1 at the end, but in the meantime, there's a mod for that and it works very well.
  15. Sent another mission to the Jool system, this time landing on Vall for the first time. While I was there, and since it will be almost a Kerbin year until the next return window and since my transfer vehicle has dV to spare, I decided to orbit Pol for the first time in KSP2.
  16. Not without glancing in multiple places. And since the Target marker in KSP2 is the same color as the attitude indicator, using the navball alone to dock is visually cluttered and unintuitive. I've done a few dozen times in the last 3+ weeks, but I don't like it. And we get that you're not a fan of Navyfish's DPAI. Great and good for you. But I'm with the OP here. I haven't made a docking without it in KSP1 in many years, and I'd be using it today if it was available for KSP2 or was part of the stock docking system.
  17. The problem with this in KSP2 is that in Target mode, relative velocity displayed on the navball is not signed - that is, no positive or negative value with the velocity, so it's not intuitively obvious whether you are closing with the target or increasing separation. The DPAI mod in KSP1 puts that number right smack in the UI of the mod widget window, so you can tell at a glance are you adjust your velocity vector exactly have fast you're closing or separating. The KSP2 Target mode would be more informative if they at least added a sign to the value. But it will never be as intuitive or easy to dock using just the navball (especially now that the thing is parked in the lower left of the UI) as compared to DPAI.
  18. The Munarches are on the scale of like 200m tall. For comparison, the pic I posted last evening from Duna, my ship is the new large lander with a methalox tank and a 2.5m Mainsail engine and those giant legs. The cabin is 12m AGL so the feature in the photo is several dozen meters across east-to-west and north-to-south. It's also substantially taller than my 12m lander. The ... other features ... on Minus, elsewhere on Duna and on Tylo probably 50 - 100m tall at least. They render in at around 30km. People have posted techniques above - very low orbits, pausing and moving the camera around looking for them.
  19. I adore this mod in KSP1 and docking without is slow, tedious and not nearly as intuitive. I would love for something like it to become stock in KSP2, or if Navyfish could port it to the new game. Even more than the fact that it makes aligning docking ports and velocity vectors completely intuitive is the fact that you can target off-axis docking ports (such as radial or zenith/nadir ports) on any module and the process of aligning velocity vectors and managing closure rate is exactly the same.
  20. I hope so, but in the meantime, there’s an excellent little mod that works very well.
  21. This evening I spent a lot of time trying to locate an old, old favorite spot from BITD ... This is an original anomaly, but relocated to a new place. If you don't want to see, don't un-hide the spoiler.
  22. Gah, the Face on Duna was a real PITA to find. With all due respect to @enzo_schmitz, the Map view shots weren't high-res enough for me to find it easily. I must have made about 20 landings in different little valleys and plains to try to locate it. Whew.
  23. Returned my crew from Ike, after first spending several months in Duna orbit conducting observations waiting for the return window. I eyeballed a Pe past KSC in an attempt to land closeby but overshot by about 35km in the end. The first phot shows the transfer stage braking into Kerbin orbit, where I eventually left it, intending to refuel it and use it on future outer-system missions. Unfortunately, after recovering the lander, I checked the Tracking Station and it had been affected by the bug that separated vessels sometimes affect each others' trajectories. Somehow it had left its 200km circular parking orbit and was set to reenter and crash. I just destroyed it from the Tracking Center instead. Guess I have to launch another one for future missions.
  24. I launched both parts of this vessel into LKO separately. First was the LH2-fueled SWERV-powered transfer stage, and then the methalox-fueled lander. Docked in LKO, transferred to Duna system and made orbit around Ike. Undocked and landed on Ike, then took off, rendezvoused and docked again, and after messing around in Duna space, headed back to Kerbin. I made orbit around Kerbin and separated the lander from the transfer stage. After undocking the staging was all confused and showing no available dV despite the propellant tanks having plenty. I fiddled around by creating and deleting some dummy stages, dragging the engine into one of them along the way. Somehow, the engine ended up being duplicated in the staging list even though there's only one engine on the lander.
  25. You need to work on your system cooling, seriously. Hello from Ike orbit at 1440p with everything cranked up to max.
  • Create New...