egg changed the topic of #principia to: Logs: https://esper.irclog.whitequark.org/principia | <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly…
_whitelogger has joined #principia
_whitelogger has joined #principia
_whitelogger has joined #principia
<queqiao-> ⟨maraganina⟩ Burned 15700 m/s worth of ΔV straight up and got this masterpiece on ECEF
<queqiao-> ⟨runeboss⟩ I don't get how you can find with the Target KO thing which is which
<queqiao-> ⟨runeboss⟩ Like
<queqiao-> ⟨runeboss⟩ Where do i point to burn relative velocity?
<queqiao-> ⟨runeboss⟩ Retrograde in the Target KO thing?
<queqiao-> ⟨runeboss⟩ I tried but it doesn't seem to be helpful
<queqiao-> ⟨runeboss⟩ I also odn't understand the Target KO orbital loopty loops
<queqiao-> ⟨kuzinat0r⟩ Your best candidates for rendezvous are descending/ascending nodes. You should adjust your period at one of those points. The problem is the distance between nodes of your and your target orbits isn't displayed. So you have to constantly switch between plotting frames🥲
paculino has quit [Ping timeout: 207 seconds]
_whitelogger has joined #principia
<queqiao-> ⟨butcher6994⟩ El gato
_whitelogger has joined #principia
<queqiao-> ⟨runeboss⟩ i understand that
<queqiao-> ⟨runeboss⟩ im basically at the same oribtal plane of my target
<queqiao-> ⟨runeboss⟩ its just idk how to see our relative speeds ig
<queqiao-> ⟨runeboss⟩ like to my target
<queqiao-> ⟨runeboss⟩ cuz in ksp what i do is i switch to target view frame, match speed to target, \
<queqiao-> ⟨runeboss⟩ then burn towards them a little
<queqiao-> ⟨runeboss⟩ at next closest rendezvousd
<queqiao-> ⟨runeboss⟩ do the same
<queqiao-> ⟨runeboss⟩ repeat
<_whitenotifier-bad2> [Principia] eggrobin opened pull request #4144: Fix nanobenchmarks on clang - https://github.com/mockingbirdnest/Principia/pull/4144
<_whitenotifier-bad2> [Principia] eggrobin closed pull request #4144: Fix nanobenchmarks on clang - https://github.com/mockingbirdnest/Principia/pull/4144
<queqiao-> ⟨egg⟩ In the target frame, the target doesn’t move. So your speed is just the speed relative to the target.
<queqiao-> ⟨runeboss⟩ Would that mean burning to the prograde and retrograde markers would mean i am changing my velocity relative to the target?
<queqiao-> ⟨runeboss⟩ -would
<queqiao-> ⟨runeboss⟩ In the reference frame
<queqiao-> ⟨egg⟩ The loops are your trajectory with respect to the target. As you are used to in stock, with different periods, with each revolution of the orbit (which you can see in the KCI frame), you catch up or fall back a little. In the target frame, you see that catching up or falling back as loops.
<queqiao-> ⟨egg⟩ Yes.
<queqiao-> ⟨runeboss⟩ Oh ok thank you evry much
<queqiao-> ⟨egg⟩ The loops are your trajectory with respect to the target. As you are used to in stock, with different periods, with each revolution of the orbit (which you can see in the KCI frame), you catch up or fall back a little. In the target frame, you see that catching up or falling back directly, as loops.
<queqiao-> ⟨egg⟩ The loops are your trajectory with respect to the target. As you are used to in stock, with different periods, with each revolution of the orbit (which you can see in the KCI frame), you catch up or fall back a little. In the target frame, you see that catching up or falling back directly, as loops towards or away from the fixed target.
<queqiao-> ⟨egg⟩ (I should probably make screenshots for https://github.com/mockingbirdnest/Principia/wiki/A-guide-to-performing-low-orbit-rendezvous…)
<queqiao-> ⟨egg⟩ You are trying to do a rendez-vous between non-coplanar orbits ?
<queqiao-> ⟨runeboss⟩ No theyre ont hes ame plane
<queqiao-> ⟨runeboss⟩ Dw lol its just i got confused by the new targeting referenec frame
<queqiao-> ⟨egg⟩ (I was asking about kuzinat0r’s use case, not yours)
<queqiao-> ⟨kuzinat0r⟩ It's not forbidden) And I think it would be even cheaper than aligning the plane and arranging a rendezvous with separate burns
<queqiao-> ⟨egg⟩ OK, I’ll think about that.
<queqiao-> ⟨kuzinat0r⟩ And it's just cool to combine a Minmus orbital insertion burn with a rendesvous with a fuel station at the same time
<queqiao-> ⟨egg⟩ I was aware you had some issues with the target frame, but telling us _what you are trying to achieve_ is the useful part. Telling us how you think we should help you achieve it is typically less useful. (See https://github.com/mockingbirdnest/Principia/blob/master/SUPPORT.md#new-features-and-improvements, last section.)
<queqiao-> ⟨butcher6994⟩ Ideally you want to do a single burn to align planes and also sync orbits, yes
<queqiao-> ⟨egg⟩ I would guess that it would work to look at the {closest approach, node, target} set of markers and make them converge (all of that is shown in the target frame), but maybe that gets messy. I should try it.
<queqiao-> It occurs to me that this sounds a bit like the kind of thing that used to be easy but tedious before the optimizer, maybe we should be able to optimize a target interception…
<queqiao-> ⟨kuzinat0r⟩ Ok, let me create a feature request with my idea and prepare some screenshots
<queqiao-> ⟨egg⟩ Please don’t
<queqiao-> ⟨kuzinat0r⟩ Well, you're not obliged to implement it if you don't want to. It just wouldn't get lost in chat
<queqiao-> ⟨runeboss⟩ 👍🏿
<queqiao-> ⟨egg⟩ Again, we don’t want to hear about your idea of how this should be done. If we listened to that we would have kept adding markers to the patched conics UI until it filled the screen, because that is what players know and think they want. I want to know what you are ultimately trying to do, and then we’ll try to come up with a way of enabling that that fits within the way we present things (which will be less familiar at first, but...
<queqiao-> ... that’s fine 😈).
<queqiao-> ⟨kuzinat0r⟩ Ok, the problem I have(and trying to solve) is I have no idea where our trajectories touch each other. Ascending/descending nodes are the best candidates, but I need to know the distances between them(difference of our orbits' heights at these points). If I know exactly this info, I can adjust the period of my orbit so we meet exactly at AN/DN only several meters apart
<queqiao-> ⟨kuzinat0r⟩ And then I have to kill the relative velocity of course
<queqiao-> ⟨egg⟩ Right, that you can do afterwards. So the problem is to hit something from an orbit in a different plane.
<queqiao-> But when you have succeeded in doing that, at the interception point, there will not only be a node (where you cross the target orbital plane) on your trajectory, but also a closest approach marker. So I would imagine that you could do that wholly in the target frame by trying to make the node marker and the closest approach markers move towards each other and towards the (fixed) target.
<queqiao-> ⟨ezsnack⟩ talking about cluttering, cant the unclutter all default to off or save the preference...
<queqiao-> ⟨kuzinat0r⟩ Easier said that done) I know how to do that if I know the distance between the nodes - just burn prograde/retrograde at the opposite node until the distance becomes very small. But it's literally trial and error without that info
<queqiao-> ⟨kuzinat0r⟩ * error(and switching between plotting frames)
<queqiao-> ⟨egg⟩ It may be trial and error to see which way to burn, but you shouldn’t need to switch between frames, since you don’t care about the exact number, just about whether node comes closer to the closest approach (which is something you can see in the target frame alone).
<queqiao-> But anyway, I need to try it out.
<queqiao-> ⟨egg⟩ It may be trial and error to see which way to burn, but you shouldn’t need to switch between frames, since you don’t care about the exact number, just about whether node comes closer to the closest approach (which is something you can see in the target frame alone).
<queqiao-> (And for final fine tuning, the closest approach has the distance information.)
<queqiao-> But anyway, I need to try it out.
<queqiao-> ⟨kuzinat0r⟩ But the closes
<queqiao-> ⟨kuzinat0r⟩ * what if the closest approach at AN/DN will be several orbits ahead?
<_whitenotifier-bad2> [Principia] eggrobin opened pull request #4145: More fixing of nanobenchmarks on clang - https://github.com/mockingbirdnest/Principia/pull/4145
<_whitenotifier-bad2> [Principia] eggrobin closed pull request #4145: More fixing of nanobenchmarks on clang - https://github.com/mockingbirdnest/Principia/pull/4145
<queqiao-> ⟨egg⟩ Well that is where the target frame should shine, because you can actually read many revolutions ahead, whereas in stock you can only see one revolution at a time. But again, I need to try it out.
<queqiao-> ⟨ezsnack⟩ You can read as many revolutions ahead as you want with conics. Just need to use 2 manouver nodes
_whitelogger has joined #principia
<_whitenotifier-bad2> [Principia] eggrobin opened pull request #4146: Sourcery for functions - https://github.com/mockingbirdnest/Principia/pull/4146
<queqiao-> ⟨egg⟩ I did not write that you could not read multiple revolutions ahead. But you cannot see them all at the same time (it would be a mess, they are all along the same ellipse!). With the target frame, each revolution is a loop in a different place as you move away from or towards your target, so you can actually see them all at once.
_whitelogger has joined #principia
<_whitenotifier-bad2> [Principia] eggrobin opened pull request #4147: Download Release protoc even when building in Debug - https://github.com/mockingbirdnest/Principia/pull/4147
<_whitenotifier-bad2> [Principia] eggrobin closed pull request #4147: Download Release protoc even when building in Debug - https://github.com/mockingbirdnest/Principia/pull/4147
<_whitenotifier-bad2> [Principia] pleroy opened pull request #4148: Next release is Kuratowski - https://github.com/mockingbirdnest/Principia/pull/4148
<_whitenotifier-bad2> [Principia] eggrobin opened pull request #4149: nanobenchmarks is not a test - https://github.com/mockingbirdnest/Principia/pull/4149
<queqiao-> ⟨clayel⟩ 2nd new moon in one month, is there a name for the opposite of a blue moon?
<queqiao-> ⟨GoForPDI (less drag=more faster)⟩ clearly red moon
<queqiao-> ⟨GoForPDI (less drag=more faster)⟩ well, technically that’s the opposite of cyan, but close enough
<queqiao-> ⟨clayel⟩ well that would be a blood moon
<queqiao-> ⟨clayel⟩ oh there is a name for it! black moon
<queqiao-> ⟨clayel⟩ * https://en.wikipedia.org/wiki/Black_moon
<_whitenotifier-bad2> [Principia] eggrobin closed pull request #4149: nanobenchmarks is not a test - https://github.com/mockingbirdnest/Principia/pull/4149
<_whitenotifier-bad2> [Principia] eggrobin closed pull request #4148: Next release is Kuratowski - https://github.com/mockingbirdnest/Principia/pull/4148
<_whitenotifier-bad2> [Principia] pleroy created tag 2024123022-Kummer - https://github.com/mockingbirdnest/Principia
<_whitenotifier-bad2> [Principia] pleroy tagged cbfb62e as 2024123022-Kummer https://github.com/mockingbirdnest/Principia/commit/cbfb62ed2d9b854700323bc9aa29b187bfd8a215
<raptop> I suppose that there's nothing preventing egg from tagging the release with ⚸ instead of 🌑︎
<queqiao-> ⟨egg⟩ 🌑︎, not to be confused with 𒊹
<raptop> If I'm using the latter, that probably means that my lunar probe failed because the wiring used inferior grade copper
<queqiao-> ⟨egg⟩ amusingly, šar₂ means totality https://oracc.museum.upenn.edu/epsd2/sux/o0038872
raptop has quit [Ping timeout: 190 seconds]
_whitelogger has joined #principia
raptop has joined #principia
<_whitenotifier-bad2> [Principia] eggrobin closed pull request #4146: Sourcery for functions - https://github.com/mockingbirdnest/Principia/pull/4146
paculino has joined #principia
<queqiao-> ⟨clayel⟩ grabbed it
<queqiao-> ⟨sichelgaita⟩ The US of A gets the first download.
<paculino> Do you keep track of the frequency of those first downloads?