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…
queqiao-- has quit [*.net *.split]
paculino has quit [*.net *.split]
_whitenotifier-979b has quit [*.net *.split]
armed_troop has quit [*.net *.split]
queqiao- has quit [*.net *.split]
armed_troop has joined #principia
queqiao-- has joined #principia
paculino has joined #principia
_whitenotifier-979b has joined #principia
queqiao- has joined #principia
<queqiao--> <k​uz​in​at​0r​> You'll probably find VSO frame more useful
<queqiao--> <e​zs​na​ck​> i think you need to open more windows i can still see the screen
<queqiao--> <k​uz​in​at​0r​> But your manoeuvre frame should still remain as eci
<queqiao--> <e​zs​na​ck​> to answer your question absolutely not, this is just like a transfer to the moon or a RV if you use the correct RF
<queqiao--> <e​zs​na​ck​> but theres a guide on the wiki so go read some :V
<queqiao--> <K​ag​a> by the way how to i precisely move my menouver node without it going haywire in the solar system
<queqiao--> Reply to "K​ag​a: by the way how to i precisely move my menouver node without it going haywire in the solar..."
<queqiao--> Reply to "K​ag​a: it gets annoying when i have to adjust 0.001dv"
<queqiao--> <Z​ha​ng​ Y​on​g> you know you can type the changes to dv on those boxes right?
<queqiao--> <K​ag​a> i am aware, i prefer the slide so i dont have to type it in every second
<queqiao--> <k​uz​in​at​0r​> You can scroll over any decimal digit
<queqiao--> <k​uz​in​at​0r​> It's rather convenient way of interacting with numbers
<queqiao--> Reply to "k​uz​in​at​0r​: You can scroll over any decimal digit"
<queqiao--> <K​ag​a> ah, thanks! i didnt know that was possible to fine tune like that
<queqiao--> Reply to "k​uz​in​at​0r​: You can scroll over any decimal digit"
<queqiao--> <e​zs​na​ck​> this is literally the only way i ever did it lol
<queqiao--> <e​gg​> Note that this is no longer the case since Lagrange: https://github.com/mockingbirdnest/Principia/wiki/Change-Log#lagrange
raptop has quit [Ping timeout: 190 seconds]
raptop has joined #principia
<queqiao--> Reply to "e​zs​na​ck​: i think you need to open more windows i can still see the screen"
<queqiao--> <r​ud​em​ar​io​> LMAO
<queqiao--> Reply to "e​gg​: Note that this is no longer the case since Lagrange: https://github.com/mockingbirdnest/P...";
<queqiao--> <r​ud​em​ar​io​> Oh awesome! I was poking around the github to see if there was a changelog in case you guys had already fixed this before I bothered mentioning anything. My bad for not finding the changelog. I like reading through the changelogs of impressive stuff anyway cause it's fun to see all the amazing improvements documented (maybe I'm just a nerd though 😬)
<queqiao--> Reply to "K​ag​a: it gets annoying when i have to adjust 0.001dv"
<queqiao--> <r​ud​em​ar​io​> honestly, with dV adjustments that small I'm not even sure gods gonna be enough. As someone who loves to plan multi-swing by gravity assist in the Jool system in stock KSP who's spent 90% of my time playing staring at this menu for the precision adjustments it offers, you're just not going to get that kind of precision with Principia fundamentally because you have to manually time execution of your manuevers with no
<queqiao--> in-progress feedback
<queqiao--> <r​ud​em​ar​io​> Like, you're talking about values that you're just gonna steamroll over by variances in keypress/reaction time etc. However I can't speak for how accurate mechjeb "Execute Principia Burn" or something like a kOs script though
<queqiao--> <r​ud​em​ar​io​> You're also only using a precision of 1m in your screenshot over RSS distances
raptop has quit [Ping timeout: 190 seconds]
<queqiao--> <r​ud​em​ar​io​> Question: Just speaking in quick/rough estimate terms, is there any way for me to roughly estimate how stable a given orbit will be over time from orbital parameters alone? I know that I can just crank up the plan length (and that's what it's there for, that's literally why numerical integration is used), which is what I usually do, and it's just got me wondering. Like, for example, I see here that the semimajor axis
<queqiao--> changes +-69m and the eccentricity changes +-0.011, and that my mean apses are ~ +-0.65km (I assume these are all per revolution).Ignoring the fact that obviously Laythe moving close by Vall and Tylo will introduce temporary stronger perturbance. I just mean "ahhh yknow what I'm just popping inside for a bit, I'll just leave the car running" good enough estimation
<queqiao--> <r​ud​em​ar​io​> Like "I'm probably safe from getting kicked into Laythe's atmosphere for a week or two Bob you got this yeah?"
<queqiao--> <N​az​fi​b> > I assume these are all per revolution
<queqiao--> <N​az​fi​b> You assume incorrectly. Those changes are over the full analysed time period (in this case, 4h7m). If you want to investigate the long-term stability, you need to increase that time — in this case, that can be done by increasing the flight plan duration.
<queqiao--> Reply to "N​az​fi​b: > I assume these are all per revolution You assume incorrectly. Those changes are over th..."
<queqiao--> <r​ud​em​ar​io​> OHHHHHHHHHHHHH so Orbital Analysis in Principia is the average over the as much as the pink line can see OR as long as the flight plan is set for? That's great to know
<queqiao--> <N​az​fi​b> It is the analysis over the orbit starting after the final manoeuvre, until the end of the flight plan; or, if you open it from the main window, it is analysed for the time you set directly in that one.
<queqiao--> Reply to "N​az​fi​b: It is the analysis over the orbit starting after the final manoeuvre, until the end of th..."
<queqiao--> <r​ud​em​ar​io​> The main window has some sort of default as well. It's set to 28 days when I open it for example, which I now realize must not just be the current distance the pink line can see at my given steps+tolerance cause I'm pretty sure that'd only be like 10 hours by where it ends
<queqiao--> Reply to "N​az​fi​b: It is the analysis over the orbit starting after the final manoeuvre, until the end of th..."
<queqiao--> <e​gg​> (To be explicit: neither of which have anything to do with the length of the fuchsia noodle—the prediction.)
<queqiao--> Reply to "e​gg​: (To be explicit: neither of which have anything to do with the length of the fuchsia nood..."
<queqiao--> <r​ud​em​ar​io​> (yeah)
<queqiao--> <r​ud​em​ar​io​> Speaking of the orbit analysis main window: For me it always fluctuates really rapidly, regardless of what I seem to change. Like tighter tolerance doesn't stop the fluctuating
<queqiao--> <r​ud​em​ar​io​> Does it do this because I'm not giving it enough total time to analyze?
<queqiao--> <e​gg​> There are no tolerance settings on that one.
<queqiao--> <e​gg​> (I think it just uses same integration step as the real thing.)
<queqiao--> <r​ud​em​ar​io​> I figured the main orbit analysis window inherited settings from the principia window (the fuschia line)
<queqiao--> <e​gg​> No.
<queqiao--> <r​ud​em​ar​io​> ahhhhhhhhhhhhhhhhh
<queqiao--> Reply to "r​ud​em​ar​io​: Speaking of the orbit analysis main window: For me it always fluctuates really rapidly, r..."
<queqiao--> <N​az​fi​b> If you have some sort of autopilot firing RCS thrusters occasionally, then the orbit analysis might change a little between runs. If, additionally, the analysed time is very short, then it could be that the results seem to fluctuate.
<queqiao--> <e​gg​> And conversely, if your spacecraft is inert and you are analysing for the next month, it should be extremely stable.
<queqiao--> Reply to "N​az​fi​b: If you have some sort of autopilot firing RCS thrusters occasionally, then the orbit anal..."
<queqiao--> <r​ud​em​ar​io​> Then maybe it's just because I play Principia at stock KSP scale and all of the orbital durations in stock KSP are just not long enough, even on something like the Kerbin>Jool interplanetary transfer
<queqiao--> <r​ud​em​ar​io​> Even when I have the game paused the scroll bar changes size really rapidly lol
<queqiao--> <r​ud​em​ar​io​> Let me show
<queqiao--> <N​az​fi​b> Do you mean the progress bar near the top of the window? Yeah, if the analysed time is short, it will go very quickly indeed.
<queqiao--> <e​gg​> Nothing unstable there, the numbers don’t change.
<queqiao--> <r​ud​em​ar​io​> Paused
<queqiao--> <e​gg​> The progress bar goes quickly because the computation is quick.
<queqiao--> <r​ud​em​ar​io​> OHHHHHHHHHH that's a PROGRESS bar
<queqiao--> <r​ud​em​ar​io​> Yeah even on the interplanetary burns in stock KSP the bar moved so quick I assumed it was more like a resizing slider
<queqiao--> <r​ud​em​ar​io​> I knew it was human error and not anything wrong, but I figured it was me not giving it enough accuracy
<queqiao--> Reply to "N​az​fi​b: > I assume these are all per revolution You assume incorrectly. Those changes are over th..."
<queqiao--> <r​ud​em​ar​io​> Oh wow that's really cool actually: by incrementing up and down the time in the main orbit analysis window, I can see that between hour 3 and 4, my mean altitude and semimajor axis jumps up super far. So, if I had already performed the desired parking orbit circularization and didn't want to create a flight plan, I could just use this window to find the "time" my orbit experiences a massive change by throwing in
<queqiao--> <r​ud​em​ar​io​> So like this: Circularize at an approximate "safe" perturbation altitude (lets say I ballpark it and pick 100km Laythe altitude so my ascent vehicle doesn't have to reach so high). If I know I'm gonna be at Laythe for no longer than 3 weeks, I can just plug in like "d20" into the orbit analysis, and if the +- doesn't change beyond like 20km, then within like 5s I can figure out if I'm good
<queqiao--> <r​ud​em​ar​io​> I guess at the end of the day the answer was still "via numerical integration" but the "answer" to my question is technically the bit about the +-mean altitude change being what you can use to "ballpark" it
<queqiao--> <r​ud​em​ar​io​> Awesomeee
<queqiao--> <r​ud​em​ar​io​> Also, about this guy. Do you only get this if you analyze for a duration exceeding 1 full "year" for the given body and or only in polar or inclined orbits beyond a certain threshold? https://media.discordapp.net/attachments/480397772248580098/1383213304993812591/image.png?ex=684df946&is=684ca7c6&hm=cbeca35e6564d8a9eef42318c4e7f13d31bb85bb2f29c1b4ce41c5e79f513ab0&
<queqiao--> <r​ud​em​ar​io​> (mean local time of ascending node question for anyone searching the discord in the future)
raptop has joined #principia
<queqiao--> <e​gg​> So, no to both questions. The reasons why you might not get this analysis are listed here: https://github.com/mockingbirdnest/Principia/blob/3e7b9483647cc6300ea30a0ac905b338820e9094/ksp_plugin/orbit_analyser.hpp#L159-L161
<queqiao--> <e​gg​> Presumably you did not remove the sun, so this is probably because the orbit of Laythe around the sun is a bit on the long side.
<queqiao--> <e​gg​> (Technically it is the orbit of the sun around Laythe that we analyse.)
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> please do not remove the sun
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> this is generally not a good plan
<queqiao--> <e​gg​> It would make a lot of astronomy easier.
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> (please don’t rule 3 me this is relevant) https://media.discordapp.net/attachments/480397772248580098/1383218327832236173/IMG_0212.png?ex=684dfdf4&is=684cac74&hm=3668da4343ccdb872dc5373a6dde6ef9d09eff83cd70acaf3074696c2881b2ce&
<queqiao--> <e​gg​> (From https://what-if.xkcd.com/49/.)
<queqiao--> Reply to "e​gg​: So, no to both questions. The reasons why you might not get this analysis are listed here..."
<queqiao--> <r​ud​em​ar​io​> Interesting
<queqiao--> <r​ud​em​ar​io​> Also really nice to see nullopt being fired for an unexpected but being handled and not just force crashing the program (ptsd from bugfixing a codebase where that was done deliberately...a LOT lmao)
<queqiao--> Reply to "e​gg​: Presumably you did not remove the sun, so this is probably because the orbit of Laythe ar..."
<queqiao--> <e​gg​> This is strange though, since the code seems to suggest that we try to compute the length of the year out to 20 Julian years.
<queqiao--> <e​gg​> Oh we do force crash a lot. We use optionals for things that are logically optional, not for errors.
<queqiao--> <e​gg​> See https://github.com/search?q=repo%3Amockingbirdnest%2Fprincipia%20LOG(FATAL)&type=code.
<queqiao--> Reply to "e​gg​: This is strange though, since the code seems to suggest that we try to compute the length..."
<queqiao--> <r​ud​em​ar​io​> Yeah to clarify I made sure to remove Kopernicus entirely as well as removing my currently installed planet pack, EventHorizon before installing Principia and creating a new save (so I could see how the Joolian system was supposed to be with no errors before I go ahead and try to add the Kopernicus config myself and not know that I didn't get the config working correctly), so the sun is not only there but Kopernicus'
<queqiao--> sun magic isn't even in the playbook rn
<queqiao--> Reply to "e​gg​: Oh we do force crash a lot. We use optionals for things that are logically optional, not ..."
<queqiao--> <r​ud​em​ar​io​> Ah. This codebase did a lot of "struct = get_data_from_web_address, if(datafromwebaddress): initialize some_variable, else, stdnullopt. *some variable->some_variable"
<queqiao--> <r​ud​em​ar​io​> It was almost like they intentionally wrote the codebase to be hostile lmao. cause you fix one crash but then they made sure to sneak them in places you wouldn't even fathom as to why unless they wanted you to suffer
<queqiao--> <r​ud​em​ar​io​> ...like...you could just not intentionally dereference nulls...? like...all over the place?
<queqiao--> <r​ud​em​ar​io​> btw I just assume I'm dumb and the answer is obvious somewhere, but why do you guys use "d6" in your date/time format? like I assume it's automatic and denotes if you're using Kerbal time or RSS time and I know that kerbal time is 6h=1d, but my intuition expects it to be "h6" instead of "d6" and it be moved one place to the right
<queqiao--> <r​ud​em​ar​io​> I'm probably just missing something trivial
<queqiao--> <A​l₂​Me​₆> "d6" as in 6-hour days. In RSS it is simply "d"
<queqiao--> Reply to "r​ud​em​ar​io​: btw I just assume I'm dumb and the answer is obvious somewhere, but why do you guys use "..."
<queqiao--> <r​ud​em​ar​io​> @Al₂Me₆ Yes. "[...] and I know that kerbal time is 6h=1 [...]"
<queqiao--> <N​az​fi​b> 'd6' means "6 hours", 'd' means "24 hours" — they are simply units of time. How long would an 'h6' be?
<queqiao--> Reply to "N​az​fi​b: 'd6' means "6 hours", 'd' means "24 hours" — they are simply units of time. How long woul..."
<queqiao--> <r​ud​em​ar​io​> The 6 being there is to indicate to the user that you're using Kerbal time, through a "mnemonic" like cue. Like it's saying "we're in d6 version of d", not by saying "Kerbal Time: " The information the user needs to remember is what's different about the time systems. However, the "day" placeholder value, which is "a number that goes up to 30/31" is not what's changed, it's the hour "decimal place". the hour place ends
<queqiao--> at 6, instead of 24, which is the thing you have to remember. "The overflow for this number is 6 not 24, pay attention". d is still 30 or 31. h, however, is now 6
<queqiao--> <r​ud​em​ar​io​> There aren't 6 days in a month
<queqiao--> <r​ud​em​ar​io​> but there is 6 hours in a day
<queqiao--> <r​ud​em​ar​io​> Hence why I was curious
<queqiao--> <r​ud​em​ar​io​> d/h/m/s
<queqiao--> Reply to "r​ud​em​ar​io​: but there is 6 hours in a day"
<queqiao--> <A​l₂​Me​₆> Precisely? Thus “d6” is a disambiguation of the unit itself, not how many increments of the unit goes into the next larger unit.
<queqiao--> <r​ud​em​ar​io​> d/6h/m/s
<queqiao--> <r​ud​em​ar​io​> oh no, hold on...
<queqiao--> <r​ud​em​ar​io​> I see it now. It's meant to be read "x: unit/x: unit/x: unit". NOT "unit: x/unit: x/unity: x"
<queqiao--> Reply to "r​ud​em​ar​io​: I see it now. It's meant to be read "x: unit/x: unit/x: unit". NOT "unit: x/unit: x/unity..."
<queqiao--> <r​ud​em​ar​io​> It's "24 days, 7 months" not "days: 24, months: 7"
<queqiao--> <r​ud​em​ar​io​> THAT'S where my confusion about the logic order came from
<queqiao--> Reply to "r​ud​em​ar​io​: I see it now. It's meant to be read "x: unit/x: unit/x: unit". NOT "unit: x/unit: x/unity..."
<queqiao--> <N​az​fi​b> Yes. It's much more natural to write "5 days" rather than "days: 5". When writing, the unit usually comes after the value.
<queqiao--> Reply to "N​az​fi​b: Yes. It's much more natural to write "5 days" rather than "days: 5". The unit usually com..."
<queqiao--> <r​ud​em​ar​io​> That's not how date/time encodings are written, though, which is why maybe it seems simple when you isolate it like that.Consider yyyy/dd/mm
<queqiao--> <N​az​fi​b> That's a date, not a time interval, though.
<queqiao--> <r​ud​em​ar​io​> ...
<queqiao--> <r​ud​em​ar​io​> so you see why I was confused now?
<queqiao--> <r​ud​em​ar​io​> I was interpreting it as a t- style date like a system clock/mission clock
<queqiao--> <r​ud​em​ar​io​> t+ dddd/mm/ss
<queqiao--> <N​az​fi​b> I usually write "something will happen in 5 hours", rather than "something will happen in hours:5". That's just weird.
<queqiao--> <r​ud​em​ar​io​> It's not weird to misinterpret similar things, that's human
<queqiao--> Reply to "r​ud​em​ar​io​: I was interpreting it as a t- style date like a system clock/mission clock"
<queqiao--> <N​az​fi​b> 😕 I've seen "T minus 3 days" to mean "three days before launch". I've never seen a date inserted there.
<queqiao--> <r​ud​em​ar​io​> You absolutely have seen this before
<queqiao--> <r​ud​em​ar​io​> Look
<queqiao--> <r​ud​em​ar​io​> am I being gaslit here lmao
<queqiao--> <e​gg​> That is a duration.
<queqiao--> <N​az​fi​b> Yes, that's "3 years, 164 days after launch". It's a duration, not a date.
<queqiao--> Reply to "e​gg​: That is a duration."
<queqiao--> <r​ud​em​ar​io​> Yeah, I was interpreting your readout to be like a version of this. I don't know why, but I was
<queqiao--> <r​ud​em​ar​io​> It doesn't seem strange to me at all
<queqiao--> <e​gg​> But that is also units after the number.
<queqiao--> <e​gg​> 3 is the number of years. No y:3 here.
<queqiao--> <N​az​fi​b> If you click the "MET" button to switch it to "UT", it will show you something like "Y4, D100". That is a date, and is therefore formatted differently.
<queqiao--> Reply to "e​gg​: But that is also units after the number."
<queqiao--> <r​ud​em​ar​io​> You are correct. 3y, 164d6, 03:57:58 wouldn't be misconstrued by me at all here.See I knew the answer all along was that I was just missing something logical and it wasn't at all a problem with the system which is why I asked. Thanks egg for pointing that out. I don't really know why my brain went to the "y:3" logic because it clearly doesn't support my argument at all. Something about the way the time interval was
<queqiao--> written made me think it was like a custom "date interval but also each unit is defined" and "the defining happens to the right"
<queqiao--> <r​ud​em​ar​io​> I'm dumb but I can't tell you guys why cause idk why I just knew something was off lmao
<queqiao--> <r​ud​em​ar​io​> I'm not crazy though Nazfib, h6 would make more logical sense given the weird system I thought it was haha
<queqiao--> Reply to "r​ud​em​ar​io​: I'm not crazy though Nazfib, h6 would make more logical sense given the weird system I th..."
<queqiao--> <N​az​fi​b> … I guess? I've never quite figured out what weird system you've invented, but I'm glad it's been cleared up for you. Everyone has their own little blind spots sometimes; and I, for one, believe that it's never wrong to ask for clarification (as long as you stay nice about it, of course).