• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Fillipuster

  • Rank
    Curious George

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. How would I go about getting the navball's current orientation/rotation for use in an external visualization of said ball? Would I have to get the vessel orientation based on the navball's current reference frame?
  2. Ah, amazing! Really looking forward to the 040 update, and the things we will be able to do with serial connections, web sockets and events. Great work Jungle Worm! Let me know if I can do anything to help.
  3. Well... the inverse thing was not the problem, but I did figure it out. For some reason, I had to use a different ordering of the quaternion values. Because I didn't know anything about the math of quaternions, I brute-forced it, testing all different combinations using a little system I made. For me, it worked out to be no "x, y, z, w", but instead, "z, y, x, w". I then went on to build a Linux application in Unity, only to be hit hard by the fact that the Raspberry Pi 3 doesn't run a x86 processor, and thus, cannot run a Unity application. In essence... most of my work is wasted. I'm pondering what to do next now. I think the easiest solution would be to write the navball display in OpenGL instead (which does run on a rpi3 - and should run faster). But that provides the challenge of learning not only OpenGL, but also C++ Learned a lot... will probably learn a s*** ton more before this is working Again, thanks for all the help djungleorm! (you aren't a Dane by any chance? - your name pretty much translates to Jungle Worm in Danish)
  4. Wow... I feel kind of stupid now. I didn't even notice that the Rotation tuple had 4 elements, which would probably have lead me to believe it was a quaternion - great idea with the ticket! Simply setting the rotation quaternion to the tranform of the sphere in unity gets rid of the "flipping" (gimbal-lock I'm guessing), but now I've run in to (yet) another problem... I have my main unity camera pointing at the sphere I am rotating using the kRPC data, but no matter what side I look at the sphere from, or what way I rotate the camera, I cannot seem to get the same rotational results. If I place it in one spot, the heading matches. If I place it in another, the roll matches. I feel like the solution is right in front of me, but no matter the perspective (get it? :P) I cannot seem to crack it. Any ideas?
  5. Hmm.... This is interesting. I've now tried with different reference frames, without much luck. I did however figure out how to use the Direction vector to rotate the navball instead of the pitch, heading and roll angles. This, however, provides a different "flipping" problem, as seen in this video: This also doesn't include the roll of the vessel, which I presume is stored in the Rotation tuple ( I'm lost as to how to fix this flipping and/or implement the roll. Progress at least, if not much.
  6. I never even considered that pitch and roll don't range between -360 and 360, but with your addition, I get the exact same behavior. This is my code: void UpdateNavball() { Flight flight = vessel.Flight(vessel.SurfaceReferenceFrame); float roll = flight.Roll; float pitch = flight.Pitch; if (roll < 0) { roll += 360; } if(pitch < 0) { pitch += 360; } Quaternion newRotation = Quaternion.Euler(-roll, flight.Heading, -pitch); transform.rotation = newRotation; }
  7. So I made it (not really) work with Heading, Pitch & Roll. But I cannot for the life of me figure out why I get these strange "flips" when I reach the top and bottom of the hemispheres... Here's a short video showing it off. My guess is that it has something to do with my usage of euler angles and the raw heading, pitch and yaw data. I should probably be using Flight.Direction and Quaternions but that's beyond my understanding at the moment. Any input?
  8. I see, thanks for the reply There doesn't seem to be a way to specify the reference frame when getting the Direction Tuple I assumed the direction would just use the reference frame that the navball in game uses (matching the navball). I suppose I could use the pitch, roll and heading maybe?
  9. Having two well knowing guys on this thread (djungelorm & artwhaley), I was wondering if you'd have to input as to how to properly rotate my navball (Unity). I've set up a sphere and got the kRPC connection going, but I'm lost as to what exactly to change given the direction information from kRPC. kRPC gives a vessel direction as a Tuple with three doubles seemingly ranging from -1 to 1. ( Simply multiplying the output from the direction Tuple and feeding it as euler angles (multiplied by 360) in to the quaternion transform of my sphere doesn't seem to do the trick (as it clearly doesn't match KSP's navball). What am I getting wrong here?
  10. Wow! Thank you so much artwhaley! I'm sure this will give me a better picture of how I'd make the map view. However, I doubt it'll be an easy feat for me, especially as I don't even really know how to get started on the navball display Oh well... guess I should start reading up on the maths of spheres and rotation... .--.
  11. Interesting... I'll have to consider using JAT for the map-view clone. Somehow I do feel that it would be easier to do in Unity. I'm more familiar with Unity and C#. I just have to crack the code of drawing elliptical lines using the orbital data from kRPC. No easy task ...
  12. I feel you man. Same deal for my controller project. Another sidenote: Being the creator of kRPC; would you happen to know of anyone who has made standalone map-views or navball displays using kRPC? I've been looking for both for ages, but no one seem to have made something like it. I'd preferably not have to make a map view and navball view from scratch in Unity Alas, I'm just using you as a hotline now xD sorry... I don't know if you've ever done serial stuff with Arduino, but it's quite simple. A system like it directly integrated in to kRPC would significantly up the game-changeification factor of kRPC!
  13. I see. Although not tested fully yet, it seems to work by using Unity's experimental .NET4.6 script runtime environment. Sidenote: you should make a serial communication API to talk to Arduinos directly via kRPC (or other serial connections), and an Arduino sketch to go along with it :3
  14. Ah, nice! Thanks man. Now that I see you're online, may I just compliment you on kRPC. It's a complete game-changer for simpit/physical control panel makers! Without kRPC, me and my uncle wouldn't be able to make the board we are making right now. Thank you!
  15. Thanks for the suggestion @TheRagingIrishman, I worked around it by saving a reference to the active vessel instead of the SpaceCenter. Now, I've run in to another conundrum. I'm wanting to reference the latest 3.9 kRPC dll in a Unity project, but I'm having trouble. Supposedly, it's a straight forward procedure to add external dlls, you simply drag-n-drop them. The problem arises with the fact that kRPC 3.9 uses .NET 4, which is not supported by Unity. I'd love if there was a way to work around this, hence me writing a reply to this thread. Can you somehow "downgrade" to .NET3.5 (which Unity supports)? Can you somehow make Unity eat the kRPC3.9 even though it's .NET4? Any input is much appreciated I figured it out myself. In case anyone is interested in adding kRPC to a Unity project, do the following: 1. Get the kRPC client dll from here: 2. Unpack and place the dll file in the Unity project. 3. Change the build settings by going to Files->Build Settings->Player Settings and changing Scripting Runtime Version to .NET4.x. 4. Simply use kRPC in Unity scripts like you would any other C# project. -FP