c4ooo

Members
  • Content Count

    88
  • Joined

  • Last visited

Community Reputation

29 Excellent

4 Followers

About c4ooo

  • Rank
    Rocketry Enthusiast

Profile Information

  • Location Night side of Kerbol

Recent Profile Visitors

1,439 profile views
  1. @Benjamin Kerman This is what i get when i tried rolling the vessel: (IDK why but Vector3d.ToString() makes it a rainbow...) https://i.imgur.com/fZkVZuo.png Next i tried pitching the vessel down (harder to do accurately then rolling) and got this: https://i.imgur.com/vOJGRm6.png
  2. How do i orient a craft's angularVelocity vector to extract the ΔPitch, ΔRoll, ΔHeading? Mechjeb does this to orient the attitude vector to get the pitch roll and heading: Vector3d CoM, north, up; Quaternion rotationSurface; CoM = Vessel.CoM; up = (CoM - Vessel.mainBody.position).normalized; north = Vector3d.Exclude(up, (Vessel.mainBody.position + Vessel.mainBody.transform.up * (float)Vessel.mainBody.Radius) - CoM).normalized; rotationSurface = Quaternion.LookRotation(north, up); Vector3d attitude = Quaternion.Inverse(Quaternion.Euler(90, 0, 0) * Quaternion.Inverse(Vessel.GetTransform().rotation) * rotationSurface).eulerAngles; However doing something similar but replacing Vessel.GetTransform().rotation with Vessel.angularVelocity results in what seems like meaningless numbers.
  3. 'Angle x 50' would be better do to ease of use I suppose. (The current ratio is Angle x ~91.0222, which isn't an integer as you can see :V ). Although if you would be fine with negative headings (range of -180 to 180), then you can make the ratio 'Angle x 100', and have a resolution of 0.01 degrees. As for the targeting planets issue: since the 'set navball mode' code also uses the "TargetExcists()" function, I assume it is not possible to set the navball to "Target" speed mode or set SAS to "target" mode if you are targeting a planet, not a vessel.
  4. This was originally part of this thread but posting it in this subforum is more appropriate. YARK Multifunctional Display is a program that uses the YARK plugin to fetch flight through a TCP connection and display it on virtual instruments situated in widgets. This could be useful if you want to build a simpit with simulated displays or just have extra monitor space. Below is a screenshot of an earlier build: Instruments are situated in "Widget" windows, which can be configured through a console, or by mouse interaction. List of Widgets: NavBall (navball) Attitude Indicator (ati-in) Air Map (airmap) Soyuz NavBall (soyuznavball) Configuring YARK-MFD config.txt is read on startup and tells YARK-MFD the desired window size and connection IP. It is in the following format: IP <IP> <port> winsize <width> <height> start.txt is read next, and contains a list of console commands that configure the initial layout of the widget windows and serves to save the layout between uses. Here is a list of accepted console commands: savestate //saves the state of the windows to the start.txt open <widget name> <locationX> <locationY> <sizeX> <sizeY> //opens the requisted widget at the given location. close <window title> //closes the widget with that window title. (generly window title = widget name) resize <window title> <locationX> <locationY> <sizeX> <sizeY> //sets window to a certain size and location Of course, windows can also be moved resize using mouse drag and drop. (Although there is no way to open new windows without the console yet). The console is opened automaticly so "resize" or "close" should be used to move/close it. (Dont do "open console") NOTE THAT Everything is still very alpha, I am still working on the overall system, adding more widgets, and changing how they render Download / Source YARK-MFD requires at least openGL 3.3, and is currently only compiled for 64 bit windows. YARK-MFD can be downloaded here, and the YARK plugin (required) here. Source code for both YARK and YARK-MFD is here. Compiling YARK-MFD requires SDL2, glm, freetype and glew (see /Lib folder).
  5. @zitronen I sent a pull request, but unfortunately I could not test the code becouse I don't have any arduinos at hand. Should work fine though. I made the 16-bit angles be stored in the range of [-360,360), so that there is no need for negative headings (headings is in the range (0,360] while pitch is in the range (-90,90)). Not sure if this is the best option long term. Edit: I just came to the realization that the Normal Vector's heading (likewise to Radial Vectors pitch and heading) can be calculated easily from the prograde Vector, so there's no need to send it :V That is unless I got something confused again.
  6. I have taken a look and I am not sure how the code is supposed to be used. As far as I see, MAS doesn't come with any camera models itself, so is the code meant to use/control cameras from mods like KURS?
  7. @zitronen and others, is there any demand for making the plugin send the Pitch+Heading of the navball vectors? (Prograde, Target, Maneuver and Normal). I recently worked the code out for how to do that (because I am making a TCP-socket based version of this plugin), and would be happy to send a pull request. However, the amount of data needed to be sent is quite large, adding up to a total of 7 floats (the Normal vector always has a pitch of zero, so need to send that), or 28 bytes. This size could be cut down by replacing floats with something smaller and less accurate, such as a 2-byte fixed point representation, but that's still 14 bytes. Edit: Well seems like @naru1305 does :V (I didn't bother reading the thread before posting) Edit 2: anyways here's the code to calculate pitch+heading of the vectors by the way:
  8. @DMagic well, for the target vectors I suppose I could just subtract the target position from the vessel position. I just don't know how to "orient" this resulting vector so that I can sensibly draw it on my external navball. Edit: Well, it took me all morning but I figured out how to calculate the Pitch and Heading (relative to the surface/navball) of the prograde vector given the vessel's velocity vector (which is in world space). Once I got it though, it seemed easier then I expected. In the code bellow, AV is the active vessel:
  9. Is there any "official" way on how to get the different vectors from the navball (Pro/Retrograde, radialIn/Out, Anti/Normal etc)? I have found some old forum posts (one and two) but the github links that are there are dead. I have also found this code on github, which seems to get the NavBall class through GameObject.Find(""); but when I try the same method, I get a null object. Do I have to manually calculate the vectors, or is there a way to somehow read them from somewhere? Edit: I want the navball vectors because I want to render a navball in a separate desktop application. I already have the navball pitch/yaw/roll rotation correctly rendered, now I just need the vectors.
  10. c4ooo

    Yet Another Remote Kontroller

    OK so, I pushed the most recent code to github. (Well actually, I haven't pushed most of the Client because it uses a large SDL/openGL wrapper I wrote, and I think I will make that a separate repo.<sidetrack> All my c++ openGL projects use this wrapper in different stages of its development, and because I was always simply copy and pasting the wrapper from the previous project to the next, the whole thing is a huge mess. <sidetrack>) https://github.com/c4ooo/YARK/tree/master/YARK_CLIENT/YARK_CLIENT/Client contains a very simple c++ TCP client to receive data from the plugin. If you wanted to use that code, you would have to write a main method, #including Client.h, and in which you would create a new Client() object , passing the appropriate params to the constructor. Once Client.state is equal to TCPCLIENT_CONNECTED, you can start reading the appropriate data from Client.status (the "static" data packet) and Client.dataIn (the "dynamic" data packet) and writing to Client.CP (the control packet). To actually send the control packet you need to call Client.SendControls(). The structs are defined in: https://github.com/c4ooo/YARK/blob/master/YARK_CLIENT/YARK_CLIENT/Client/Struts.h Yea, I know everything is messy and confusing right now, but I will be working to clean it up as well as writing a proper documentation and stuff. Ohh and, the plugin's server is started on port 9999, I will make this configurable ASAP. Edit: Just a screenshot:
  11. c4ooo

    Yet Another Remote Kontroller

    I will try to have to have more or less finalized documentation by the end of this week. (Tomorrow I plan on fixing how the desktop-client renders the navball) Right now, the current setup acts this way: Once the client connects, it will automatically start receiving packets from the server. Each packet starts with a 3 byte header. The first two bytes are always 0xDEAD (lame, I know ), and the third byte identifies what type of packet it is. The first type (0x01) is a "Status Packet", which notifies the client of whether there is a vessel currently in flight, and what name of that vessel is, and other "static" data about the vessel. It gets sent when the client first connects, when the flight starts/ends, or when the vessel is switched. The second type of packet (0x02) is the "Vessel Data Packet" which gets sent every frame, as long as there is a vessel in flight, and holds "dynamic" data about the vessel such as altitude, attitude, fuel, etc.
  12. YARK plugin can be be downloaded here. It is compiled for KSP 1.2.2; Yet Another Remote Kontroller (YARK) YARK is a plugin that allows for the remote control and flight data monitoring of vessels through a TCP connection. YARK is heavily based on, and wouldn't be possible without, @zitronen's KSPSerialIO plugin. (In fact, YARK is essentially KSPSerialIO with the serial code swapped for socket stuff). YARK isn't meant to be as extensive as kRPC, but it does have some features over KSPSIO, such as the sending of navball vectors (prograde, target, maneuver, etc). YARK protocol: Communication with YARK is meant to be simple. Once a client connects, the plugin immediately begins sending two types of data packets. The first type, StatusPacket, is sent every time KSP enters/leaves flight, or when the vessel is switched. It contains more "static" data, such as whether or not there is a vessel in flight, and that vessel's name. The second type, VesselPacket, is sent every frame (this is configurable), as long as there is a vessel in flight. It contains more "dynamic" data about the vessel such as attitude, fuel levels, etc. Each packet sent from the server to the client is prefaced with a 2-byte header. The first bytes is always 0xC4. The Second byte identifies the type of packet that fallows, with 0x01 being a StatusPacket and 0x02 being a VesselPacket. After the 3 byte header comes the actual packet. To control the vessel, the client must send a Control packet to the server. The control packet's first and second bytes should always be 0xDE and 0xAD, respectively. The layout of all packets, and documentation of their members, can be found in Structs.h Excample c++ client: This contains a simple c++ client for YARK. ExcampleClient.cpp is a simple script that uses the client, checking for abort conditions and executing a two-step abort sequence. Configuring YARK: Like KSPSIO, YARK's settings are in the PluginData folder. The settings are identical to KSPSIO, except for two unique fields. The "TCPPort" field is the port the plugin opens a server on (defaults to 9999), and "UpdatesPerSecond" is the target number number of VesselPackets the server will attempt to send per second. If left zero, the server will simply send a VesselPacket every frame. (UpdatesPerSecond defaults to 0/every-frame) Compiling YARK: YARK can be compiled like any other KSP plugin from the source code found here. Just point MSVS to the required unity reference DLLs, and make sure you compile for .NET 3.5. Multi-Functional Display (MFD) (Main Thread) The YARK-MFD is a multifunctional display written in c++ with openGL that uses YARK to fetch and display flight data. Read the main thread for more info. Screenshot:
  13. Thanks, that seemed to have worked Should i leave the Dont_Destroy boolean true or false?
  14. I dont quite understand how to write an addon that gets created once and then persists through the entire game. I have tried "[KSPAddon(KSPAddon.Startup.MainMenu, true)]", which, as far as i understand should be started once the main menu loads and never be destroyed. However it gets destroyed once the scene changes (eg i load a save).