raptop changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Fréchet. We currently target 1.5.1, 1.6.1, and 1.7.x. <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… | <egg> also 4e16 m * 2^-52 is uncomfortably large
Raidernick_ has quit [Quit: Leaving]
Raidernick has joined #principia
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
Mike` has quit [Ping timeout: 190 seconds]
egg|laptop|egg has quit [Read error: Connection reset by peer]
Mike` has joined #principia
<_whitenotifier-d13c> [Principia] coffeehat starred Principia - https://git.io/Jfff4
_whitenotifier-d13c has quit [*.net *.split]
kmath has quit [*.net *.split]
_whitenotifier-d13c has joined #principia
kmath has joined #principia
<discord-_> H​aukifile. — @egg I managed to record a journal of the `Check failed: 0 <= r (0 vs. -1) ` crash, I'll share the file once the upload is done. Do you want me to open a new issue on github?
egg|laptop|egg has joined #principia
egg|laptop|egg has quit [Remote host closed the connection]
<discord-_> e​gg. — Yeah that is a good way to track issues
<discord-_> e​gg. — Better than discord at least
<_whitenotifier-d13c> [Principia] Haukifile opened issue #2530: Principia crash when decoupling with msg Check failed: 0 <= r (0 vs. -1) - https://git.io/Jffnj
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 190 seconds]
egg|cell|egg has joined #principia
egg|laptop|egg has joined #principia
egg|laptop|egg has quit [Ping timeout: 378 seconds]
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 190 seconds]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 204 seconds]
egg|cell|egg has joined #principia
egg|laptop|egg has joined #principia
egg|cell|egg has quit [Ping timeout: 378 seconds]
egg|cell|egg has joined #principia
goblin has joined #principia
<goblin> Hello :-) If I want a contraption to stay in a special point (i.e. Lagrange or keosync), is there some smart controller that'll keep nudging it in the right directions once I'm off doing other things? Or do I have to check back every now and then and nudge it manually?
<discord-_> S​ir Mortimer. — manually, I'm afraid.
<goblin> OK, thanks :-)
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #principia
<discord-_> e​gg. — you can however use the orbit analysis tool to help you check how long you stay close enough/how far you run away
<discord-_> e​gg. — goblin ^
egg|laptop|egg_ has joined #principia
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|laptop|egg has quit [Ping timeout: 378 seconds]
<_whitenotifier-d13c> [Principia] DarthPointer opened issue #2531: Make orbital analysis window available in tracking station - https://git.io/Jff6n
egg|laptop|egg_ has quit [Ping timeout: 190 seconds]
<discord-_> S​ir Mortimer. — pretty pictures!
<_whitenotifier-d13c> [Principia] DarthPointer commented on issue #2531: Make orbital analysis window available in tracking station - https://git.io/JffiJ
<discord-_> n​eph. — Fantastic
<discord-_> A​cer_Saccharum. — how are the ground-track figures made?
<_whitenotifier-d13c> [Principia] pleroy commented on issue #2530: Principia crash when decoupling with msg Check failed: 0 <= r (0 vs. -1) - https://git.io/JffPr
<_whitenotifier-d13c> [Principia] pleroy labeled issue #2530: Principia crash when decoupling with msg Check failed: 0 <= r (0 vs. -1) - https://git.io/Jffnj
<discord-_> A​cer_Saccharum. — nCI (n-Centered Inertial) reference frames are inertial, they fix the center of the body (ECI earth-centered inertial, MCI for mars, VCI for venus, and so on)
<discord-_> A​cer_Saccharum. — they are the most similar to the stock KSP reference frames
<discord-_> A​cer_Saccharum. — .
<discord-_> A​cer_Saccharum. — nCnF (n-Centered n-Fixed) frames are surface fixed, they set the center of body n as the origin, and rotate along with the surface of body n
<discord-_> A​cer_Saccharum. — these are good for planning satellite ground-tracks, and especially good for geostationary orbits
<discord-_> A​cer_Saccharum. — a geostationary orbit in ECEF would look like a small loop or tightly curled spirograph-like shape
<discord-_> A​cer_Saccharum. — .
<discord-_> A​cer_Saccharum. — nCmA (n-Centered m-Aligned) frames set the center of body n as the origin, and rotate such that the center of body m is fixed with respect to the origin
<discord-_> A​cer_Saccharum. — ECSA for example fixes the center of the earth as the origin, and rotates such that the sun is "stationary"
<discord-_> A​cer_Saccharum. — this is good for setting up sun-synchronous orbits, and can work for lagrange points
<discord-_> A​cer_Saccharum. — .
<discord-_> A​cer_Saccharum. — nmB (n-m Barycentric) frames are centered on the barycenter between object n and object m, and additionally fix the positions of body n and body m
<discord-_> A​cer_Saccharum. — EMB in this case sets the origin to be the earth-moon barycenter, and rotates along with the moon around the barycenter
<discord-_> A​cer_Saccharum. — this is good for working with lagrange points of body m around body n
<discord-_> A​cer_Saccharum. —
<discord-_> A​cer_Saccharum. — reposted from https://discordapp.com/channels/319857228905447436/319857228905447436/700443676307882055 and the following few messages
<discord-_> A​cer_Saccharum. — at least this is what I have figured out after playing almost exclusively with Principia for around a year
UmbralRaptop has quit [Remote host closed the connection]
<discord-_> A​cer_Saccharum. — the Target-centric frames are a little more arcane to me at least
UmbralRaptop has joined #principia
egg|cell|egg has joined #principia
<discord-_> A​cer_Saccharum. — nCI (n-Centered Inertial) reference frames are inertial, they fix the center of the body (ECI earth-centered inertial, MCI for mars, VCI for venus, and so on)
<discord-_> A​cer_Saccharum. — they are the most similar to the stock KSP reference frames
<discord-_> A​cer_Saccharum. — .
<discord-_> A​cer_Saccharum. — nCnF (n-Centered n-Fixed) frames are surface fixed, they set the center of body n as the origin, and rotate along with the surface of body n
<discord-_> A​cer_Saccharum. — these are good for planning satellite ground-tracks, and especially good for geostationary orbits
<discord-_> A​cer_Saccharum. — a geostationary orbit in ECEF would look like a small loop or tightly curled spirograph-like shape
<discord-_> A​cer_Saccharum. — .
<discord-_> A​cer_Saccharum. — nCmA (n-Centered m-Aligned) frames set the center of child body n as the origin, and rotate such that the center of parent body m is fixed with respect to the origin
<discord-_> A​cer_Saccharum. — ECSA for example fixes the center of the earth as the origin, and rotates such that the sun is "stationary"
<discord-_> A​cer_Saccharum. — this is good for setting up sun-synchronous orbits, and can work for Lagrange points
<discord-_> A​cer_Saccharum. — .
<discord-_> A​cer_Saccharum. — nmB (n-m Barycentric) frames are centered on the barycenter between parent body n and child body m, and additionally fix the positions of body n and body m
<discord-_> A​cer_Saccharum. — EMB in this case sets the origin to be the earth-moon barycenter, and rotates along with the moon around the barycenter
<discord-_> A​cer_Saccharum. — this is good for working with Lagrange points of body m around body n
<discord-_> A​cer_Saccharum. —
<discord-_> A​cer_Saccharum. — reposted from https://discordapp.com/channels/319857228905447436/319857228905447436/700443676307882055 and the following few messages (edited)
egg|cell|egg has quit [Read error: Connection reset by peer]
egg|cell|egg has joined #principia
<_whitenotifier-d13c> [Principia] pleroy opened pull request #2532: Do not call C++ with positions, velocities or angular velocities that are NaNs. - https://git.io/Jff1w
egg|cell|egg has quit [Ping timeout: 189 seconds]
egg|cell|egg has joined #principia
<_whitenotifier-d13c> [Principia] Pending. Build queued… - 
<_whitenotifier-d13c> [Principia] Pending. Building… - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4212/
<_whitenotifier-d13c> [Principia] eggrobin labeled pull request #2532: Do not call C++ with positions, velocities or angular velocities that are NaNs. - https://git.io/Jff1w
<discord-_> e​gg. — lots of questions
<discord-_> e​gg. — @Acer_Saccharum the ground track figures are made with https://climserv.ipsl.polytechnique.fr/ixion/, which is made by the author of https://twitter.com/eggleroy/status/1123556005042970624 and used to make the figures in his book.
<kmath> <eggleroy> Michel Capderou (2012), Satellites : de Kepler au GPS. https://t.co/vAqW1Adq8Z
<discord-_> e​gg. — @Acer_Saccharum honestly, the nmB frame is pretty useless in practice. There could be a different barycentric rotating frame, one that is rotating-pulsating, wherein lengths change (i.e., in that frame the earth grows and shrinks), that could be useful for Lagrange points (they are fixed in that frame, so in particular they could be drawn there), but that frame is just utterly weirdly behaved (see: the
<discord-_> e​gg. — the weird behaviour may be confusing to use, and also would very much mess with our libraries that assume that lengths exist
<discord-_> e​gg. — other than that your frame descriptions are KO
<discord-_> e​gg. — other than that your frame descriptions are OK/ (edited)
<discord-_> e​gg. — other than that your frame descriptions are OK (edited)
<discord-_> A​cer_Saccharum. — I personally thought it would be more useful for lagrange points because L4 and L5 are specifically defined wrt the barycenter
<discord-_> A​cer_Saccharum. — L1, L2, and L3 to a similar extent
<discord-_> e​gg. — well, Lagrange points are not defined "with respect to the barycentre"
<discord-_> e​gg. — they are defined "in the rotating-pulsating barycentric frame"
<discord-_> e​gg. — and this is the rotating barycentric frame
<discord-_> e​gg. — turns out dropping the "pulsating" bit makes everything messy
<discord-_> A​cer_Saccharum. — the geometric description of L4 and L5 is defined wrt the barycenter I believe, but I may be wrong
<discord-_> e​gg. — see my replies
<discord-_> A​cer_Saccharum. — yeah I see your point about the barycentric frame being strange, since the earth and moon aren't fixed wrt their barycenter, since the moon's orbit is eccentric
<discord-_> e​gg. — it turns out, e.g., Earth-Moon Lagrange points move less in Moon-centred Earth-fixed than they do in EMB
<discord-_> A​cer_Saccharum. — well that's good to know
<discord-_> e​gg. — no, the geometry doesn't really bring the barycentre in (you don't need the barycentre to define an equilateral triangle Earth-Moon-L4or5), but the *derivation* uses the *barycentric rotating-pulsating reference frame* (not just the barycentre)
<discord-_> A​cer_Saccharum. — I figure that might vary on a case-by-case basis
<discord-_> e​gg. — no
<discord-_> e​gg. — The barycentric rotating frame is really just puissantly useless :-p
<_whitenotifier-d13c> [Principia] Success. Build finished. - http://casanova.westeurope.cloudapp.azure.com:8080/job/Principia/4212/
<discord-_> A​cer_Saccharum. — well now I know not to use it
<discord-_> e​gg. — (I should get rid of it, there is one edge case where people are using it because we are missing a barycentric nonrotating frame)
<discord-_> e​gg. — as for the target frame, it is the same thing as ECSA
<discord-_> e​gg. — except ISS-C Earth-A, for instance
<discord-_> e​gg. — (we call it Target LVLH, because that is what it is called in aerospace)
<discord-_> e​gg. — we should probably rename ECSA to Earth-centred ecliptic or something
<discord-_> e​gg. — (again, because that is the name used)
<discord-_> e​gg. — <body> Centred Orbit, in the general case
<discord-_> e​gg. — ECO
<discord-_> A​cer_Saccharum. — the LVLH part was a little confusing to me, since I'm not sure what the local vertical is
<discord-_> A​cer_Saccharum. — is it the direction perpendicular to both the velocity vector and radial-in direction?
<discord-_> e​gg. — local vertical is down towards the planet
<discord-_> e​gg. — local horizontal is, well, perpendicular to that
<discord-_> e​gg. — in that reference frame, these remain fixed
<discord-_> A​cer_Saccharum. — okay I see now, I was looking at things from the "astrolabe" perspective, rather than the vessel perspective
<discord-_> e​gg. — hence the "local"
<discord-_> A​cer_Saccharum. — okay I see now, I was looking at things from the ~~"astrolabe"~~(wrong word) perspective, rather than the vessel perspective (edited)
<discord-_> A​cer_Saccharum. — okay I see now, I was looking at things from the "celestial sphere" perspective, rather than the vessel perspective (edited)
<_whitenotifier-d13c> [Principia] pleroy closed issue #2530: Principia crash when decoupling with msg Check failed: 0 <= r (0 vs. -1) - https://git.io/Jffnj
<_whitenotifier-d13c> [Principia] pleroy pushed 2 commits to master [+0/-0/±8] https://git.io/JffM7
<_whitenotifier-d13c> [Principia] pleroy 84fb522 - Do not enter the C++ code with positions, velocities or angular velocities that are NaNs.
<_whitenotifier-d13c> [Principia] pleroy 1ed6360 - Merge pull request #2532 from pleroy/2530 Do not call C++ with positions, velocities or angular velocities that are NaNs.
<_whitenotifier-d13c> [Principia] pleroy closed pull request #2532: Do not call C++ with positions, velocities or angular velocities that are NaNs. - https://git.io/Jff1w
<discord-_> B​utcher. — Pretty sure I have used EMB frame for planning lunar intercept.
<discord-_> e​gg. — yeah you should have used MCEA
<discord-_> e​gg. — :-p
<discord-_> B​utcher. — Since it has periapsis points shown.
<discord-_> e​gg. — MCEA has apsides, EMB does not
<_whitenotifier-d13c> [Principia] pleroy commented on issue #2530: Principia crash when decoupling with msg Check failed: 0 <= r (0 vs. -1) - https://git.io/JffMA
<discord-_> e​gg. — so perhaps you were using MCEA
<discord-_> e​gg. — which is what you should be using :D
<discord-_> B​utcher. — Oh, hmm. Maybe it was mcea.
<discord-_> B​utcher. — I thought it was one of the earth frames though. 🤔
<discord-_> e​gg. — (if you want to intercept the moon, you want to see where the moon is, thus M-centred
<discord-_> e​gg. — cat is loudly meowing
<discord-_> B​utcher. — That was before I started doing a lot of automated direct ascent though.
<_whitenotifier-d13c> [Principia] eggrobin commented on issue #2531: Make orbital analysis window available in tracking station - https://git.io/JffDC
<_whitenotifier-d13c> [Principia] eggrobin edited issue #2531: Make orbital analysis window available in tracking station - https://git.io/Jff6n
<_whitenotifier-d13c> [Principia] eggrobin edited issue #2531: Make orbital analysis window available in tracking station - https://git.io/Jff6n
* discord-_ e​gg. — stares at the wording of https://github.com/mockingbirdnest/Principia/issues/2520_
<discord-_> l​pg. — that last sentence
<discord-_> e​gg. — indeed
<discord-_> e​gg. — does this JNSQ thing change the stock clock to follow its 12h time?
<discord-_> B​utcher. — Ouch. It's be tempted to ignore that issue on principle.
<discord-_> B​utcher. — Ouch. I'd be tempted to ignore that issue on principle. (edited)
<discord-_> e​gg. — that is what we have been doing, yes
<goblin> egg, cool
<goblin> does the atmosphere cut off rapidly at 70km as in stock, or does it also contribute to decaying orbits?
<discord-_> e​gg. — no atmospheric drag modelling at this time
<discord-_> P​teropodidae. — > there is one edge case where people are using it because we are missing a barycentric nonrotating frame
<discord-_> P​teropodidae. — What is that edge case?
<discord-_> e​gg. — maybe in a few years, but that would be a lot of work
<goblin> I see. Cool, thanks :-)
<discord-_> e​gg. — @Pteropodidae trajectories around double stars iirc
<discord-_> P​teropodidae. — There's planet packs with binary stars?
<discord-_> e​gg. — apparently
<discord-_> P​teropodidae. — Woah
<discord-_> P​teropodidae. — And TIL nmB is mostly useless
<discord-_> e​gg. — it took me a while to realize that
<discord-_> e​gg. — (obviously, otherwise I would not have added it :D)
<discord-_> P​teropodidae. — So that issue would be sort of like the current body-centered frames but centered on the barycenter instead?
<discord-_> P​teropodidae. — So the frame that fixes that issue would be sort of like the current body-centered frames but centered on the barycenter instead? (edited)
<discord-_> e​gg. — yeah
<discord-_> P​teropodidae. — Implementing a rotating-pulsating barycentric frame doesn't sound fun
<discord-_> P​teropodidae. — Would you need to switch to normalized lengths?
<discord-_> P​teropodidae. — Instead of absolute lengths?
<discord-_> e​gg. — yeah if you want to retain safety in the APIs, you would lose InnerProduct in that type
<discord-_> e​gg. — (and Norm)
<discord-_> e​gg. — an it turns out we use those in the trajectories
<discord-_> P​teropodidae. — Oof
<discord-_> e​gg. — The general principle of these APIs is that they only expose coordinate-free operations
<discord-_> e​gg. — so for instance, InnerProduct exists, because, for some F going from one frame to another InnerProduct(F(v), F(w)) = InnerProduct(v, w)
<discord-_> P​teropodidae. — Is there a workaround in principle, or would that be completely new territory where you have to both design and implement a solution instead of using (relatively) well-known techniques?
<discord-_> e​gg. — nah, it is mostly just a question of tweaking our type system and shuffling calculations around until they happen where we can write them
<discord-_> e​gg. — e.g., we have no cross product, because if F is orientation reversing, F(v) × (w) = -F(v × w)
<discord-_> e​gg. — instead, we distinguish bivectors from vectors, and we have Wedge (takes two vectors, gives you a bivector), Commutator (takes two bivectors, gives you a bivector), and operator* (takes a vector and a bivector, gives you a vector)
<discord-_> e​gg. — so when using physics formulae that do not make those distinctions, × can mean three different things in our APIs
<discord-_> e​gg. — (here there is a similar thing really; you have a distinction between vectors and (forms, covectors, whatever you want to call them) that you do not usually make in classical physics)
<discord-_> e​gg. — (here there is a similar thing really; by losing the inner product you need a distinction between vectors and (forms, covectors, whatever you want to call them) that you do not usually make in classical physics) (edited)
<discord-_> P​teropodidae. — Hrm
<discord-_> e​gg. — I mean, in theory you would even lose angles, except that this is actually isotropically dilating so you still have angles
<discord-_> P​teropodidae. — isotropically dilating?
<discord-_> e​gg. — homothetic
<discord-_> e​gg. — (ask question about greek word, get another greek word in reply)
<discord-_> P​teropodidae. — /slap
<discord-_> P​teropodidae. — /slap dictionary (edited)
<discord-_> e​gg. — (it grows the same in all directions)
<discord-_> P​teropodidae. — Thanks
<discord-_> P​teropodidae. — All this is a bit out of my wheelhouse
<discord-_> P​teropodidae. — Would this make showing apsides impossible, since you no longer have absolute distances to show? Or can you still convert normalized distances to something a KSP player might expect?
<discord-_> e​gg. — it would be unprincipled to show apsides
<discord-_> P​teropodidae. — Also, I'd guess showing planetary distortions to account for length contractions means taking over even more drawing functionality from KSP?
<discord-_> e​gg. — nah
<discord-_> e​gg. — simply, the surface would not be fixed in that reference frame
<discord-_> e​gg. — the things that are not fixed are still drawn, they just move
<discord-_> e​gg. — so just like the moon moves when the camera is in ECI, the earth would grow in the rotating pulsating frame
<discord-_> e​gg. — and as a result, you might see a trajectory that goes through the (current) earth but actually does not reenter, because the earth would have changed size by then
<discord-_> e​gg. — which is why showing apsides would be unprincipled
<discord-_> e​gg. — at least altitudes
<discord-_> e​gg. — it would be a massively unintuitive frame
<discord-_> P​teropodidae. — Ah
<discord-_> P​teropodidae. — I kind of want to see the "bug" reports you might get if you ever implement that feature
<discord-_> P​teropodidae. — Alternatively, when you first use that mode in the flight planner pop up a big window showing "THIS FRAME IS FOR ADVANCED USERS. READ THE DOCUMENTATION"
<discord-_> P​teropodidae. — And then watch the bug reports flow in anyways
<discord-_> l​pg. — just make the navball nyancats, then no one will want to use it
<discord-_> P​teropodidae. — So one advantage for a rotating-pulsating barycentric frame is being able to properly render lagrange points
<discord-_> P​teropodidae. — Are there other reasons you'd want to implement such a frame?
<discord-_> e​gg. — none at all.
<discord-_> e​gg. — > By a strange coincidence “None at all” is exactly how much suspicion the ape-descendant Arthur Dent had that one of his closest friends was not descended from an ape, but was, in fact, from a small planet somewhere in the vicinity of Betelgeuse.