Jovus

Members
  • Content count

    981
  • Joined

  • Last visited

Community Reputation

450 Excellent

About Jovus

  • Rank
    Junior Rocket Scientist
  1. Saw on the last page that the tutorial (and the whole project) is being reworked, which is really cool. However, I've never used CactEye before; does any one of you end-users have a quick-and-dirty run-down of how it works? I've just realized in my save I have no idea what I'm doing. I searched for CactEye tutorials, but what I've seen so far is from 2014 and doesn't appear to have much to do with what I see in my game. (That said, the telescope I'm using is in Solar orbit, and I saw an off-hand comment that the telescopes only work in high Kerbin orbit?)
  2. Hi all, I've recently discovered I'm not as clear on how to launch into a specific orbit as I thought I was. I'm talking about in the simplified case provided by Kerbin; you launch from the equator into an orbit with Kerbin at the centre. I'm not concerned with off-equatorial launches, not orbits around bodies not the launch body. What I thought would have worked would be: time warp until the longitude of your ascending node is (roughly) the same as the LAN of the target orbit. Then, offset your launch angle from the East according to the inclination of the target orbit - so if the inclination you want is 20 degrees, you launch at 90-20=70 degrees on the navball. Unfortunately this didn't work. My orbit ended up in a vastly different orientation, though the same inclination. What did I do wrong?
  3. True, to a point. There's a difference between 'the ground is leaky' and 'we want to tunnel underwater' as a matter of engineering. I'm not claiming this makes it unfeasible, just that it's maybe a reason to consider it uneconomic. If that's even the case. It's a question.
  4. Someone else who knows better than me: isn't LA only just above its own water-table? Wouldn't boring holes underneath it require you to constantly evacuate said water? Not that this is impossible (see: Chunnel), just maybe not an awesome idea (see: Chunnel).
  5. So, OK, it's clearly impossible with real materials. But what about whatever-it-is that Kerbal planets are made of? And, for those who don't want to do the integral proving that the outer shell imparts no gravity on anything inside it, you can get halfway there by thinking about it in terms of subtending angles. Choose some spot to look out from the inner body, and some angle of deviation for your gaze (say, 10 degrees). Then, when the inner body is in the centre, the cone of your gaze will cover (subtend) a certain amount of the outer shell. Now move the inner body further away, by having it drift in the opposite direction of your gaze. Then, the outer shell on that side will be further away, and therefore impart less gravitational force - but the same angular cone will subtend more of it, meaning that more of it will pull along that cone. It so happens that the amount of less pull because of distance and amount of more pull because of greater subtension exactly cancel one another. Also, for those who have done undergrad E&M: gravitational potential works exactly the same way as electric field potential, so you've already done this proof.
  6. Camouflage. Can't hate on Dres if you can't find it.
  7. Scientist? At least, when I get a chance to play KSP at all anymore, instead of writing code.
  8. ...okay, I'll assume silence is consent, unless I hear otherwise! Some time soon I'll either update my version of the license, to include credit where I realize credit is due, or take my stuff off GitHub. Probably the former. Thanks for all your help, guys!
  9. Finally got it to work! Heavily based on (and many thanks to) AlexMoon's and @TriggerAu's work in the area (https://github.com/alexmoon/ksp/blob/gh-pages/src/lambert.coffee and https://github.com/TriggerAu/TransferWindowPlanner/blob/master/TransferWindowPlanner/SharedStuff/LambertSolver.cs) Which leaves me with a licensing question. You can see AlexMoon's original license from 2013/14 and its requirements regarding distribution and modification of the software. However, I'm technically not distributing or modifying that software in any way, but instead writing my own, in a different language, heavily based upon that original work but with some subtle-but-important differences. Right now my work is ARR, mostly because that's easier in my time crunch than looking into what open-source license I actually want to use when I make this available. And I'm not trying to avoid giving credit where credit is due. At the same time, to be brutally honest, I'm not sure I want to (at the moment) include a license that could be read as saying effectively, "Hey, this is someone else's work and I just cribbed," because I have to present this as an end-of-semester project, and my Professor may have strange ideas about the acceptability of using someone else's solution to the problem to help me write one, especially when they're as similar as they are. So I'm asking y'all (and tagging @TriggerAu and would be tagging AlexMoon if I knew what his handle on the KSP forums was), because I don't want to be either a) in breach of license or b) ungrateful for the help, and I would like advice on how to proceed. This is also the first time I've ever done something where licensing might possibly be an issue. Maybe the easiest thing would be to delete my work from GitHub for the nonce and re-upload when I've fixed the licensing? How bound am I by the original license in AlexMoon's work, since this is to my mind a heavily-inspired-but-technically-original piece? (You can see the repository in question here: https://github.com/Jovus/Transfer-Window-Finder)
  10. OK, for a large enough time-of-flight, my algorithm transgresses the parabolic minimum or maximum (depending on which is in place). Now to track down why...
  11. Running into a weird bug with my Lambert solver. I've construed the problem as you can see here: http://www.braeunig.us/space/interpl.htm#gauss I'm also using their method of linear interpolation to find the correct parameter. As construed, this method should converge for all cases except where R1 and R2 are colinear. However, that's not at all my experience. I'm clearly getting behaviour where, after a certain time-of-flight bound, the algorithm diverges (and quits with an error due to either taking the square root or a trig function of a number that is out of bounds). If anyone feels like taking a look, you can see the code in question here: https://github.com/Jovus/Transfer-Window-Finder/blob/master/libs/scratch.py Note I'm using cartesian coordinates, because ellipses aren't spherically symmetric. Also, I'm more than happy to give credit, despite the slapdash state of the license.
  12. That's exactly what I was going to do, except I'll choose the farther body, whether destination or departure body, on the principle that the inner body obviously make a full revolution if the outer body does. But centering on the Hohmann time is the bit I was missing - which sounds obvious once you've said it, but that's how ideas work. Thanks again!
  13. Perfect answer. Thanks!
  14. Been a while since I posted here, so I don't expect a response, but I thought I'd ask: Pretty much all interplanetary launch window solvers use time-of-flight as an input, rather than an output. Does anyone know a good source for various bodies what a reasonable time-of-flight would look like? Or how to get a starting estimate? I can find Earth/Mars data that seems to indicate a good middle value being ~200 days, and of course I would pad that out to around 100-500 to catch unlikely trajectories. I'm also sure someone somewhere has tables that'll give me reasonable values for Earth/planet trajectories. But what if I want to leave from Venus? Or Jupiter? Maybe what I should do is take the lower bound of ToF to be half the inner body's orbital period, and the outer bound to be the outer body's orbital period, but that seems like an excessively large window. Related, does anyone have any recommended sources for orbital parameters for the planets? Especially including true anomaly at some specified date. (I can programmatically update from there; long-term accuracy isn't a concern.) Again, everyone, thanks for all your help.
  15. Got it. Thanks! I've seen references to the ephemerides in further papers, but never explained as well as you just did. Once I'm done I'll probably post my work to github, because after all I might as well. Unfortunately I haven't done much further work on it, because I'm focused for the moment on building a linear algebraic equation solver. (Without using the solver methods that come with most programming languages.)