Jump to content

Syntax

Members
  • Content Count

    70
  • Joined

  • Last visited

Community Reputation

43 Excellent

About Syntax

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

1,834 profile views
  1. I like to deorbit my debris using a craft that has an AGU attached. A few versions back, I had no issues with this. But now targeting debris targets the root part of the debris, not the COM, and once the klaw is attached, I can't target the COM, like I can when attached to an asteroid. Am I missing something? Or is there a workaround? I'd gladly install (or even write, if I knew where to start) a plugin that adds the "target COM" ability to the right click menu, or changes the game's targeting behaviour to target vessels' COM by default, or treats debris as a singular part that forces COM
  2. I was away from KSP for a while, but since I've been back, I've come to find that one can no longer target the COM of a piece of debris once latched on to it with the AGU. I seem to remember being able to do this back in the day, just as I can today with asteroids. This seems so backwards, as it's the engineered object whose COM should be able to be known, while an asteroid's should be less certain. I've considered options like a "pull design" tug that could perhaps work, but I'd still need to know roughly where the COM is at the time of attachment, so that's not my ideal. Also, I just fe
  3. Can someone help shed some light for me? I thought I knew SCANsat... but then I found this, and I honestly don't get it. There is so much data here, and all the people responding are so excited about it... and I don't understand what the data means or why it pleases people or how it could be useful to me as a SCANsat user. I know that different scanner parts have different ideal orbit altitudes, and that small adjustments to that altitude will make for more complete scans of the surface, but this... this is something more, no? I think of myself as fairly well versed in KSP and
  4. I thought I knew SCANsat... but then I found this, and I honestly don't get it. There is so much data here, and all the people responding are so excited about it... and I don't understand what the data means or why it pleases people or how it could be useful to me. I know that different scanner parts have different ideal orbit altitudes, and that small adjustments to that altitude will make for more complete scans of the surface, but this... this is something more, no? I think of myself as fairly well versed in KSP and its mechanics (orbital mechanics and game mechanics), but the sig
  5. Nice! Thanks! I managed to make it work. I ended up leaving the initial value for the minimum distance unspecified. When I use the code below, the true anomalies spit out at the end were 0 (or whatever value I passed in that initial value array). I couldn't figure out why, as that didn't happen with the max distance array reduction. const res = distances.reduce((a, b) => a[0] < b[0] ? a : b, [a1 + a2, 0, 0]); But it worked without that initial value... just thought that was a bit strange. Anyway, thanks so much for your guidance! You've really helped me tie a nice bow on this
  6. I'm sorry to necro this. I thought you might be interested in knowing that I did get to the bottom of this issue some months ago, but haven't done much with the results yet. I'm starting to work on it again... I find myself with more free time lately... Turns out the problem was a silly calculation error on my end, and both your code and my model in fact were returning identical results (long story short, I was conflating true anomaly and eccentric anomaly). More as an exercise and diversion than anything else, I am now wondering: What would I need to change about the original code to use
  7. So I've been away from KSP for about 3 years. I've always missed playing it, but I fell away and got caught up in other projects. Last time I played was in 1.2. KSP2 hadn't yet been announced and Making History and Breaking Ground were but glimmers in the devs' eyes. I was good enough at the game to feel comfortable with landing on Mun and Minmus, rendezvous and docking, I had several mods installed and had played around with planes and VTOLs a bit. I had probably a couple hundred hours docked, but I never got around to leaving the Kerbin SOI... Though I was on the brink of such a missio
  8. @K^2 Whelp, I'm out of ideas at this point. I've learned enough about rotation matrices in the last few days to understand how to reproduce your transformX and transformY functions. I was hoping to find some minor discrepancy that, when resolved, would close the gap between the results. And the rotation matrices I came up with did differ slightly from yours, by a negative sign in the variable z for each. Changing it didn't make any difference at all. I checked the rotation matrix against the orbits' orientations in my model, and they are visually identical. As for bignumbers, I don't
  9. @K^2Really, just enough to work out what's causing that 0.05 rad discrepancy. I'm happy to research and learn, but it can be hard to know where to look, and my formal mathematics training ended with high school calculus. These are definitely well out of my league. Thank you for the resource, though. Who knows, I may end up to coming back to them. This helped a lot, and I'm going to try to find more stuff like this. Just about the only thing left in your JS that I don't understand is the transformX and transformY functions, and I'm hoping that with that last puzzle piece I can c
  10. @K^2 Thank you SO MUCH for what you've done here. You've single-handedly brought me to within a hair's breadth of the solution to this problem that has been bugging me for months! I say "within a hair's breadth" because, oddly, when I put the true anomalies output by your algorithm into my model, I get a distance of 113191.131383 Mm, a difference of 169.675468 Mm from your algorithm's output (113360.806852). But, when I play around with fine adjustments to those body positions in my model, I can maximize the distance calculated in the model to within <10m of the algorithm output! So I
  11. @K^2 This gives a max separation a few Gm less than what I've been able to find just through trial and error.
  12. @K^2That does look more believable. Seems likely I'm having issues on my end. Not sure why, though. I will also continue looking. One thing I do notice (and this could help explain our discrepancies), is that on the graph you provided, it looks like Dres' periapsis lies on the positive y-axis, and Jool's orbit swings away from it to the upper left. When I look at my model (and indeed at the map screen in KSP) in that orientation, Jool's orbit swings away from Dres' to the upper right when looking straight down at it.
  13. Sure can! Jool SMA: 68773.56032 e: 0.05 Inc: 0.022759093795546 LAN: 0.907571211037052 APe: 0 Dres SMA: 40839.348203 e: 0.145 Inc: 0.0872664625997166 LAN: 4.88692190558413 APe: 1.57079632679490 Thanks so much for all your help! This is amazing.
  14. @K^2 That's fantastic. Thanks for clarifying. I see it now. Thing is... something's not adding up. I've made this model (linked in my signature) against which I'm checking the angles and distances this script is spitting out. I've been using Dres and Jool... and I'm getting a max distance that I can't seem to replicate no matter how hard I try (off by 3Gm!). Plus, the angles are just plain nonsensical. I don't know what is leading to the inconsistencies. I'm trying to get it to add up, but no luck yet. If you get a chance to look at what I'm talking about, I'd be interested to hear y
  15. My cup overflows! Thank you! I will try this out tonight. Am I correct in my understanding that the centre of the ellipse (and not one of the foci) is at the origin?
×
×
  • Create New...