egg|zzz|egg changed the topic of #principia to: READ THE FAQ: http://goo.gl/gMZF9H; The current version is Clifford. We currently target 1.2.2, and 1.3.1. <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/
awang has quit [Ping timeout: 198 seconds]
awang has joined #principia
Raidernick_ has joined #principia
Raidernick has quit [Ping timeout: 383 seconds]
NathanKell|AFK is now known as NathanKell
NathanKell is now known as NathanKell|Twitch
CommandoDiamond has quit [Read error: Connection reset by peer]
icefire has quit [Quit: Leaving]
NathanKell|Twitch is now known as NathanKell
<lamont>
egg: you know if you want to just give me the API with no backtracking, we could test it out and see if it works
Mike` has quit [Ping timeout: 182 seconds]
ferram4 has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
ferram4 has joined #principia
Mike` has joined #principia
<GH>
[Principia] lamont-granquist commented on issue #1659: Actually I think I would like to see the API without backtracking -- just give the first point in the trajectory if it is the closest point. And then we can go from there and determine if backtracking is actually necessary or not. That would simplify what you need to do in order to deliver the endpoint. Then I can plug it into PEG and see how it explodes or not. If it doesn't explode then there's ob
NolanSyKinsley has quit [Remote host closed the connection]
NathanKell is now known as NathanKell|Twitch
NathanKell|Twitch is now known as NathanKell
NathanKell is now known as NathanKell|AFK
<egg|anbo|egg>
lamont: if you prefer I can also give you the closest point on the trajectory *including the planned burn*, not sure which is sanest
<egg|anbo|egg>
anyway, that's much easier
<egg|anbo|egg>
I'll take a look
<GH>
[Principia] eggrobin commented on issue #1701: retest this please https://git.io/vN7Cj
<GH>
[Principia] eggrobin commented on issue #1702: retest this please https://git.io/vN7BH
egg|phone|egg has quit [Ping timeout: 186 seconds]
<egg|laptop|egg>
lamont: oh, of course we have our own marshallers, so you'll have to copy those too? :-p
Jesin has quit [Quit: Leaving]
stratochief has quit [Remote host closed the connection]
ferram4 has quit [Read error: -0x1: UNKNOWN ERROR CODE (0001)]
ferram4 has joined #principia
NolanSyKinsley has joined #principia
Jesin has joined #principia
Jesin has quit [Client Quit]
icefire has joined #principia
Jesin has joined #principia
egg|phone|egg has quit [Ping timeout: 182 seconds]
egg|phone|egg has joined #principia
Hypergolic_Skunk has joined #principia
<lamont>
moar coffee
<lamont>
and egg: maybe? sure? i don’t know if i want the finite burn path or not. problem is that if PEG converges on one of those points that isn’t the right destination, so i suspect not...
<lamont>
yeah actually not
<lamont>
that’d definitely be bad to converge on
<egg|laptop|egg>
lamont: okay, so I'll do it on the coast
<egg|laptop|egg>
that works too
<lamont>
yeah if we do any points before it needs to be the target coasting orbit
<egg|laptop|egg>
lamont: do those declarations seem sane? alternatively I guess you could yoink them by reflection but it seems it would be cleaner for you to have an extern declaration
<lamont>
MOAR COFFEE
<lamont>
its still early for me =)
<egg|laptop|egg>
:D
<lamont>
(also AM meetings for actual work)
<egg|laptop|egg>
ow
SilverFox has quit [Ping timeout: 198 seconds]
<GH>
[Principia] eggrobin commented on issue #1702: @aw1621107, it seems that this confuses MSVC:... https://git.io/vN5gC
<GH>
[Principia] eggrobin commented on issue #1702: An alternative would be to use a trailing return type `-> Row<r>`, but this would be inconsistent with our surrounding style. @pleroy, what do you think? https://git.io/vN5go
<GH>
[Principia] eggrobin commented on issue #1701: retest this please (we need to do something about the flakiness induced by races when copying the DLL...) https://git.io/vN5rt
<lamont>
how hard would it be to wire up non-principia-placed maneuver nodes to produce principia orbit predictions?
<egg|laptop|egg>
why?
<awang>
egg|laptop|egg: Ahhhhhhhhhh why :(
<lamont>
it would make for a simple UX that would be a 95% solution that would ease users in Principia, and would enable trajectory planning in mechjeb via a simple interface
<egg|laptop|egg>
lamont: uh I have no idea where you're going here
<egg|laptop|egg>
lamont: we're not going to start mixing the stock manoeuvre node UI (which is strongly bound with the orbit rendering and all that mess) with ours
<lamont>
so users can drop a maneuver node, get an accurate prediction from you based on the impulsive burn solution and hit the execute button in MJ and go
<egg|laptop|egg>
"drop a maneuver node"
<egg|laptop|egg>
what does this mean
<egg|laptop|egg>
you can't add stock maneuver nodes, because those are on the stock orbit to start with
<egg|laptop|egg>
also those won't work if you aren't using the right frame
<lamont>
ah interesting
<egg|laptop|egg>
the fact that you've been working with PEG in ECI all the time doesn't mean everybody does that :-p
<lamont>
so mechjeb’s maneuver planning can drop a node just fine on the vessel.orbit but yeah that’s obviously a thing
<egg|laptop|egg>
yeah, but obviously that's not something you can do in the UI with principia, and also it's going to be conceptually hell with principia in non-ECI frames (and shitty even in ECI if the orbit isn't very Keplerian)
<awang>
egg|laptop|egg: Wait, this is making my head hurt. Why do you have two template<> things on FixedMatrix<>::row()?
<awang>
One for the return type, one for the function?
<egg|laptop|egg>
awang: because it's a member function template of a class template
<egg|laptop|egg>
one for the function, one for the class
<awang>
I... see?
<awang>
I think?
<awang>
Also trying to see what a trailing return type would look like
<egg|laptop|egg>
lamont: I agree that the flight plan need UX improvements, but falling back to stock isn't one; the general plan is having the flight plan as an accurate estimation of the possible, with some indicators so it can be flown by hand, and then having guidance to that expectation, and I'd like to stick to that.
<egg|laptop|egg>
(that's the plan about the plan, I guess)
<awang>
Trailing return type seems to work on clang
<egg|laptop|egg>
yeah but it's inconsistent with our style
<egg|laptop|egg>
we could have gone with trailing return types everywhere, which would be fun
<egg|laptop|egg>
but we didn't
<egg|laptop|egg>
let's stick with what we went with.
<awang>
Fair enough
<awang>
No ML/Haskell-type declarations :(
<egg|laptop|egg>
there are infinitely many weird styles you can go with (use and and or instead of && and ||, use trailing return types, etc.)
<egg|laptop|egg>
we do some weird things (e.g. our semantics for not_null<T*> vs. T&), but consistently
<awang>
True
<awang>
Now that I think about it, I haven't seen any C++ code using "and"/"or" instead of "&&"/"||"
<egg|laptop|egg>
awang: did you know you can use bitand and and for references >_>
<egg|laptop|egg>
lamont: I mean, if you're writing your own styleguide and doing a fairly isolated project like principia, you *could* go with and etc., or with trailing return types; they're just surprising
<lamont>
sure
<egg|laptop|egg>
(I do not recommend constructs such as Args and... args for perfect forwarding though
<egg|laptop|egg>
)
<lamont>
i deeply hate the style of putting `if () {` opening bracket on the next line, because i’m just old school that way, and when i’m writing my own code i’d put it on the same line as the `{` but when i’m writing MJ i try to write it on the next line ‘cuz the rest of the C# and KSP world seems to disagree with me…
<lamont>
* same line as the ‘if’
<egg|laptop|egg>
lamont: yeah, C# usual style seems to be next line
<lamont>
and they’re all wrong =)
<lamont>
but when in rome...
<egg|laptop|egg>
we write our C# close to our C++ style though :-p
<awang>
As long as it's not GNU style, I'm fine with it
<lamont>
i used to like 8 character hard tab stops from *BSD C style
<icefire>
GNU somehow managed to find the most offensive way to style C
<lamont>
now i recognize that hard tabs are the antichrist
<lamont>
but still if 8 characters winds up indenting too much your code is most likely turning into spaghetti pasta nomz
<egg|laptop|egg>
lamont: yeah, the Ada in mockingbirdnest/LEGO uses 8 space tabs
<egg|laptop|egg>
(the pretty-printer did that)
<egg|laptop|egg>
(phl wrote the pretty-printer)
<lamont>
but ruby is 2 and i’ve adapted, C# tends to be 4, etc...
<egg|laptop|egg>
(it was a good pretty-printer on the whole)
<egg|laptop|egg>
lamont: iirc the tabs were 8 spaces, but the indent was lower
<egg|laptop|egg>
it just turned any 8 spaces into a tab
<lamont>
lol that’s horrible
<icefire>
I found some code at work that used 5 space tabs
<lamont>
thing is that my editor switches styles based on the extenion, the project and comments in the header, so whatevs…
<egg|laptop|egg>
the pretty-printer did that for you :-) (and it was pretty grammatically smart, so it completed missing bits of grammar)
<lamont>
now that is entirely civilized
<lamont>
i’ve got an editor macro that lets me do things like that (mostly for
<lamont>
= though)
<egg|laptop|egg>
if you typed type record or something it would turn it into type [identifier] is record [whatever this is called] end record; properly formatted
<egg|laptop|egg>
lamont: okay, so thoughts on the questions of marshalling and extern declarations?
<lamont>
uhm hrm
<egg|laptop|egg>
(and the .dll.config etc.)
<lamont>
well that’s curious
<lamont>
i had a different mental model of your plugin adapter
<lamont>
i thought it was c# glue code, but its c++ glue code
<egg|laptop|egg>
the adapter is C#
<lamont>
oh no it is
<egg|laptop|egg>
the actual interface file is generated by C++
<egg|laptop|egg>
because of course it is :-)
<lamont>
oh
<egg|laptop|egg>
(in fact so is the C++ header)
<lamont>
i’ve got a totally unrelated question about world rotation
<egg|laptop|egg>
ask away :-)
<lamont>
so i need to stash away a velocity vector in KSP in one frame, and then in the next frame take that vector and subtract off a velocity from that frame, and etc and burn it down to zero
<lamont>
except world rotation i think is hosing me
<egg|laptop|egg>
yes it will do that
<lamont>
so i think i need to convert the vector from world to ehrm… the other one...
<egg|laptop|egg>
the unnamed mysterious nonrotating frame
<egg|laptop|egg>
(it has no name that I know of)
<lamont>
okay you gave it a name
<egg|laptop|egg>
well kinda
<lamont>
now i can’t find your comment where you name it
<egg|laptop|egg>
I gave a name to a frame which is 1. a mirror image 2. a translation and probably rotation of that
<egg|laptop|egg>
it's Barycentric
<lamont>
anyway is that just Planetarium.rotation and the inverse of that?
<egg|laptop|egg>
yeah
<egg|laptop|egg>
not sure which one is which
<egg|laptop|egg>
lamont: oh, note that with Principia if you switch SoI that won't be enough
<lamont>
yeah so what i’ve got are deswizzled non-Alice World world velocities
<egg|laptop|egg>
okay, so plain old World
<egg|laptop|egg>
(but actually ECI velocities, for maximum confusion)
<egg|laptop|egg>
yeah, so it's planetarium rotation or its inverse
<lamont>
right, so Planetarium.rotation converts from those World vectors to “Barycentric”
<lamont>
cool
<egg|laptop|egg>
KindaBarycentric really
<lamont>
yeah yeah
<egg|laptop|egg>
AliceBarycentric :-p
<lamont>
KerbalBarycentricWTF probably becuase nothing is simple
<egg|laptop|egg>
RabbitBarycentric
<egg|laptop|egg>
lamont: oh yeah, and Barycentric also is that *up to the rotation that changes the axis of the main body*
<egg|laptop|egg>
(rotate the universe because KSP can't handle tilt, etc.)
<lamont>
ah
<egg|laptop|egg>
(which is why I'm saying don't keep vectors across SoI changes)
<egg|laptop|egg>
Principia will screw them up
<lamont>
oh, SOI, not Sol
<lamont>
that makes sense
<lamont>
yeah if anyone happens to plan a finite burn that crosses a SOI boundary i’m okay with them being SOL as well
<lamont>
this is for handling the last 10 seconds of a finite burn only
<awang>
KSP needs more strong types for frames
<lamont>
yeah actually i was thinking of creating a type for this which if you cast it to Vector3d would apply Barycentric->World and vice versa
<egg|laptop|egg>
lamont: okay so about the API, I'll be nice (contrary to our internal functions) and return an error code if preconditions are not met, rather than crash :-p
<lamont>
yes
<lamont>
plz
<egg|laptop|egg>
(it's probably a bad idea to crash if you e.g. look for a manoeuvre that doesn't exist)
<egg|laptop|egg>
with an error message as an out parameter
<lamont>
i was expecting to call something like Principia.GetMeMyStuff() via reflection and not have to worry about marshalling/unmarshalling…
<egg|laptop|egg>
hmm
<egg|laptop|egg>
okay, could do that
<egg|laptop|egg>
lamont: can you reflect static methods? I've never done much reflections
<lamont>
that’s more work for you less work for me, but it also places all that responsibility in your court, so if you want to make major plumbing overhauls i won’t care?
<egg|laptop|egg>
s/tions/tion
<Qboid>
egg|laptop|egg meant to say: lamont: can you reflect static methods? I've never done much reflection
<lamont>
hrm
<lamont>
i would think so?
<egg|laptop|egg>
okay, so I'll have a static class principia.ksp_plugin_adapter.External or something
<egg|laptop|egg>
lamont: so now the question is whether you could just call my P/Invoke static method
<egg|laptop|egg>
awang: oh nice
<awang>
:o Oh no
<egg|laptop|egg>
lamont: so then you can, I don't need to write wrappers, everyon's happy?
<lamont>
heh i dunno much about p/invoke at all
<egg|laptop|egg>
awang's last link
<egg|laptop|egg>
seems you can get that method
<lamont>
okay that looks like it maps to ffi in ruby in my head, which looks fine (don’t ask)
<lamont>
will i get Vector3d’s out of that?
Jesin has quit [Ping timeout: 186 seconds]
<egg|laptop|egg>
lamont: out of what?
<egg|laptop|egg>
our functions? nah, you'll get QPs and XYZs
<awang>
idk if it works, since I haven't actually done it myself
<lamont>
as C# objects that i can yank Vector3d’s out of?
<lamont>
oh XYZs
<egg|laptop|egg>
they are C# structs
<egg|laptop|egg>
XYZ is convertible to Vector3d
<egg|laptop|egg>
QP has a q and a p member
<egg|laptop|egg>
both XYZ
<lamont>
just via a cast?
<egg|laptop|egg>
yeah, explicit I think
<lamont>
`(Vector3d) myqp.q`
<lamont>
that’s fine
<egg|laptop|egg>
not sure how that works out if you have it by reflection though
<egg|laptop|egg>
since you have a QP as out parameter, you need to declare a QP somehow?
<lamont>
“If you are using a version of Invoke that requires the type parameters be passed, then be sure to use the Type.MakeByRefType instance method for the output parameter. (Not relevant here, but was in my case!)”
<egg|laptop|egg>
okay so you'll reflect QP and do that magic
<lamont>
ah just for refs
<lamont>
i’m reasonably certain there’s a way to do that slickly
<lamont>
at worst, use reflection to grab the QP class and make one of those dynamically
<egg|laptop|egg>
I mean it might be easier to just copy over the definition of QP, the dll.config, and the p/invoke declarations of the external functitons
<lamont>
Type.GetType(“QP”) will definitely work. it isn’t entirely clear to me how typeof(QP).MakeByRefType() compiles without linking to Principia, but maybe there’s some late-binding type magic there.
egg|laptop|egg has quit [Ping timeout: 180 seconds]
<egg|anbo|egg>
um my laptop somehow doesn't want to reconnect
egg|laptop|egg has joined #principia
<egg|anbo|egg>
ah
egg|laptop|egg has quit [Ping timeout: 180 seconds]
egg|laptop|egg has joined #principia
UmbralRaptor is now known as ElectrodynamicRaptor
<lamont>
egg when i click “show on navball” where is the node attached?
<lamont>
like
<lamont>
when i’m half an orbit around too early and i click on that...
<lamont>
is the maneuver node on the patchy conic from where i am now?
<egg|laptop|egg>
it's at the right time, because we use the node to time things
<egg|laptop|egg>
it may be in completely the wrong place as a result
<egg|laptop|egg>
(we just use the node to give you a navball vector and (another) countdown
<egg|laptop|egg>
)
<lamont>
yeah but the node is just on the keplerian orbit?
<lamont>
so as i coast to the maneuver node, that vessel.orbit gets updated by principia right?
<egg|laptop|egg>
yes?
<egg|laptop|egg>
lamont: this is all just a hack to get a vector on the navball
<egg|laptop|egg>
please don't depend on that node
<lamont>
yeah but for today its what i’ve got and it means i get more accuracy if i don’t pull off the subsequent orbit way in advance, and it helps me get my mind around the issues you were talking about earlier with stock maneuver nodes
<lamont>
so its all edumucational
<lamont>
i’m walking down the road of understanding why its all lies...
<egg|laptop|egg>
:D
<egg|laptop|egg>
everything KSP says is a lie :D
<egg|laptop|egg>
the frames are big lies
<egg|laptop|egg>
lamont: I'm working on your API right now, so I'll probably have it (no backtracking) soon
<lamont>
cool
* egg|laptop|egg
pets a cat
stratochief has joined #principia
icefire has quit [Read error: Connection reset by peer]
<egg|laptop|egg>
(normally we crash on most of those, but you probably won't like that :-p)
egg|phone|egg has quit [Ping timeout: 182 seconds]
egg|phone|egg has joined #principia
icefire has joined #principia
egg|cell|egg has joined #principia
egg|phone|egg has quit [Read error: Connection reset by peer]
Jesin has quit [Quit: Leaving]
<GH>
[Principia] aw1621107 commented on issue #1702: Should I close this PR then? https://git.io/vNdJ8
<GH>
[Principia] eggrobin commented on issue #1702: No, add `TEMPLATE` back to macros.hpp and use it here; we still want things to build on Macintosh and Linux. https://git.io/vNdUS
Hypergolic_Skunk has quit [Quit: Connection closed for inactivity]