Pablo49

I get this, too. Also the backside of panels are not reflective. Blue sides of smaller panels and the windows/helmets work, etc.

So I have been working on a mission control-esque display using kRPC. Shows the vessels pitch, yaw and overall displacement relative to the velocity or prograde vector. Also can rotate the vector to match in game, give or take (some math is definitely a bit broken) It's coming along quite nicely so far. kRPC has proven to be easy to code with.

And here comes Pablo with an even older one. I am from Orbiter, been playing since Harv posted a link to KSP on O-F. So I have been playing since the first day of public release. I remember us trying to set altitude records in the first couple days. Pretty sure I held the record for awhile. The game got pretty angry when I was escaping kerbins SOI, very jittery.

Glad it will be useful. Your documentation has been coming along nicely, which has been super helpful.

Awesome, that did it. Thanks a bunch for the help! Here is my code snippet for finding pitch and yaw relative to the vessels velocity vector, in case anyone else wants this down the road. Save them the headache of flipping triangles and axes like I did all day. import krpc, math conn = krpc.connect(name='Pitch/Yaw') vessel = conn.space_center.active_vessel while True: # x north # y normal to surface # z forward direction = vessel.direction(vessel.orbit.body.reference_frame) velocity = vessel.velocity(vessel.orbit.body.reference_frame) # x yaw # y pitch # z roll # direction unit vector, with corrected axes x0 = direction[1] y0 = direction[0] z0 = direction[2] # calculate unit vector of velocity magnitude = math.sqrt( velocity[0]**2 + velocity[1]**2 + velocity[2]**2 ) v = (velocity[0]/ magnitude, velocity[1]/ magnitude, velocity[2]/ magnitude) # velocity unit vector, with corrected axes x1 = v[1] y1 = v[0] z1 = v[2] # calculate pitch pitch = math.acos((x0*x1 + y0*y1 ) / (math.sqrt(x0**2 + y0**2) * math.sqrt(x1**2 + y1 **2))) * (180 / math.pi) # pitch is positive if velocity is below attitude, negative if above (this is arbitrary) if x0 > x1: pitch = -pitch # calculate yaw yaw = math.acos((y0*y1 + z0*z1 ) / (math.sqrt(y0**2 + z0**2) * math.sqrt(y1**2 + z1 **2))) * (180 / math.pi) # yaw is positive if velocity is left of attitude, negative if right (this is arbitrary) if y0 < y1: yaw = -yaw print "pitch: {:+07.2f} yaw: {:+07.2f}".format(pitch, yaw) Spacial reasoning is the hardest thing I encountered working on this so far, understanding which axis was the one I wanted to work with, etc, and especially knowing which reference frame I required.

Yeah, the numbers do work out when when in a complete orbit. I also want to be able to calculate my attitude against prograde during ascent and descent, and I get numbers that don't match when in the atmosphere/suborbital: prograde: (0.6492723060508789, -0.00322239392899013, 0.7605492020722537) direction: (0.8629220494448264, -0.004159275196002663, 0.5053202365175846) I also tried that with surface reference frame, and similar results. I thought flight().velocity might be a solution for this suborbital problem, but all I can ever get that method to return is (0.0, 0.0, 0.0) What I am trying to do is have a 2D display of the vessel's attitude, one relative to the surface (where flight().pitch, .heading etc will work out-of-the-box) and then another that is relative to the vessels trajectory, so you can see a capsules orientation during reentry, for example.

Also, question. I think I am misunderstanding the unit vectors from the reference frames. I am trying to find the angle of pitch and yaw of a vessel from it's prograde vector. I am using vessel.direction(vessel.orbital_reference_frame) and vessel.flight(vessel.orbital_reference_frame).prograde. If a vessel is pointing prograde, I would expect the values of vessel.direction and flight.prograde to be nearly identical if in the same reference frame, but they are not.

As a heads up, it looks like you just moved where you host your docs, and the generation for the docs gives incorrect method names. Like the reference frames are all CamelCase, like vessel.SurfaceReferenceFrame, but in actuality they are snake_case vessel.surface_reference_frame. Poking at your code it looks like you have a method to change from CamelCase to snake_case, so your docs generator is pulling out unusable method names.

Did you base this off Mismas?

Wikis are pretty good for this though. Mod devs can go and add their new mod to the wiki right away. More than one person has access to the list to update it (what if the maintainer goes on vacation, or computer breaks, etc?) I think a page on the KSP wiki is the best way to keep a mod list neat and always up to date, while in this early stage of KSP.

I know it's early for a full blown repo. (hence my saying 'in the future') My point is different. Like, in this thread for example, you are keeping the list up to date, but your post isn't the OP, which is really should be. KSP pulls in a lot of views already, and like most game communities there are a lot of people who don't take the time to read a thread or search, and a random lurker could easily miss your list since it isn't the first post. And, what if for whatever reason you stopped updating your post, either permanently, or even for a short while? (Not to say you would, but for example) Then someone else starts a new thread, or a new post in this thread. Maybe a better solution is a wiki article that lists the mods, then anyone can edit the list at anytime, and it never gets 'locked out'? Then have a locked and stickied thread in this forum with a link to that page, for those who don't check the wiki.

It would seem you misunderstood me then.

AS I said when commenting on Orky' Bits. I think KSP lends itself to some steam-punk theming. I've been planning on doing it myself sometime soon. But these are already awesome.

Hopefully a neater and more proper repository will exist for KSP in the future. (think AVSIM or Orbithangar) I'm not particularly keen on trusting the OP of a thread, or the maintainer of a site to update their pages frequently (since people lose interest sometimes, etc).

Retro rockets are greatly appreicated. also, thanks for keeping the version number in the thread title. Nice being able to check for updates on a glance.

Looks steam-punky. Which goes nicely with the slapping random parts together feel of KSP. I approve.