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--> Reply to "N​az​fi​b: … I guess? I've never quite figured out what weird system you've invented, but I'm glad i..."
<queqiao--> <r​ud​em​ar​io​> Yeah, to explain more clearly, as you were typing I thought about it, I was imagining the system was like this:2000/1/1"okay lets turn that into days, hours, seconds"0000/0/0(see here how it also starts with 4 zeros, much like the intervals in Principia, this might've been my trigger for thinking this was how the system was)"Okay, now, if we want our default to be RSS/normal time since that's our intended use
<queqiao--> case/preferred default state, but we would also like to support stock KSP, what would be the least destructive addition would could add to cue to the user we're using Kerbal Time?0000 d6/0/0Now, I was personally feeling like this made more sense along that line of reasoning0000/h6 0/0Why? because you technically read this system right to left, not left to right, when you think about it as a "time incrementer". You don't start incrementing from the
<queqiao--> left, you start on the right because the smallest unit is on the right. For example, if we looked at JUST the days, it's 4 digits, so if you had 4 days, that would be 0004/0/0.Consider this:d6 0000/h 0/s 0instead of0000 d6/0 h/0 sIf you take your eyes and are trying to "index them to the right spot at each place to verify you start counting right", is it easier to start "right aligned", to put the number in your head "0402", then once you confirm
<queqiao--> you've got the full number, indexing to the far left to confirm the place value (d6)? or is it mentally easier for you with the below, where even though you HAVE to start counting from the right (0001), you can't "start" at the beginning because there's a placevalue there (d6)?
<queqiao--> <r​ud​em​ar​io​> This COULD just be a quirk of me. Like my brain sees "d6 0402/42/32" way as easier or "less disruptive" to my count flow than "0402 d6/42/32
<queqiao--> <r​ud​em​ar​io​> I might just be the one guy putting his hand up in the class like "oh yeah that's not weird at all" and then everyone turns to face me
<queqiao--> <r​ud​em​ar​io​> If you completely forget about using h6, putting d6 on the left instead of the right also satisfies the same core "crux" in this fictional framework
<queqiao--> <N​az​fi​b> I read it left-to-right, reading it as as "0 six-hour days, 0 hours, 0 minutes and 0 seconds". Similarly, don't Americans usually write lengths as "6 ft 2 in" (putting the largest unit first) rather than the other way around? It puts the most significant value first, and gets more precise with each further field that you read. The information is ordered from most to least important in that way. Numbers are also written like
<queqiao--> that, with the most significant digit first.Dates, in my mind, are their own separate thing, which have their own rules that are completely separate from those of all other kinds values (such as time intervals). Humans are weird, I suppose; what seems to be completely normal and obvious to one person, might be very unintuitive for someone else.
<queqiao--> <N​az​fi​b> Anyway, it's time for me to go; it's the middle of the night here, and I'm going to get some sleep now. Have a good night!
<queqiao--> Reply to "N​az​fi​b: I read it left-to-right, reading it as as "0 six-hour days, 0 hours, 0 minutes and 0 seco..."
<queqiao--> <r​ud​em​ar​io​> I think for me I get stunlocked into interpreting it right to left for some reason. That might be a personal quirk human thing of mine. 0000d60h0s honestly even makes me wanna interpret it as a date. Humans are weird indeed
<queqiao--> <N​az​fi​b> I read it left-to-right, reading it as as "0 six-hour days, 0 hours, 0 minutes and 0 seconds". Similarly, don't Americans usually write lengths as "6 ft 2 in" (putting the largest unit first) rather than the other way around? It puts the most significant value first, and gets more precise with each further field that you read. The information is ordered from most to least important in that way. Numbers are also written like
<queqiao--> that, with the most significant digit first.Dates, in my mind, are their own separate thing, which have their own rules that are completely separate from those of all other kinds values (such as time intervals). Humans are weird, I suppose; what seems to be completely normal and obvious to one person, might be very unintuitive for someone else.
<queqiao--> Reply to "N​az​fi​b: Anyway, it's time for me to go; it's the middle of the night here, and I'm going to get s..."
<queqiao--> <r​ud​em​ar​io​> Have a good night Nazfib!! Hope you didn't destroy your sleep schedule haha
<queqiao--> <r​ud​em​ar​io​> (I have a tendency to do that myself)
<queqiao--> <r​ud​em​ar​io​> Please, is there any way to somehow be allowed to see at least the next closest approach indicator in the fixed and rotating reference frames other than just target oriented?
<queqiao--> <r​ud​em​ar​io​> I might be the only person that finds rendezvous harder to perform in Principia rather than easier I guess, but holy. I noticed I was having this problem with setting up encounters with celestial bodies too: because closest approach markers are not shown (and there is no Target frame for celestial bodies), there is no visual confirmation provided that your orbit comes "close" or ever comes "close "to a body unless you
<queqiao--> get significantly close enough that you can tell your orbit is being deflected, which means unless the body you're attempting to rendezvous with is already AT the spot you're going to be at that time, you have no feedback on which course correction you need to apply to adjust your phase. I know what I need to do from in the CI (first) reference frame visual cues from years of using the inertial fixed non-rotating reference frame KSP's stock patched
<queqiao--> conics uses, but I have to "fly blind" and "trial and error" my inputs on the manuever node based on that previous knowledge in order to get that stuff to happen. I figured that stuff was just limited to celestial bodies maybe, and that being able to select a vessel as a target might function differently. However, even if I pin the target reference frame of a vessel, it still doesn't also show me my closest approach in any other frame besides Target,
<queqiao--> which isn't that much of a problem like, when you're already "lined up", but it makes the whole preliminary lining up and the lining up part of orbit matching "obscured" and difficult to execute
<queqiao--> <r​ud​em​ar​io​> I imagine that this stuff doesn't matter if you pre-plan a very specific sort of flight plan (like I mean literally structuring your mission a specific way), but it kinda feels like to do "other" styles of missions it's much harder because of this
<queqiao--> <A​l₂​Me​₆> Ok, let's start with the simpler task: Hohmann transfer. If you're having difficulty with this you aren't using the correct reference frames
<queqiao--> Reply to "A​l₂​Me​₆: Ok, let's start with the simpler task: Hohmann transfer. If you're having difficulty with..."
<queqiao--> <r​ud​em​ar​io​> On my current mission, I performed a Joolian injection via a hohmann transfer. Then I lined up a Tylo gravity assist to capture, then did a multi-flyby Laythe twice before coming back around for a small burn to perform the Laythe capture. Then, I landed with a lander, came back up, and have just finished rendezvous with my mothership. This photo I took just after completing rendezvous a few minutes ago
<queqiao--> <A​l₂​Me​₆> > there is no visual confirmation provided that your orbit comes "close" or ever comes "close "to a body
<queqiao--> <A​l₂​Me​₆> This is exactly what the <body> <parent> Orbit frame does?
<queqiao--> <A​l₂​Me​₆> Not to be That Guy, but just to make sure: you have seen and read https://github.com/mockingbirdnest/Principia/wiki/Concepts#plotting-frame ?
<queqiao--> Reply to "A​l₂​Me​₆: > there is no visual confirmation provided that your orbit comes "close" or ever comes "c..."
<queqiao--> <r​ud​em​ar​io​> So, TJO reference frame (Tylo-Jool-Orbit), looks like JCI (Jool Centered), but has closest approach markers visible?
<queqiao--> Reply to "A​l₂​Me​₆: Not to be That Guy, but just to make sure: you have seen and read https://github.com/mock...";
<queqiao--> <r​ud​em​ar​io​> I have read this, and the rendezvous tutorial. My concern wasn't answered in those, and I understood them
<queqiao--> Reply to "r​ud​em​ar​io​: So, TJO reference frame (Tylo-Jool-Orbit), looks like JCI (Jool Centered), but has closes..."
<queqiao--> <A​l₂​Me​₆> The "closest approach marker" is a stockism; please stop thinking in stock terms. You have been conditioned to work within a very constrained framework and it's evident that you're competent in working with the stock planning tools, but that is an active hinderance in Principia.
<queqiao--> <A​l₂​Me​₆> in TJO, Tylo does not move. That means if you took a ruler and measured the distance between a point on your trajectory and Tylo on the screen, that is exactly how far you will be from Tylo at that moment in time.
<queqiao--> <r​ud​em​ar​io​> Yes, I understand that very well. To explain this in meta terms I suppose, it seems that maybe you believe I must not understand how Principia works if I'm having problems. However, my problem isn't that I do not understand how Principia works or is designed, I'm having trouble understanding how to transfer my knowledge and capabilities that I already possess onto the principia way of doing things. Like, it's not that
<queqiao--> I don't WANT to get good at the Principia way of doing stuff, I'm having difficulty understanding what it is I should learn in order to. Or, in other words, if I can't enable the closest approach marker in the <body> centered interial frame (non rotating), or in <body> <parent> Orbit frame, how would I achieve equivalent capability using what Principia offers?
<queqiao--> <r​ud​em​ar​io​> Consider the following example in stock:
<queqiao--> <r​ud​em​ar​io​> Basic example, stock KSP. Joolian hyperbolic trajectory with a goal to capture, coming presumably from Kerbin. Tylo selected as target. Closest approach to target marker (which functions as a total distance seperation at any point since you're shown at least 1 at all times provided orbit is close enough) is visible, which is the blue circle on the right. blue circle above is YOUR position at the same time Tylo's is
<queqiao--> shown
<queqiao--> <r​ud​em​ar​io​> Because I am being fed data about where Tylo will be when I am near the orbit crossing point I have defined (by making my periapsis similar to Tylo's altitude relative to Jool as defined by the orbit line), I know that I can simply burn in KSP terms, "retrograde" plus "radial out", in order to "slow" my approach speed but maintain my orbit angle (so my Jool relative periapsis doesn't dip below Tylo's orbit line height)
<queqiao--> <r​ud​em​ar​io​> The way that Principia seems to suggest that I do this is to manually calculate where Tylo will be on a specific date, using Tylo's period information and my proposed arrival time (which I can obtain from something like a collision course with a body or by looking at my time to periapsis), and calculate out by hand what my new arrival time should be
<queqiao--> <r​ud​em​ar​io​> However, I found a way to sort of "cheese" or "brute force" this sort of relative distance information by switching to one of the other reference frames (it might've been Laythe or Tylo fixed rotating) and viewing where my orbit line showed up relative to where the fixed position was
<queqiao--> Reply to "r​ud​em​ar​io​: Basic example, stock KSP. Joolian hyperbolic trajectory with a goal to capture, coming pr..."
<queqiao--> <r​ud​em​ar​io​> Once I played around with a flight plan burning in different reference frames (cause I had no idea what got me relatively to where), I managed to get it JUST close enough that I started doing this by memory, which would be to burn combinations of negative tangent and positive normal delta v, and if that didn't bring it closer after a bit, to do it the opposite "direction" (inverting the two). And I knew I got a close
<queqiao--> fly by encounter when I, like I mentioned above, noticed heavy deflection on my orbit trajectory in the JCI view
<queqiao--> Reply to "r​ud​em​ar​io​: Because I am being fed data about where Tylo will be when I am near the orbit crossing po..."
<queqiao--> <A​l₂​Me​₆> Q: where is your spacecraft at the time when you're performing the burn? Just past Kerbin ejection?
<queqiao--> <A​l₂​Me​₆> Q: to confirm, the goal is to adjust the timing of your arrival such that you intercept Tylo at perijove?
<queqiao--> <r​ud​em​ar​io​> The way I got it done did not at all feel intended, and I'm not saying it should be. What I am curious about (because this also plays into my question about craft rendezvous' originally) is "how do I perform this sort of thing in Principia"?
<queqiao--> Reply to "A​l₂​Me​₆: Q: where is your spacecraft at the time when you're performing the burn? Just past Kerbin..."
<queqiao--> <r​ud​em​ar​io​> A: these sorts of manuevers are most efficiently performed a few weeks out from Jool, usually right after entering Jool's SOI in stock KSP (just a coincedence, you can easily do it outside too), following the same principle as "the further out you burn the more efficient your movements over vast distances". it doesn't matter where you do this stuff, but if you tried do to line this up just past Kerbin ejection, you'd
<queqiao--> likely be talking about increments of dv smaller than what would get eaten up by the Jool SOI change bug or if that didn't happen, at least take a REALLY long time to type into the editor. Like 0.001 dvs.
<queqiao--> <r​ud​em​ar​io​> Q. The goal is to perform a Joolian capture by Tylo gravity assist, with the goal being for it to place your Joolian periapsis as close to Laythe's orbital altitude as possible. This is to either line up a flyby of Laythe to reduce your apoapsis. All of this can easily be done every time upon entering the stock KSP Jool system because of Tylo's quick orbital period of only 9(?) days, and it's unrealistically dense mass
<queqiao--> (for large deflection). The period plus Jool's gravity producing a really long hyperbolic travel time makes the adjustment so easy that you can get it done every time
<queqiao--> <r​ud​em​ar​io​> I did indeed pull this off in Principia. However, I wasn't able to get as clean of a inclination off of Tylo as I would normally, but that was more because of unfamiliarity with the flight plan's reference frame setting. I realize that what I was trying to do was essentially a "HCI" based manuever node set of tangent and normal inputs, but because I had the camera focused on Jool with JCI, I know now in hindsight that I
<queqiao--> was plotting the flight plan in THAT reference frame, which is why my inputs weren't what I would expect them to do normally from stock KSP
<queqiao--> <r​ud​em​ar​io​> I learned that and that shouldn't happen anymore
<queqiao--> <r​ud​em​ar​io​> Nothing about Principia, whatsoever, effects any of the above's basic principles, to be clear
<queqiao--> <r​ud​em​ar​io​> as in, the n body simulation being present
<queqiao--> <r​ud​em​ar​io​> quite literally, the ONLY thing that makes this kind of manuever harder in Principia (which also applies to rendezvous with vessels but at leas there you can see it by constantly swapping to target view), is the lack of a readout of closest approach for planets
<queqiao--> <A​l₂​Me​₆> Hm ok, well the intuitions about how to burn still hold. Thus, as you said, the correct maneouvre frame in the planner is JCI. Now switch to the TJO plotting frame (decluttering is probably advisable) and focus on Tylo. Adjust the two burn directions until your Tylo periapsis in TJO (TCI would probably also work, for this purpose?) is at the desired value. To tell if you're being deflected in the correct direction, check by
<queqiao--> switching back to JCI. Once you get the maneuver tuned close enough the perijove altitude can be tuned back in JCI.
<queqiao--> <A​l₂​Me​₆> I haven't touched the stock system in a very long time, but that's how I would do it. Perhaps there is worth in producing a tutorial for this task.
<queqiao--> Reply to "A​l₂​Me​₆: Hm ok, well the intuitions about how to burn still hold. Thus, as you said, the correct m..."
<queqiao--> <r​ud​em​ar​io​> Sorry, uh, maybe the problem or "the usefulness of stock KSP's closest approach marker" wasn't made clear by me
<queqiao--> <A​l₂​Me​₆> Hm ok, well the intuitions about how to burn still hold. Thus, as you said, the correct maneouvre frame in the planner is JCI. Now switch to the TJO plotting frame (decluttering is probably advisable) and focus on Tylo. Adjust the two burn directions until your Tylo periapsis in TJO (TCI would probably also work, for this purpose?) is at the desired value. To tell if you're being deflected in the correct direction, check by
<queqiao--> switching back to JCI. Once you get the maneuver tuned close enough the perijove altitude can be tuned back in JCI.
<queqiao--> <A​l₂​Me​₆> I haven't touched the stock system in a very long time, but that's how I would do it. Perhaps there is worth in producing a tutorial for this task.
<queqiao--> <A​l₂​Me​₆> Yes, the latter is likely what I fail to comprehend.
<queqiao--> <r​ud​em​ar​io​> You cannot do what you said here
<queqiao--> <r​ud​em​ar​io​> You will frankly not at all see a Tylo periapsis
<queqiao--> <A​l₂​Me​₆> Alright, I'll find some time to produce a tutorial after I finish fighting msbuild/CI
<queqiao--> Reply to "r​ud​em​ar​io​: consider this more extreme example:"
<queqiao--> <r​ud​em​ar​io​> most people in stock KSP when doing rendezvous with vessels or gravity assists do not know how to do the above
<queqiao--> <r​ud​em​ar​io​> Most people would likely just say "you missed Tylo on this window" or in the case of rendezvous say something to the effect of "wait a very long amount of phases"
<queqiao--> Reply to "r​ud​em​ar​io​: You will frankly not at all see a Tylo periapsis"
<queqiao--> <A​l₂​Me​₆> In the stock conception of "periapsis", yeah no, because you won't ever enter Tylo's SOI. But there is no such thing as SOI in Principia (well, as far as flight planning is concerned). In Principia the periapsis is the mathematical local minimum in distance to the body. Its existence has nothing to do with how large the value is.
<queqiao--> Reply to "A​l₂​Me​₆: In the stock conception of "periapsis", yeah no, because you won't ever enter Tylo's SOI...."
<queqiao--> <r​ud​em​ar​io​> yes this I understand
<queqiao--> <r​ud​em​ar​io​> That's not a problem, the same way as it isn't in stock ksp; all that's needed to solve this practically is a readout that constantly feeds you closest approach
<queqiao--> <r​ud​em​ar​io​> What you said about Tylo periapsis makes me wonder, though, IF I can see tylo's periapsis in it's fixed frame NO MATTER how far away it is, that functions as the same thing
<queqiao--> <r​ud​em​ar​io​> Let me reload a save and check that real quick
<queqiao--> Reply to "r​ud​em​ar​io​: What you said about Tylo periapsis makes me wonder, though, IF I can see tylo's periapsis..."
<queqiao--> <A​l₂​Me​₆> Yes, that's what I'm saying...
<queqiao--> <A​l₂​Me​₆> Anyhow, I should sleep. Will see about producing a tutorial this weekend.
<queqiao--> Reply to "A​l₂​Me​₆: Yes, that's what I'm saying..."
<queqiao--> <r​ud​em​ar​io​> I can confirm that you can see a periapsis at even distances as absurd as what constitutes just barely a Jool encounter, meaning that the periapsis can itself function as a Closest Approach marker. This is GREAT news for gravity assists, and I would say that you don't need to produce a tutorial for this whatsoever. As someone who, by being a member of the group of people who do or want to do this sort of thing, am the
<queqiao--> target audience/source for a tutorial on that subject, all you actually need to say to people like me is that you can see your apoapsis or periapsis with any body of your choice no matter the distance by swapping to that body's reference frame and zooming out to locate it; that is to say that Principia never performs any kind of selective truncation of displaying the readout "when it might not be useful"
<queqiao--> <r​ud​em​ar​io​> The assumption we and many others would make on first interpretation is that it wouldn't be shown until some reasonable distance, possibly set by the body's gravity as a performance or UI choice
<queqiao--> <r​ud​em​ar​io​> So if you want to make a tutorial you could simply just make it a small paragraph that states the above line, plus "You can use the periapsis much the same way as you might use the closest approach marker in stock KSP patched conics as a way to track your target body when doing more advanced gravity assist/flyby manuevers"
<queqiao--> <r​ud​em​ar​io​> That's all you really need to say on that, to save you some time
<queqiao--> <r​ud​em​ar​io​> HOWEVER, this does not help my original problem with performing rendezvous with vessels, though, and that problem still remains
<queqiao--> <r​ud​em​ar​io​> The reason this solves the issue for celestial bodies is because plotted manuevers can be visualized in the same style of reference frame as you would perform these manuevers in stock KSP: When I click TCI, and plot manuevers in either JCI or HCI the adjustments use compatible reference frames so it essentially functions as a "drop in" feature replacement for your existing stock KSP gravity assist knowledge. It's
<queqiao--> fundamentally the "same thing" like, "up goes up, down goes down, even if left and right are swapped you know what you need to do" yknow what I mean? However, vessels have no equivalent; the target vessel MUST be viewed in the Target Frame in order to see ANY closest approach markers, and manuevers MUST be plotted in a reference frame that isn't the Target Frame. This means you have to make changes in one "space" of movement, but VIEW/VISUALIZE the
<queqiao--> effect in a different space of movement. All your experience gained in stock KSP for rendezvous, so all the tricks, intuition, subconcious understanding, but most importantly input feedback, are all essentially performed in the <body>CI reference frame AND visualized in the <body>CI reference frame. I know how to rendezvous well enough in stock KSP that I don't need to have aligned AN/DN nodes, it doesn't matter whether I'm in a larger or smaller
<queqiao--> orbit, it doesn't matter whether I nail the launch timing just right. 7 years ago I ABSOLUTELY needed to ensure I matched inclination to 0 and got in relatively similar orbits or I'd be there FOR HOUUUURS trying to get a closer approach than 20km lmao. But now in my main save, I can gravity assist with a horrific orbit cause I'm almost out of life support and had to visit way off transfer phase, and rendezvous with my heavily inclined station in like
<queqiao--> 5, 10 minutes while listening to music no problem. You pick up a lot of intuitive familiarity with what and how to do things and how to be efficient too.
<queqiao--> <r​ud​em​ar​io​> Yknow, push your apoapsis to the well boundary since inclination changes are much cheaper there, maybe make a small phasing adjustment plus another inclination change halfway along your AN/DN node to push your orbit much closer to being in-line with your target space station, go up for another high apoapsis AN/DN and now you're at like 0.7 degrees, come back down and set up the rendezvous to within 0.5 km and then do
<queqiao--> the rest out the window
<queqiao--> <r​ud​em​ar​io​> ALL of this is just as possible in Principia, there's nothing about it that precludes this stuff. If anything, RSS scale is what truncates your options into essentially "doing everything as efficient as possible" because there's absolutely no margin for error (because you simply cannot HOLD enough delta v for ANYTHING to go even slightly not so good in ANY mission you do). With RSS, the answer basically IS "if you're
<queqiao--> not perfectly in phase with that planet down to the day that means your missions over bud". So I can totally see how, if Principia is mainly designed FOR RSS, that these sorts of things seem like afterthoughts
<queqiao--> <r​ud​em​ar​io​> Even if I know that I can go to the gravity well boundary for a cheaper inclination change what's that gonna buy me? like 0.4 degrees? lmao
<queqiao--> <r​ud​em​ar​io​> Bringing it back to the above: There's no way to view your AN/DN nodes or closest approach with your target without using the Target reference frame, but the Target reference frame doesn't visually display information in a way that I can comprehend my movements in: that in and of itself is not an issue at all, right? I can just use a different view for now as I learn it slowly as I play because Principia supports the
<queqiao--> <Body> Centered Fixed view. Uh oh, I can't see anything in that view that I need, like AN/DN and closest approach...
<queqiao--> Reply to "r​ud​em​ar​io​: Bringing it back to the above: There's no way to view your AN/DN nodes or closest approac..."
<queqiao--> <r​ud​em​ar​io​> Okay, well, lets just set up a node inside the Target frame so I can learn what each movement does and move relative to the target in my planning. Oh wait, I can't set my flight plan's reference frame to the target frame
<queqiao--> <r​ud​em​ar​io​> Bringing it back to the above: There's no way to view your AN/DN nodes or closest approach with your target without using the Target reference frame, but the Target reference frame doesn't visually display information in a way that I can comprehend my movements in: that in and of itself is not an issue at all, right? I can just use a different view for now as I learn it slowly as I play because Principia supports the
<queqiao--> <Body> Centered Fixed view. Uh oh, I can't see anything in that view that I need, like AN/DN and closest approach...
<queqiao--> <Q​az​er​ow​l> You can use the "optimize" button in the maneuver planner to fine tune your jool periapsis off Tylo. Once you have an encounter with Tylo that lowers your Jool periapsis, the optimizer doesn't care what you're encountering between now and then, just that it will make small tweaks that get you where you want to be. That can hypothetically mean tweaking the maneuver that uses multiple gravity assists.
<queqiao--> Reply to "r​ud​em​ar​io​: Okay, well, lets just set up a node inside the Target frame so I can learn what each move..."
<queqiao--> <r​ud​em​ar​io​> So, I'm not really sure what the options are in Principia for transferring existing knowledge/playstyle over. The options just seem to be "only use the target reference frame to see closest approach, eyeball a manuever node where your AN/DN is, leave it in that reference frame, swap back and forth between <body> centered inertial and lose the closest approach right click pin every time you go back and forth (so you
<queqiao--> gotta find it and put your mouse over it every time you swap)...OR completely relearn how to do stuff like cross orbital plane, burn at AN/DN node, perform half-mid orbit phase changes with stuff like planetary launches with stations (very very similar to what you do with the Tylo rendezvous example I drew in Paint, if you don't have to go around once you shouldn't have to), all from within the Target reference frame without needing to leave it. The
<queqiao--> only options kinda seem to be to relearn it from scratch. The workaround for this would just be some way to make closest approach and AN/DN nodes visible in <body> centered interial frames, if nothing else just the closest approach marker (because swapping once or twice for AN/DN is not a big deal at all and can be lived with). If I could see that, ALL of what I've learned in stock KSP applies to Principia. To make it clear, I never had trouble doing
<queqiao--> the rendezvous, I only had trouble "seeing" the info I needed to see to make the rendezvous happen. It took me longer because I had to keep switching back every time. The solution isn't "to just learn Target view" because I'll learn it eventually—and from what I've played with how it visualizes movement it looks really interesting—because that doesn't solve the question of when I need to do manuevers that aren't ideally planned in Target frame? I
<queqiao--> know how to do that stuff in in <Body> centered fixed (like lining up orbital lines and matching altitude at periapsis), but, I miss out on if on my next go around I have a close approach. You still have to relearn it all
<queqiao--> Reply to "Q​az​er​ow​l: You can use the "optimize" button in the maneuver planner to fine tune your jool periapsi..."
<queqiao--> <r​ud​em​ar​io​> I've given the optimizer a try, it's pretty cool. It doesn't help me plan multi swing bys though, like if I want to do a low delta V Laythe insertion capture at an inclined orbit (like to match my station)
<queqiao--> <r​ud​em​ar​io​> I have to do that stuff by hand
<queqiao--> <r​ud​em​ar​io​> That doesn't take anything away from the optimizer at all. It should by no means support optimizing something like that, that's the job of something like TOT or https://github.com/Zange10/KMAT
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
queqiao- has joined #principia
_whitenotifier-979b has joined #principia
<queqiao--> Reply to "r​ud​em​ar​io​: So, I'm not really sure what the options are in Principia for transferring existing knowl..."
<queqiao--> <k​uz​in​at​0r​> I don't know who are you speaking with, but yes, I agree - rendezvous is easier with stock conics
<queqiao--> <r​ud​em​ar​io​> So, I'm not really sure what the options are in Principia for transferring existing knowledge/playstyle over. The options just seem to be "only use the target reference frame to see closest approach, eyeball a manuever node where your AN/DN is, leave it in that reference frame, swap back and forth between <body> centered inertial and lose the closest approach right click pin every time you go back and forth (so you
<queqiao--> gotta find it and put your mouse over it every time you swap)...OR completely relearn how to do stuff like cross orbital plane, burn at AN/DN node, perform half-mid orbit phase changes with stuff like planetary launches with stations (very very similar to what you do with the Tylo rendezvous example I drew in Paint, if you don't have to go around once you shouldn't have to), all from within the Target reference frame without needing to leave it. The
<queqiao--> only options kinda seem to be to relearn it from scratch. The workaround for this would just be some way to make closest approach and AN/DN nodes visible in <body> centered interial frames, if nothing else just the closest approach marker (because swapping once or twice for AN/DN is not a big deal at all and can be lived with). If I could see that, ALL of what I've learned in stock KSP applies to Principia. To make it clear, I never had trouble doing
<queqiao--> the rendezvous, I only had trouble "seeing" the info I needed to see to make the rendezvous happen. It took me longer because I had to keep switching back every time. The solution isn't "to just learn Target view" because I'll learn it eventually—and from what I've played with how it visualizes movement it looks really interesting—because that doesn't solve the question of when I need to do manuevers that aren't ideally planned in Target frame? I
<queqiao--> know how to do that stuff in in <Body> centered fixed (like lining up orbital lines and matching altitude at periapsis), but, I miss out on if on my next go around I have a close approach. You still have to relearn everyt
<queqiao--> <e​zs​na​ck​> It really isnt :v
<queqiao--> Reply to "r​ud​em​ar​io​: Okay, well, lets just set up a node inside the Target frame so I can learn what each move..."
<queqiao--> <B​ut​ch​er​> You would normally use body centered inertial for referencing a rendezvous.
<queqiao--> Reply to "r​ud​em​ar​io​: I've given the optimizer a try, it's pretty cool. It doesn't help me plan multi swing bys..."
<queqiao--> <s​ic​he​lg​ai​ta​> The optimizer supports optimizing individual burns and specifying the desired inclination (and distance). There is no telling if it will do something useful in a particular situation (it's all best effort) but it was designed (and tested) for building complex, multi-burn flight plans.
<queqiao--> <R​ad​ -​ L​R-​87​ f​an​at​ic​> Y’all want some trajectory porn?
<queqiao--> <e​zs​na​ck​> direct TLI with principia and new LTP by clayel :V
<queqiao--> <e​gg​> what is this yellow ellipse?
<queqiao--> <e​zs​na​ck​> pvg predicted orbit, its always in eci
<queqiao--> <e​gg​> What is it like in MEO?
<queqiao--> <e​zs​na​ck​> (this is a different window)
<queqiao--> Reply to "e​zs​na​ck​: "
<queqiao--> <C​la​ye​l> good to know that it actually works
<queqiao--> <C​la​ye​l> do you see a performance impact in flight? i didnt notice it before bc it doesnt show up in the ksc scene, but im seeing a ~20fps performance impact in flight, tracking station, or vab with the gui open (and it gets worse with settings open too)
<queqiao--> <e​zs​na​ck​> i didnt but i close ltp straight away after liftoff always, and you have no reason not to tbf :V
<queqiao--> <e​zs​na​ck​> when manually warping to a direct tli window i didnt notice any performance impact btw, but im not on the latest version, you should make releases so i know how far behind i am lol
<queqiao--> Reply to "e​zs​na​ck​: when manually warping to a direct tli window i didnt notice any performance impact btw, b..."
<queqiao--> <C​la​ye​l> i should probably figure out how to do releases
<queqiao--> <e​gg​> Isn’t LTP Butcher’s ? Clearly the versions should be named after cats.
<queqiao--> <C​la​ye​l> he's using my https://github.com/Clayell/LunarTransferPlanner/tree/2.0.0 fork
<queqiao--> <e​zs​na​ck​> they are not, use the correct manouvering frame and move around the timing of the manouver to find where its cheaper
<queqiao--> <K​ag​a> i am using VSO as you told me
<queqiao--> <N​az​fi​b> Does it help if you disable the inclination checkbox before clicking "optimize"?
<queqiao--> Reply to "N​az​fi​b: Does it help if you disable the inclination checkbox before clicking "optimize"?"
<queqiao--> <K​ag​a> i was trying to use it to find the cheapest maneouver
<queqiao--> <N​az​fi​b> But does your Venus orbit need to be equatorial, or is a polar flyby also acceptable?
<queqiao--> <K​ag​a> i tried fiddling the edjustment, its taking me 400dv
<queqiao--> <e​zs​na​ck​> optimize only finds the local minima, if you are not even close to the optimal position to burn at it wont be useful
<queqiao--> <e​zs​na​ck​> the bulk of the correction should be prograde or retrograde and done right after TVI cutoff
<queqiao--> Reply to "e​zs​na​ck​: optimize only finds the local minima, if you are not even close to the optimal position t..."
<queqiao--> <K​ag​a> i followed as TWP told me
<queqiao--> <e​zs​na​ck​> and the manouvering frame has to be ECI, which is completely unrelated to the visualization reference frame which should be VSO or any venus centered frame
<queqiao--> <e​zs​na​ck​> as a easy rule of thumb you want your manoeuvreing frame to be set to inertial body centered of the body you are orbiting in 99% of cases
<queqiao--> <K​ag​a> i did that too, im just having a hard time finding the best time to maneouver, seems like a chore
<queqiao--> <e​zs​na​ck​> when the mouse is over the principia window the camera starts spinning as if im in ecef
<queqiao--> Reply to "e​zs​na​ck​: "
<queqiao--> <K​ag​a> the majority of my DV it says it will burn will be on the Normals
<queqiao--> <N​az​fi​b> Disable the checkbox to the right of the inclination field, and then click 'optimize' again. What does it give you?
<queqiao--> <K​ag​a> 465 dv.
<queqiao--> <e​zs​na​ck​> but why cant we read 😢
<queqiao--> Reply to "e​zs​na​ck​: read"
<queqiao--> <K​ag​a> whats the problem? u said VSO
<queqiao--> <N​az​fi​b> And the initial manoeuvre did result in an intercept, meaning that all this is because of an inaccurate execution of the manoeuvre?
<queqiao--> Reply to "e​zs​na​ck​: but why cant we read 😢"
<queqiao--> Reply to "K​ag​a: whats the problem? u said VSO"
<queqiao--> <e​zs​na​ck​> go back and read all the messages very carefully
<queqiao--> <K​ag​a> i cant see the error of what i read, care to tell me?
<queqiao--> <K​ag​a> im like, looking at my monitor very closely and reading it aloud
<queqiao--> Reply to "e​zs​na​ck​: "
<queqiao--> <K​ag​a> but the ECI is already done/ejection?
<queqiao--> <K​ag​a> do you mean using ECI for edjusting?
<queqiao--> <N​az​fi​b> By the way, if you're on dev MJ, upgrade to TWP2 from https://discord.com/channels/319857228905447436/850388104313569350/1276163824545828885
<queqiao--> <N​az​fi​b> It is much more accurate when using Principia.
<queqiao--> <e​zs​na​ck​> you are orbiting earth so your frame is ECI, its that easy, if you are orbiting the sun its HCI
<queqiao--> Reply to "e​zs​na​ck​: you are orbiting earth so your frame is ECI, its that easy, if you are orbiting the sun i..."
<queqiao--> <K​ag​a> but i am not orbiting anymore, i am ejecting as we speak?
<queqiao--> <e​zs​na​ck​> changing manouvering frame changes the meaning of what prograde is, if you look at the manouver node you will see the 3 component rotating based on the current manouvering frame
<queqiao--> Reply to "K​ag​a: but i am not orbiting anymore, i am ejecting as we speak?"
<queqiao--> <e​zs​na​ck​> idk you dont understand reference frames, idk how to explain this lol
<queqiao--> <e​zs​na​ck​> just because you are on a hyperbolic trajectory it doesnt mean you arent orbiting earth
<queqiao--> <e​zs​na​ck​> your prograde motion with respect to venus is not the same as your prograde motion with respect to earth
<queqiao--> <K​ag​a> so do i manouver with HCI?
<queqiao--> <e​zs​na​ck​> as i said unless you understand reference frames idk how to explain this
<queqiao--> <e​gg​> Which direction do you want to burn in?
<queqiao--> <R​OB​ot​ 2​.0​> Download the latest version of Principia from https://github.com/mockingbirdnest/Principia/blob/master/README.md; make sure to download the right one for the version of KSP that you are using (otherwise the game will crash on load).
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> whoops wrong command
<queqiao--> <R​OB​ot​ 2​.0​> https://github.com/mockingbirdnest/Principia/wiki/Concepts
<queqiao--> Reply to "e​gg​: Which direction do you want to burn in?"
<queqiao--> <K​ag​a> idk, i just want my encounter 200km close
<queqiao--> <K​ag​a> thats why im fiddling around with prograde and retrograde as told
<queqiao--> <K​ag​a> but the trajectory is overshooting "North and south" of venus
<queqiao--> <K​ag​a> at the cost of 400dv
<queqiao--> <e​gg​> Anyway, the manœuvre frame discussion seems to be a distraction if you were using the optimizer to start with (that should be insensitive to the change of basis).
<queqiao--> Reply to "N​az​fi​b: And the initial manoeuvre did result in an intercept, meaning that all this is because of..."
<queqiao--> <e​gg​> I don’t think you answered this question by Nazfib ?
<queqiao--> Reply to "e​gg​: I don’t think you answered this question from Nazfib ?"
<queqiao--> <K​ag​a> i already answered, i followed TWP data?
<queqiao--> <e​gg​> OK, but but when you put the data from TWP into the planner, before actually executing the plan, was the plan any good?
<queqiao--> <K​ag​a> i didnt bother checking the trajectory, i trusted TWP, assuming it would do the correct dv
<queqiao--> <K​ag​a> like pre- principia gameplays i did
<queqiao--> Reply to "e​gg​: Anyway, the manœuvre frame discussion seems to be a distraction if you were using the opt..."
<queqiao--> <e​zs​na​ck​> it actually isnt, someetimes it can find an equivalent solution in the wrong frame but it finds it more quickly and more frequently with the correrect manouvering frame
<queqiao--> Reply to "K​ag​a: i didnt bother checking the trajectory, i trusted TWP, assuming it would do the correct i..."
<queqiao--> <K​ag​a> when else am i supposed to burn and know how much prograde i have to churn out???
<queqiao--> Reply to "K​ag​a: i didnt bother checking the trajectory, i trusted TWP, assuming it would do the correct i..."
<queqiao--> <e​gg​> There’s your problem, I think. Are you at least using the TWP2 Nazfib linked?
<queqiao--> <K​ag​a> there is a TWP 2??
<queqiao--> <e​gg​> Please read the most recent message from Nazfib in this channel.
<queqiao--> Reply to "N​az​fi​b: By the way, if you're on dev MJ, upgrade to TWP2 from https://discord.com/channels/319857...";
<queqiao--> <e​gg​> here.
<queqiao--> <e​zs​na​ck​> hes in the correct window because twp says 114 and the planned arrival is 118 days, its just a matter of understanding where to correct and what the correct frame is :V
<queqiao--> <K​ag​a> damn, my gameplay is broken then. do i have to restart the game when redownloading TWP2?
<queqiao--> <K​ag​a> like, delete my campaign
<queqiao--> Reply to "e​zs​na​ck​: hes in the correct window because twp says 114 and the planned arrival is 118 days, its j..."
<queqiao--> <e​gg​> Correct window, yes, but executing without first adjusting the burn, and then optimizing what came out of the blind burn, seems to be the wrong order to do things in…
<queqiao--> Reply to "e​gg​: Correct window, yes, but executing without first adjusting the burn, and then optimizing ..."
<queqiao--> <K​ag​a> idk man, is it even counted as blind if i trusted the machine?
<queqiao--> <e​zs​na​ck​> 100% but luckily it worked so it is what it is :V
<queqiao--> <e​gg​> Yes, because you trusted a machine that doesn’t actually do what you think it does
<queqiao--> <K​ag​a> so the fix should be TWP2 for principia rn, correct?
<queqiao--> <e​gg​> And looking at what you are doing
<queqiao--> <e​zs​na​ck​> from your last screenshot, you have a manoeuvre in 2 days, how does that correlate to what i typed earlier https://media.discordapp.net/attachments/480397772248580098/1383492268484333658/image.png?ex=684efd14&is=684dab94&hm=1dae748bf73881f1c8aa14790a602aa676c45bc5a48319589e2a8327ee305d79&
<queqiao--> Reply to "e​zs​na​ck​: from your last screenshot, you have a manoeuvre in 2 days, how does that correlate to wha..."
<queqiao--> <K​ag​a> yeah, i assumed if i adjust earlier, the burn would be cheaper
<queqiao--> Reply to "K​ag​a: so the fix should be TWP2 for principia rn, correct?"
<queqiao--> <e​zs​na​ck​> the fix is understanding what is happening
<queqiao--> <e​zs​na​ck​> right after != 2 days
<queqiao--> <e​zs​na​ck​> it means RIGHT AFTER
<queqiao--> <K​ag​a> so how long should that be? 1h?
<queqiao--> <e​zs​na​ck​> are you kidding me?
<queqiao--> Reply to "e​zs​na​ck​: are you kidding me?"
<queqiao--> <K​ag​a> i mean, if that worked with how i maneouver with the moon TLI, i thought it should??
<queqiao--> <e​zs​na​ck​> the engine cuts off, you pause the game and plot the new burn in 10 seconds lol
<queqiao--> Reply to "K​ag​a: i mean, if that worked with how i maneouver with the moon TLI, i thought it should??"
<queqiao--> <e​zs​na​ck​> works != optimal
<queqiao--> <e​gg​> ezsnack, I think this is missing the core of the issue.
<queqiao--> <e​zs​na​ck​> that we dont understand reference frames yes 😢
<queqiao--> <e​gg​> The point here is that the first burn is so bad that it is incorrigible, because it was not actually checked using the planner.
<queqiao--> Reply to "e​gg​: The point here is that the first burn is so bad that it is incorrigible, because it was n..."
<queqiao--> <e​zs​na​ck​> he has a closest approach and the travel time matches-ish twp so this is surely salvageable
<queqiao--> <e​gg​> The computations made by TWP, as far as I understand, solve for a high-energy approximation; especially with TWP2, that is going to be good enough for fast transfers, but it is still not exactly what will come out of the actual flight simulated by Principia.
<queqiao--> <K​ag​a> good thing the sim is 400 days away..
<queqiao--> Reply to "e​gg​: The computations made by TWP, as far as I understand, solve for a high-energy approximati..."
<queqiao--> <e​zs​na​ck​> you can "make them match" by adjusting ignition timing and prograde dv of the TVI, at the end of the day you can surely obtain exactly the same window as TWP is telling you
<queqiao--> <e​gg​> Sure, but you need to adjust those before you actually execute the injection burn, and looking at where you will end up.
<queqiao--> <e​zs​na​ck​> just a matter of playing with timing and prograde component, but after the burn is done the timing becomes radial
<queqiao--> <e​zs​na​ck​> but since he got a closest approach he might not match the travel time exactly but he can still get a low PE with mostly a prograde burn
<queqiao--> Reply to "e​zs​na​ck​: he has a closest approach and the travel time matches-ish twp so this is surely salvageab..."
<queqiao--> <e​gg​> Having a closest approach is a very meaningless thing in Principia, that is true unless you have managed to run away from the planet entirely.
<queqiao--> <e​zs​na​ck​> yea i didnt mean it as strictly the PE marker appearing which always does in principia ofc xd
<queqiao--> Reply to "K​ag​a: i mean, if that worked with how i maneouver with the moon TLI, i thought it should??"
<queqiao--> <e​zs​na​ck​> step by step.
<queqiao--> <e​zs​na​ck​> right after TVI cuts off, reset the flight plan to blank and rebase
<queqiao--> <e​zs​na​ck​> set maneuvering frame to ECI and reference frame to VCI/VSO
<queqiao--> <e​zs​na​ck​> set the timing of the node to 1 minute away or w/e it takes your craft to rotate to the aim it.
<queqiao--> <e​zs​na​ck​> only change prograde and retrograde to get the lowest PE at venus that you can.
<queqiao--> <e​zs​na​ck​> let the optimizer do the rest.
<queqiao--> Reply to "e​zs​na​ck​: step by step. right after TVI cuts off, reset the flight plan to blank and rebase set man..."
<queqiao--> <K​ag​a> Right after i downloaded TWP2?
<queqiao--> <e​zs​na​ck​> step by step.
<queqiao--> <e​zs​na​ck​> right after TVI cuts off, reset the flight plan to blank and rebase
<queqiao--> <e​zs​na​ck​> set maneuvering frame to ECI and reference frame to VCI/VSO
<queqiao--> <e​zs​na​ck​> set the timing of the node to 1 minute away or w/e it takes your craft to rotate to aim it.
<queqiao--> <e​zs​na​ck​> only change prograde and retrograde to get the lowest PE at venus that you can.
<queqiao--> <e​zs​na​ck​> let the optimizer do the rest.
<queqiao--> <e​zs​na​ck​> (if the optimizer adds too much radial component at this point it means that your burn was too late or early)
<queqiao--> <K​ag​a> I should not use my current TWP
<queqiao--> <e​zs​na​ck​> i never spotted any difference, they both work fine
<queqiao--> Reply to "e​zs​na​ck​: step by step. right after TVI cuts off, reset the flight plan to blank and rebase set man..."
<queqiao--> <e​gg​> (I would add a step of looking at the planned TVI first, and running a round of optimizer the TVI burn itself if it does not get to the right periapsis to start with.)
<queqiao--> <e​zs​na​ck​> step by step.
<queqiao--> <e​zs​na​ck​> right after TVI cuts off, reset the flight plan to blank and rebase
<queqiao--> <e​zs​na​ck​> set maneuvering frame to ECI and reference frame to VCI/VSO
<queqiao--> <e​zs​na​ck​> set the timing of the node to 1 minute away or w/e it takes your craft to rotate to aim it.
<queqiao--> <e​zs​na​ck​> only change prograde and retrograde to get the lowest PE at venus that you can.
<queqiao--> <e​zs​na​ck​> let the optimizer do the rest.
<queqiao--> <e​zs​na​ck​> (if the optimizer adds too much radial component at this point it means that your burn was too late or early)
<queqiao--> Reply to "e​gg​: (I would add a step of looking at the planned TVI first, and running a round of optimizer..."
<queqiao--> <e​zs​na​ck​> for sure, this was only after TVI, assuming we do what you said earlier ahahahah
<queqiao--> <e​gg​> Right, but the correction should be a correction; here the problem Kaga has is that the correction is actually emergency planning.
<queqiao--> <e​zs​na​ck​> i usually need less than 10m/s of total correction from ejection to arrival lol
<queqiao--> <e​zs​na​ck​> thanks to the op burn integrator
<queqiao--> <e​zs​na​ck​> btw its also a possibility that he waited too many orbits and the LAN shifted lol
<queqiao--> Reply to "e​zs​na​ck​: btw its also a possibility that he waited too many orbits and the LAN shifted lol"
<queqiao--> <K​ag​a> Actually yeah.. i was using the Agena engine so i had to wait 3h to safely ignite
<queqiao--> <e​zs​na​ck​> 3h isnt meaningful
<queqiao--> Reply to "e​zs​na​ck​: 3h isnt meaningful"
<queqiao--> <K​ag​a> Took me 4 rotations?
<queqiao--> <e​zs​na​ck​> which wont shift the LAN in a meaningful way at all
<queqiao--> <K​ag​a> But you said waiting too many orbits, thought 4 is too much already
<queqiao--> <e​zs​na​ck​> 3h is 2 orbits and i literally just told you its not meaningful
<queqiao--> <K​ag​a> I was just saying my train of thought
<queqiao--> Reply to "K​ag​a: Actually yeah.. i was using the Agena engine so i had to wait 3h to safely ignite"
<queqiao--> <N​az​fi​b> By the way, this is not a thing anymore (except for a couple of very late configs); the Agena engine can reignite at any time now.
<queqiao--> <K​ag​a> Oh? So its like a normal ullage engine like the rest now?
<queqiao--> <K​ag​a> I use the ba-11 model
<queqiao--> <b​al​li​st​ic​fo​x> I understand asking this is probably a bit of a cardinal sin but with the rise of another broken mod (Tilt'em) I believe the KSP community is in desperate need of a
<queqiao--> <b​al​li​st​ic​fo​x> With the rise of another broken mod (Tilt'em) I believe the KSP community is in desperate need of a system that properly handles axial tilt and various other problems the stock game has (persistent rotation being one of them)
<queqiao--> <b​al​li​st​ic​fo​x> I understand asking this is probably a bit of a cardinal sin but how difficult would it be in theory to change principia's integrator to run a two-body approach
<queqiao--> <b​al​li​st​ic​fo​x> It would be incredibly ideal if everyone just moved to n-body, but that's "difficult" or something along those lines
<queqiao--> <A​l₂​Me​₆> Ignoring all the technical problems which I am not qualified to comment on: I don't think the n-bodiness is what makes Principia unpalatable to most players. If you don't do wacky things you won't really see n-body effects, after all. Even if you somehow managed to make the mod 2-bodied that doesn't remove any of the complexities of reference frames and whatnot.
<queqiao--> <b​al​li​st​ic​fo​x> That's understandable
<queqiao--> <A​l₂​Me​₆> And to comment briefly on the technical side to the extent that I understand: no, I don’t think that’s possible. For one you’d break all sorts of continuity assumptions made by the trajectory representation. Nor does Principia have any conception of SOI.
<queqiao--> <b​al​li​st​ic​fo​x> Would princpia's trajectory representation even be needed? I somewhat naively assumed the stock trajectory lines would be sufficient
<queqiao--> <e​gg​> If you wish to tilt an apple pie, you must first tilt the universe.
<queqiao--> <A​l₂​Me​₆> The only reason Principia is able to overcome the challenges that the stock attempts are not is because it keeps track of everything itself, every frame, and completely overwrites KSP’s own information. If you remove that then you’re back to square one.
<queqiao--> <b​al​li​st​ic​fo​x> I mean principia already has the option to display stock orbit lines in game yes?
<queqiao--> <e​gg​> Sure, but that is just for show. The underlying trajectories still need to be computed and represented.
<queqiao--> <b​al​li​st​ic​fo​x> Are you saying there'd be a mismatch between stock ksp's two body trajectory lines and and the hypothetical principia's two body trajectory lines?
<queqiao--> <e​gg​> I am not saying much, but Al₂Me₆ is pointing out that if your forces have discontinuities, woe betide your integrator (and the interpolations we use in various places in various computations).
<queqiao--> <b​al​li​st​ic​fo​x> Unfortunate.
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> there’s always the option of fade in the SOI transition
<queqiao--> <b​al​li​st​ic​fo​x> Alas, back to tinkering with Tilt'em
<queqiao--> <b​al​li​st​ic​fo​x> that's not exactly the problem
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> like, an inner and outer SOI
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> That avoids the discontinuity
<queqiao--> Reply to "G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​): there’s always the option of fade in the SOI transition"
<queqiao--> <A​l₂​Me​₆> The issues of unphysicality cannot be fixed by introducing further unphysicality.
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> (sort of, if you set it up right)
<queqiao--> Reply to "A​l₂​Me​₆: The issues of unphysicality cannot be fixed by introducing further unphysicality."
<queqiao--> <b​al​li​st​ic​fo​x> Indeed yeah
<queqiao--> Reply to "b​al​li​st​ic​fo​x: With the rise of another broken mod (Tilt'em) I believe the KSP community is in desperate..."
<queqiao--> <C​la​ye​l> havent heard of this mod, ckan says the last release was in 2020 for 1.7?
<queqiao--> Reply to "b​al​li​st​ic​fo​x: Are you saying there'd be a mismatch between stock ksp's two body trajectory lines and an..."
<queqiao--> <e​gg​> As for that… probably, because these systems tend to amplify errors, and in that hypothetical you are using very different methods for those two computations, which are going to behave a bit differently at the edges.
<queqiao--> Reply to "C​la​ye​l: havent heard of this mod, ckan says the last release was in 2020 for 1.7?"
<queqiao--> <b​al​li​st​ic​fo​x> It had an incompatible harmony version which recently someone patched and rereleased on spacedock, with the person updating the mod completely ignorant of the underlying problems when crossing the inverseRotThreshold
<queqiao--> <b​al​li​st​ic​fo​x> Got (thankfully) held the CKAN release until they've proven they've fixed the underlying issues
<queqiao--> <C​la​ye​l> i really want to see that conversation, cant find it in the netkan github
<queqiao--> <b​al​li​st​ic​fo​x> It was in the Kopernicus discord server, they hadn't even released a proper fork of it on GitHub until about half an hour ago when I mentioned it to them..
raptop has quit [Ping timeout: 190 seconds]
raptop has joined #principia
<queqiao--> <s​ic​he​lg​ai​ta​> Not wanting to shoot the messenger, but I wish this topic was not rearing its ugly head every six months. The interesting question is not "how difficult would it be?" it is "who is going to do it?". Because, scoop, it's not me. Very, very few people have demonstrated that they have the skills necessary to dive into the guts of the Principia C++ code and do useful changes there. And even if that happened, I
<queqiao--> don't want to maintain the code that makes Principia 2-body. So we are looking at a fork, and that fork is probably going to turn into abandonware after 6 months because, believe it or not, keeping up with our updates would be real work.
<queqiao--> <e​zs​na​ck​> just for curiosity what would it take to port principia to another space sim
<queqiao--> <s​ic​he​lg​ai​ta​> Hmm, that's a good question. Principia has about 180 kSLOCs (including tests). The bulk of the basic math and physics could be reused verbatim. But large parts of the (C++ and C#) code that interfaces with KSP would need to be rewritten: it's not even clear that the concepts would make sense in a different game (I guess some would, some wouldn't). That interfacing code is about 40 kSLOCs, so 20% of the total.
<queqiao--> It took us 10 years to write Principia, so I'd say 2 years (of course, it's not just coding, it's all the learning curve and discovery of figuring out how to do things).
<queqiao--> <s​ic​he​lg​ai​ta​> (Cross-checking that number, I produce professionally in the order of 20-30 kSLOCs of new code per year, it's two of us working on Principia, but we don't do that 40 hours a week, so the numbers seem to add up.)
<queqiao--> <e​zs​na​ck​> 10 years to bring it to where it is, not to a playable state tho, right?
<queqiao--> <s​ic​he​lg​ai​ta​> Yes, to where it is now.
<queqiao--> <e​zs​na​ck​> Very insightful 👍
<queqiao--> <e​gg​> Though of course the definition of playable is largely in the eye of the player. We had three versions before we got around to saving Principia’s internal state, so you would lose histories and the solar system would be picked up from whatever KSP gave us every time you changed scenes. And by the time we had serialization, it had already been a year.
<queqiao--> <e​zs​na​ck​> How long did it take from having the idea to the first working n body simulator
<queqiao--> <s​ic​he​lg​ai​ta​> 2 weeks?
<queqiao--> <s​ic​he​lg​ai​ta​> The thing is that the basic math/physics is really easy. The hard part is putting it into a game that is moderately enjoyable.
<queqiao--> <s​ic​he​lg​ai​ta​> We only had flight planning two years after the start of the project. Before that it was "seat of your pants". It took us a long to time to understand what kind of planning was useful/interesting and how to present it to the user.
<queqiao--> Reply to "s​ic​he​lg​ai​ta​: Not wanting to shoot the messenger, but I wish this topic was not rearing its ugly head e..."
<queqiao--> <b​al​li​st​ic​fo​x> I apologize if it seemed like I was implying I wanted the principia team to do it, my question was merely on the feasibility of the subject matter and whether that would be a useful approach to the problem
<queqiao--> <s​ic​he​lg​ai​ta​> Not wanting to shoot the messenger, but I wish this topic was not rearing its ugly head every six months. The interesting question is not "how difficult would it be?" it is "who is going to do it?". Because, scoop, it's not me. Very, very few people have demonstrated that they have the skills necessary to dive into the guts of the Principia C++ code and do useful changes there. And even if that happened, I
<queqiao--> don't want to maintain the code that makes Principia 2-body. So we are looking at a fork, and that fork is probably going to turn into abandonware after 6 months because, believe it or not, keeping up with our updates would be real work.
<queqiao--> <e​gg​> Feasibility really comes in two parts: would someone who knows how to work on Principia be able to do it? (Probably, nothing here is really impossible, but for the reasons Al₂Me₆ pointed out, and probably others, many of which I probably haven’t thought of, it would be a lot of work.) And then, as sichelgaita points out, would someone who knows how to work on Principia want to do it? (No.)
<queqiao--> <l​am​on​t> the question to ask probably isn't how to turn principia into tilt'em but how to fix (or fundamentally completely redesign) tilt'em using knowledge from principia.
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> Yes, but you were so focused on whether you could do it to think about whether you should
<queqiao--> Reply to "l​am​on​t: the question to ask probably isn't how to turn principia into tilt'em but how to fix (or ..."
<queqiao--> <b​al​li​st​ic​fo​x> Principia updates far more than just the axial tilt, and is a much more fleshed out and rounded framework to work off ofTilt'em is extremely hacky and can hardly be considered a minimum viable solution to the problem
<queqiao--> <l​am​on​t> yeah but then you drag all of principia along with you, and you're trying to fix the tilt'em problem by doing major brain surgery to principia to convert n-body physics back to patched conics.
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> Can KSP do axial tilt at all? I remember reading that it could do it for planets other than the home world, is that mistaken?
<queqiao--> <b​al​li​st​ic​fo​x> By default? No
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> And so the entire solar system is inclined 23.5 degrees
<queqiao--> <b​al​li​st​ic​fo​x> https://github.com/LunaMultiplayer/TiltEm/wiki
<queqiao--> <b​al​li​st​ic​fo​x> if you're curious on how TiltEm functions
<queqiao--> Reply to "G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​): And so the entire solar system is inclined 23.5 degrees"
<queqiao--> <b​al​li​st​ic​fo​x> Correct yeah, they use FK4 as the reference frame with the reference plane described as:
<queqiao--> <b​al​li​st​ic​fo​x> Reference epoch: B1950.0
<queqiao--> <b​al​li​st​ic​fo​x> X-Y plane: plane of the Earth's mean equator at the reference epoch
<queqiao--> <b​al​li​st​ic​fo​x> X-axis : out along ascending node of instantaneous plane of the Earth's
<queqiao--> <b​al​li​st​ic​fo​x> orbit and the Earth's mean equator (equinox) at the reference epoch
<queqiao--> <b​al​li​st​ic​fo​x> Z-axis : along the Earth mean north pole at the reference epoch
<queqiao--> <b​al​li​st​ic​fo​x> Describing the "correct" reference frame in RSS without principia is effectively impossible because there's no axial tilt
<queqiao--> <l​am​on​t> so you need to worry about reference frames and transitions between different reference frames on SOI boundaries (and need to be careful about atittude and angular velocity), but you don't need all of principia to do that, and principia doesn't have a monopoly on reference frames.
<queqiao--> <b​al​li​st​ic​fo​x> I'm aware the problem can be solved without principia and I'm not sure where exactly you're pulling the SOI boundary problems from, those happen in an inertial reference frame and are irrelevant as far as I'm aware
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> Well, SOIs are a gradual transition in N-body, not a sharp all-or-nothing line. That’s what I think was being talked about earlier with force discontinuities
<queqiao--> <G​oF​or​PD​I ​(l​es​s ​dr​ag​=m​or​e ​fa​st​er​)> The SOI line is simply where the gravity of the primary and secondary body are equal