• Content count

  • Joined

  • Last visited

Community Reputation

636 Excellent

About Kobymaru

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

2511 profile views
  1. The coriolis force doesn't exist. Surface velocity doesn't exist. They're all just artifacts of a rotating reference frame. Depending on the problem, sometimes it's easier to pretend that they do exist. I think this is not one of those cases. Or maybe it is. Who knows, I'm not a physicist.
  2. The authors of about 6 scientific papers that I've read on this topic tend disagree with you You can't "just take the Integration", because sometimes the Integration doesn't even have a closed form (one that can be written as a formula). It matters in which direction, because ... That's cool and all, but what about the cosine losses in between horizontal and vertical? The optimal path is not a) a straight line or b) a quarter-circle or a cosine or any simple form. The optimal path is a strange curve that looks approximately like SQRT but isn't. That's what it looks like: Along this path, the cosine loss depends on your radial velocity around the body (because of the centrifugal force) and your current velocity angle. Your current velocity and angle depends on how much you have slowed down on the path before, and on the previous cosine loss. Your previous cosine loss depends on the previous radial velocity around the body and the previous velocity angle. And those depend on the cosine loss before that... This kind of recursive relationship can be expressed mathematically as a system of coupled differential equations. In its simplest form, these are: dv/dt == g * (TWR - cos(beta)) v * d beta/dt == g* sin(beta) This already is hard to solve, but possible (only for angle and velocity - not for altitude/downrange distance!), but mind you: this assumes Flat Earth Constant g Constant TWR No Rotation Which obviously breaks in multiple ways in KSP. Now any attempt to expand the model a bit to account for a spherical body, changing g, changing TWR, and rotation, you end up with shenanigans like this one: Containing mathematical functions that I haven't even heard of. Mind you, even these monstrosities come with a huge list of assumptions like "but only if the velocity is much lower than orbital velocity and rotation is low and it's a monday evening and it's full moon". Believe me guys, I *wish* it were as simple as "just add the second dimension". And I have read a lot of comments and a lot of threads that say "oh that should be trivial". But if you look at the physics, and if you try it out in practise you realize that it's not at all simple. edit: Click here for more fun stuff
  3. Considering that you already forked it, you found it Please expose them in Plugin/API.cs
  4. Ok. What did you want to change anyway? BTW, I would prefer to continue the discussion about Trajectories in the trajectories thread:
  5. Yes, this is my fork: https://github.com/fat-lobyte/KSPTrajectories I will merge that into neuoy/KSPTrajectories bevore the next release.
  6. You can make PR's on the main repo, I have privilges.
  7. Incidentally, it's me who got stock with maintaining that mod so I know at least a little bit about it. Care to enlighten me how it calculates the required values? Because Trajectories doesn't calculate the trajectory with an engine burn, it calculates it under free fall or atmospheric. How can it help you for suicide burn? Why not? I don't see the 3rd dimension. I see only vertical and longitudinal Thanks for the code! Full numeric solution was my last resort, I was hoping for "half-analytical". Especially this looks like a nasty bit of coding that I don't know how to do nicely yet:
  8. This is the hard part. At the moment, I can't provide it accurately. My current model is so inaccurate that it's almost useless. When was the last time you tried? I do this on a regular basis. Set NavBall to surface mode, press retrograde button, press Z and wait until your vehicle has killed all velocity. If it's not too much effort, that would be nice.
  9. Nope, that should all be accounted for.
  10. Since we got really nice SAS functions including Retrograde hold in Stock KSP, I don't think this is such a big issue anymore. After digging around in ways to actually calculate the burn, I would say the difficulty lies in the implementation side
  11. Meh So I did implement the Gravity Turn algorithm in reverse. It "works" in the sense that the numeric values come out to be what is expected by solving the Differential Equations in [1] numerically. It does not work particularly well in practice, because the Suicide Burn altitude is greatly overestimated. I believe it's partially because the "flat earth" assumption breaks the centrifugal force. However, I tried to account for the centrifugal force in another model [2] and still came up short (or rather too high ) Right now I'm not quite sure where to go from here. I recall that the timer itself being pretty much OK though. You can check out my progress on the "suicide-numeric" branch of KerbalEngineer here: https://github.com/fat-lobyte/KerbalEngineer/blob/suicide-numeric/KerbalEngineer/Flight/Readouts/Vessel/SuicideBurnProcessor.cs For a quick-test, you can download the DLL here: https://github.com/fat-lobyte/KerbalEngineer/blob/suicide-numeric-bin/Output/KerbalEngineer/KerbalEngineer.dll Like I said, it's not quite there yet BTW, I have Mathematica Notebooks with 2 models of suicide Burns, I can post these if there is interest. Papers "available" on sci-hub.io, or from me on request. What I also have is a collection of papers on this subject that may or may not be useful - I can't even tell yet. Oh that would be wonderful. I'm not really doing this for KerbalEngineer, I just chose it because of the nice framework it provides. What I reall want are functioning and precise Suicide Burn aids. If it's in a separate Mod, so be it. [1] Culler, G. J., & Fried, B. D. (1957). Universal Gravity Turn Trajectories. Journal of Applied Physics, 28(6), 672–676. https://doi.org/10.1063/1.1722828 [2] McInnes, C. R. (2003). Gravity-Turn Descent from Low Circular Orbit Conditions. Journal of Guidance, Control, and Dynamics, 26(1), 183–185. https://doi.org/10.2514/2.5033
  12. @wile1411 Looks good to me and thanks for the summary! Two minor details: I'm not entirely sure if the angle setting has to be the same if snap is Off. Could be that angle doesn't matter in this case (needs checking). Roll force does not need to be >= 1 to exert a torque, you can also use anything >= 0.
  13. Then why ask? Everything is explained.
  14. Locking does not work. Organics locked -> Organics still removed by scavenging. That makes the Agriculture Module stop. I think this is a bug.
  15. I don't know either. I'd say make the PR anyway, if he doesn't want to change that he'll reject it. I think the Organics-Stealing issue does need fixing in one form or the other.