Jump to content

schlosrat

Members
  • Posts

    597
  • Joined

  • Last visited

Everything posted by schlosrat

  1. I think that @cfloutier has a bunch of plans for future K2D2 improvements, but right now he's pretty busy with an overhaul of the UI. One of the things that he and I have talked about a little is improvement in the landing autopilot. My thought is to have FP offer a deorbit burn node that would put you on a collision course to a waypoint or lat/lon surface coordinates, and then for K2D2 to do something with the waypoint or lat/lon to try to bring the landing down more precisely to those coordinates. I don't know if cfloutier might have any thoughts on how to handle staging on the way down. My approach has personally been along these lines. If I've got a transfer stage with some fuel in it and would like to spare the fuel cost on my descent and landing stage then I may do the deorbit burn with that stage to get my craft headed toward the surface, then stage and turn things over to K2D2 for the remainder. One problem I would see is that the K2D2 landing autopilot is probably making calculations for when to turn the engine on and how long to burn based on the TWR of the current engine. If you start down with one engine, then jettison that once it's done, you would at best need K2D2 to recalculate for the performance of the new engine - and you could very easily get into a situation where you've not got enough time left to land safely with the second engine. So, it's not that easy of a problem, and the much easier thing is to make sure you're on your descent and landing engine well before you're close to the surface so that K2D2 can do its thing based on that engine. Similarly, for ascent (lift), staging can be tricky if what you want is to insert a delay between stages. Here, I think the problem is that there is both a time component (how long a delay you want), as well as the many variables of design. It would be a very tall order to ask K2D2 to assess your particular rocket design and make some choices based on that. As for using the lift curve, I'd need a bit more info to offer any advice. I've found it easy to use, but then I've been using it for a long time. If it's not doing what you're expecting then it may be that you're not fully understanding how to use it - which is something that I think can be helped.
  2. Release 1.2.1Added check to prevent the mod UI from being toggleable while the game's UI is hidden (F2). This should help to prevent situations where the mod's UI is inadvertently raised while the game's UI is hidden which can result in the mod's UI only being visible when the game's UI is hidden and vice versa.Download on SpaceDock
  3. I've confirmed that this state can be entered. One way I've found to enter it is to hide the UI via F2, and then launch MNC via the hotkey (Alt+N). That will quickly get you into a state where toggling the UI's visibility has MNC up when it shouldn't be and not when it should. I'm looking into this, and will also be looking for why switching between Flight View and Map View with the UI hidden has this effect. Hopefully, I can run this down soon and get a new version posted where it doesn't do this.
  4. Update to version 0.4.0 Added capability to switch between Open and Closed part variants in the VAB. This update impacts the FPS-60, FPS-400, and FPS-2000, eliminating three parts from the part picker and instead delivering the capability to choose from Open (has no top truss structure or top attachment node) or Closed (has a top truss structure with a top attachment node) in the VAB. Selecting the Open variant will be lower mass. For backward compatibility, the old parts are all still in the asset bundle (so sadly it isn't any lighter), however, they are hidden in the parts picker. This means that any craft previously built with the now deprecated variants will still load and work as they have, but any new craft built will only have the new parts. https://github.com/schlosrat/TNO/releases/tag/0.4.0 https://spacedock.info/mod/3471/The Nuclear Option
  5. Thanks, this does help me understand the issue better. When you’re looking for a way to plan a Gilly to Eve trajectory the tab you need is indeed the Moon tab, and the maneuver is Moon Return. Of course going the other way it’s not this tab and you’re just planning a simple Hohmann transfer. Right now the Moon Return maneuver is giving poor results for Gilly to Eve, but that is the one intended for this purpose. It sounds to me like you’re finding this arrangement of maneuvers and tabs counterintuitive, and if you are then others may be as well, but this arrangement is by design. When you go from Eve to Gilly, you’re starting in an orbit about Eve and going to another object also orbiting Eve. Consequently the tools you need are basically the same as you need if you want a Hohmann transfer to rendezvous with another ship also orbiting Eve. When you go from Gilly to Eve, OTOH, your starting orbit is not about the same body that your target is orbiting, thus the math is a little different. There is still a hohmann transfer involved, but you need to escape Gilly’s SOI first, and to do so in such a way that your excess velocity puts you on a Hohmann transfer to Eve. Tab availability is situational. If you have two ships both orbiting the same body and one targets the other you’ll get the Target Relative Maneuvers tab for Vessels. This should work at any body including moons. If you target a celestial body that’s orbiting the same body you are then you’ll get theTRM tab for Celestials. If you’re orbiting a planet and target another planet you’ll get the Planet tab which gives you interplanetary transfers. You don’t get this at a moon, which may be frustrating or confusing, but again this is because the interplanetary transfer tools are not designed to get you out of a moons SOi, and then out of a planets SOI after that to put you on a transfer to your destination. Your use case of moon to moon transfer (at Kerbin or Jool) is a good one. I’ll explore if interplanetary transfer code can be used for this since the situation is analogous
  6. In the (very brief) testing I've done, the only moons where I've seen this problem are Minmus and Gilly. In every other case, I get pretty good results, although with Bop and Pol the returns to Jool are not nearly at the requested 100km Pe and instead at a few thousand Km Pe. Not really a bad result when we're talking about Jool - I mean, do you really want to be swinging around within 100km of its "surface"? I had thought I'd find the same problem at Bop and or Pol given their very small size, but apparently not - though my testing was hardly exhaustive. I do wish I had a good theory for why this happens in some cases and not in others...
  7. OK, I'm home now and I've been able to do some simple testing at Gilly, perhaps this is the problem you've encountered... In a 15.7km x 15.7km circular orbit at 0 inclination at Gilly, I used the Moon Tab to get a Return From Moon trajectory with no target selected. As with performing a Moon Return at Minmus, the result is a good burn vector at a very silly time. By a "good burn vector", I mean the Prograde, Normal, and Radial components are good - but as with returns from Minmus the node time is just plane wacky as you can see below. The resulting trajectory, while not headed all the way back to Kerbin (it's only a 221 m/s maneuver), is definitely leaving both Gilly's and Eve's SOI. In fact, if you turn the camera so you can see where Eve is in relation to all this, you'll clearly see the node time is just wacky. For a good Moon Return, or for that matter any transfer from a higher orbit to a lower orbit, we need to burn in a direction that will decrease the orbital energy so that the Pe will drop. In other words, we need to take off in more or less the opposite direction of the moon's orbital velocity about its parent. Fooling about with Maneuver Node Controller, I was able to get a not too terrible result with only modification to the time of the node. Here, the node time has been pushed out by about 2:10 - which is a lot for this orbit and results in a Gilly ejection that is headed in about the opposite direction of Gilly's motion as shown below. This problem has been reported before (by me and by others) and is being tracked on GitHub with this issue: https://github.com/schlosrat/FlightPlan/issues/49 The good news is that there is a relatively simple (albeit tedious) workaround, and also that I am aware of this and working on it. Not fantastic news, I'll grant you - but not bad news either. I am also working on this one! In fact, with this one, I feel closer to a solution than I do with the Moon Return problem, but we'll see.
  8. Are you saying that you’re orbiting Gilly and you don’t have a Moon tab with a Moon Return maneuver or that the Moon Return maneuver isn’t giving a good Pe at Eve in this case but is sending you out of Eves SOI? Any time you’re orbiting a moon there should be a Moon tab. You would not need to target Eve or anything really to be able to use it, though it does recommend that you be in a low inclination/low eccentricity orbit for best results. I’ll test the Gilly to Eve return when I get back to my PC, but it may help if you can describe more about your situation and the options you’re getting in FP
  9. Release 0.10.5Corrected issue where in some cases the Next Window time for a transfer window would be computed incorrectly and count up rather than down.Download on SpaceDock
  10. Well, that's odd. I verified it in 0.10.4 with Node Manager 0.7.3. In fact, I just reverified it in a debug build - so I've verified that the bug is possible in both the release and debug versions of FP 0.10.4 Since I'm able to reproduce it I should be able to get to the bottom of it. In my test case, I'm at UT 1y, 3d, 1:22:03 and flipping back and forth between Duna (which seems to work) and Dres (which is showing the bug). At Duna, I see this Relative Inclination: 0.06 Phase Angle to Target: 134.531 (counting down) Transfer Window Phase Angle: 44.361 Transfer Time: 302d 0:13:23 Synodic Period: 2y 57d 2:04:17 Next Window: 227d 4:51:33 (counting down) At Dres, I see this Relative Inclination: 5.00 Phase Angle to Target: 8.414 (counting down) Transfer Window Phase Angle: 82.056 Transfer Time: 1y 177d 0:55:54 Synodic Period: 1y 101d 5:22:42 Next Window: 107d 5:22:42 (counting up) The difference here is that in one case (Duna) Phase Angle to Target > Transfer Window Phase Angle, and in the other (Dres), it's not. It's also not for Moho or Eve at this UT, but those have Phase Angle counting up - which Dres does not. For any case where the target is in an inferior orbit, you can expect that the Phase Angle to Target counts up, and vice versa. All of this points to a bug in my logic where I was checking to see if Phase Angle to Target > Transfer Window Phase Angle when I should have been checking to see if the target is in an inferior or superior orbit relative to the starting planet. I've fixed this in 0.10.5 and verified it with all the stock planets. I should have a release out for you shortly.
  11. That is sooo weird! I tested with Moho, Eve, Duna, and Jool before releasing 0.10.2 and they all work fine (still do, too). I tested again with Dres and by Jove you're right - it is indeed counting up for the window. I'll look into this and sort it out. Thanks for bringing it to my attention.
  12. Release 0.10.4Multiple fixes/improvements to Resonant Orbit Maneuvers TabFixed handling of Synchronous Alt, Semi Synchronous Alt, and SOI Alt to display altitude instead of radius from the center of the body being orbited.Fixed Diving prohibition to account for atmosphere depth. You are now (correctly) prevented from setting up a diving resonant orbit around a body with an atmosphere where the Pe would be inside the atmosphere - which, I think we can all agree, would be bad.Updated FixPe and FixAp Maneuver buttons to allow for "after a fixed time" burn time option and also force a better default ("at Ap" for FixPe, and "at Pe" for FixAp)Download on SpaceDock
  13. @Poppa Wheelie Thanks for the detailed checking and the screenshots. Ending with an ecc of 0.004 is not unusual for FP when circularizing. My operating hunch is that backing off the node start time by exactly 1/2 the burn time is close to optimal, but clearly, something better could be achieved. The optimal result would be ecc 0.000. I believe this has to do with the fact that as you burn the node your mass decreases while thrust stays the same, and so acceleration increases and you're gaining more delta v in the second half than you did in the first half. The problem here is that the optimal amount to back off the node time is not a fixed percent. Depending on how much fuel you've got, what your thrust is, what your payload fraction is, and perhaps some other factors, the optimal for one craft will be different than for another. It's possible that some sort of optimization routine could be run around the problem where the offset factor of 0.5 burn duration is just an initial guess. This same thing will be in general true for all planned maneuver nodes since the cause is not unique to circularization. My priorities at the moment are to try to fix some things that are working very poorly, but it may be a good idea at some point to circle back and clean up the smaller problems like this one. The bigger questions I'm currently looking at include these. Why is it that a moon return from Mun works so well, whereas a moon return from Minmus works so poorly? Curiously, if you change the time of the moon return burn at Minmus by about 1/2 an orbit you can play with the time until you do get a good or very good result, but why is it that when at Minmus the node time is so far off? Why is it that when making a Hohman transfer from Kerbin to Minmus there is often no encounter and the node is not even getting the new Ap out to the orbit of Minmus, but when going to the Mun it will often give you an impact encounter? Both typically need some help from MNC. It would be very nice if they didn't need the help. Why is it that the Interplanetary Transfer works so very poorly unless you're selecting the "as soon as possible" burn option after time warping to be within a day of the next transfer window? Major problems with the Advanced Planetary Transfer make it not workable at all as it can't even get an encounter and so fails to make a node and there's nothing for you to adjust with MNC Wouldn't it be nice if you could give Flight Plan a landing point (lat/long) and then it could at least give you the deorbit node that would put you on a course toward your destination so that K2D2 could then land somewhere near there? Those are the things that keep me up at night much more so than circularization giving an ecc of 0.004! Still, it would be nice if this was my big problem instead of those others...
  14. Thanks for reporting this! It’s is not one I’ve encountered before but I’ll be happy to look into it. Can you elaborate on what triggers it. What circumstances are you in when it reliably behaves like this? I’ll need to be able to reproduce this in order to sort it out 15 is a lot of orbits to need to skip. If you’re low enough that orbital decay is a factor then that could certainly add up and may be the cause of it. Have you tried setting the rendezvous up in Flight Plan? If you’re looking to do it more manually then that’s obviously not the solution, but if you just want to get it done reliably then it’s a great option.
  15. Release 0.10.3 Corrected issue where the "at an altitude" burn time option was interpreting the altitude to be from the center of the body rather than above the reference level (sea level) as other altitudes are specified throughout Flight Plan. In this version, when selecting the "at an altitude" burn time option, the burn will be scheduled for the next time the orbit is at the specified altitude above sea level (bounded between the current orbit's PeR and ApR). Download on SpaceDock
  16. I believe this issue is actually related to two issues documented on GitHub. The first one (Issue 10) was an early one I created on May 8th, 2023, when I first noticed the problem with some Hohmann transfers, and in that one, I note it's affecting both transfers to moons and interplanetary transfers. The second one (Issue 31) reported on Oct 30th, 2023, identified a related problem with Moon Return. I've since then learned more about the underlying cause, but still have not gotten a solution. The new info I've got will hopefully help me to put this to bed, but it will not be easy. Since these are all related issues, I'll close those and open a new one that includes the workaround info.
  17. Release 0.10.2.1 Update to appease the CKAN gods who've been deeply offended by the mischievous machinations of the GitHub demons - we can't have that! No actual code was harmed, modified, improved upon, or in any other way molested in this process. All features are precisely the same as they were in version 0.10.2 Warranty void if speed exceeds c Download on SpaceDock
  18. Yes, I've confirmed this issue. It relates to a problem I encountered last night with GitHub, and now CKAN is confused about what to expect for the hash. The file is actually OK, but CKAN has no way to know this. You can download the file manually from GH or from SpaceDock and install it easily if you're comfortable with that process. I've been working for a bit on this, and it's beginning to look like the only way I can get CKAN to be happy is if I release a new version of the mod. I don't like doing that when there are no functional changes, but I do want people to be able to install using CKAN, so... Stand by and expect a FP 0.10.2.0, or something foolishly named like that.
  19. Yep, it’s a well known issue that’s been present for some time. Here’s a fairly recent post where I explain what’s going on and what thee work around is. Hmmm… That forum link doesn’t seem to be working correctly when I test it. Go back to page 7 on this thread and look for some long posts from me on 1/21 with a lot of pictures. That will show you the workaround Update for version 0.10.2 Fixed issue where Flight Plan would retain settings from a previous session after loading a new game session SpaceDock: https://spacedock.info/mod/3359/Flight Plan
  20. Thanks! This is a new feature, so I especially value this feedback. I'll take a look and see if I can replicate it.
  21. Update to Node Manager version 0.7.3 Added check to clear the node list when at the MainMenu game state. This prevents stale node info from inadvertently propagating when you load a different save. https://spacedock.info/mod/3366/Node Manager https://github.com/schlosrat/NodeManager/releases/tag/0.7.3
  22. Node Manager has been updated to 0.7.3 which should correct the issue of stale node info remaining from a previous session when you load a different save. This does correct the issue for MNC where it would still have the old node info. https://spacedock.info/mod/3366/Node Manager https://github.com/schlosrat/NodeManager/releases/tag/0.7.3
  23. Node Manager has been updated to 0.7.3 which should correct the issue of stale node info remaining from a previous session when you load a different save. This does not address FP starting raised in the new session with the previous tab and maneuver type already selected from the previous session. That will necessitate an update to FP, which is forthcoming. https://spacedock.info/mod/3366/Node Manager https://github.com/schlosrat/NodeManager/releases/tag/0.7.3
  24. Yep, that's probably in Node Manager. I'll run that one to ground and get a fix out which should solve this for both FP and MNC.
  25. Thanks for the feedback. I'm glad you're finding these mods useful! The first problem is actually in Node Manager - which is a mod FP and MNC depend on that runs in the background. It's maintaining a list of nodes, and apparently, this is not being cleared and reset when you load a save - hence the stale info from before. I'll get to work on this as it clearly should be handling this more gracefully. Once fixed in NM, the problem should vanish in FP and MNC. For the second problem, I may need a bit more info, and it also may help if I cast a bit more light on what FP is really doing. I'll start with the latter. tl/dr: FP is already backing the node off to make it star before the actual point you want the burn to be centered on. When FP creates a node it does base the *initial* position of the node on orbital mechanics equations that assume the burn is an instantaneous impulse. This is part of the MechJeb heritage and has the virtue that the equations are well-known and not hard to model. However, KSP2 handles burns a bit differently than KSP1, so FP carries on to adjust the time of the node, and consequently the direction of the node so that it will instead start earlier by 1/2 the burn duration. This is a two-putt approach because to get the burn time we must first *create* the node and let the game work out how long the burn needs to be for that craft to get that delta v. So, create the node, get the burn duration, back the node start time off by 1/2 the duration, and then (crucially it turns out) adjust the direction of the node. The crucial node direction adjustment is most apparent in the circularize after ascent problem. The thing here is that burn vectors are in Prograde, Normal, and Radial, and when you back a node off it will be at an earlier part of the trajectory where the prograde and radial vectors were very likely pointed in a different direction, so FP does a little math to make sure that the node, when positioned at an earlier time, has new P/N/R components that will point in the same direction the original non-adjusted node would have. Hopefully, that makes sense - now on to the request for more info! In the example you're using are you basing this on a very steep ascent profile? By steep, I mean one where you've begun your turn quite high and late in the ascent and so arrive at the Ap with not much horizontal velocity. If so, then I have your answer, but if not then I'll need more detail about the example problem so I can try to reproduce it and see what FP may need to do. What type of trajectory are you starting with: suborbital or orbital? for the initial orbit, what are the Ap and Pe? If you are talking about the problem of circularizing after a very steep ascent trajectory, then here's my answer. In such cases, particularly when the Ap is not all that far outside of the atmosphere, you can get into a situation where the node FP gives is not ideal. This is because such a trajectory is developing very little horizontal velocity resulting in needing a much longer circularization burn, and this is coupled with a more tightly turning prograde vector at the Ap of the suborbital trajectory. The solution to this is to fly a better ascent profile where you begin the turn earlier and arrive at the Ap with more horizontal velocity. That's more efficient, too. Alternatively, you can use MNC to make precision adjustments to the node, which you can even do with the game paused! So if you prefer the steeper inefficient trajectory, then as soon as you've got a circularization node from FP, press pause and bring up MNC. Now you'll be able to make very precise adjustments without worrying that your Ap is getting closer by the second, and when you un-pause you'll have a node to get the orbit you want.
×
×
  • Create New...