c4ooo

@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.

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?

@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:

@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:

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.

EDIT: Irrelevant

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. Edit: not relevant

YARK plugin can be be downloaded here. Yet Another Remote Kontroller (YARK) YARK is a plugin that allows for the remote control and flight data monitoring of vessels through a TCP socket connection. YARK could be used to build "remote" control panels powered by Raspberry PIs or other linux based computers with WIFI, or for writing remote control scripts. YARK isn't meant to be as extensive as kRPC, being tailored more for people making control panel rather then remote control scripts. YARK is heavily based on, and wouldn't be possible without, @zitronen's KSPSerialIO plugin. Some of YARK's features: Craft orientation (Pitch, Roll, Heading) "11th" SAS mode, allowing you to point the vessel at an arbitrary vector (Experimental) AxisInput (Controlling Throttle/Pitch/Roll/Yaw/TXYZ) Control and monitoring of Action Group, SAS, RCS, Brakes etc. Navball vectors (Prograde, Target, Maneuver) Alt, Velocity, etc Orbital Information Fuel Levels Getting and settings timewarp mode, SAS and speed modes, and other miscellaneous stuff. Using YARK I have provided a set of C++ and Java bindings for using YARK, rather then trying to explain the protocol. Along with the bindings, I have also provided a sample script which should show how to use the bindings. The script simply checks if the rocket is falling and executes a simple abort procedure. The bindings might have slight differences between the Java and C++ versions, but should function the same. Client documentation: Configuring YARK: YARK has two settings found in the PluginData folder. The "TCPPort" field configures the port on which YARK hosts the server (defaults to 9999), and "UpdatesPerSecond" is the number of updates the server will attempt to send per second. If left zero, the server will simply send an update 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:

Thanks, that seemed to have worked Should i leave the Dont_Destroy boolean true or false?

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).

May I ask how this mod is able to display the camera feed inside the IVA cockpit? I would like to write a mod (or modify the existing KURS or Hullcam mods) to broadcast the camera feed to a second monitor (that I want to integrate into a simpit), without actually rendering anything to the main KSP window. I assume this mod somehow renders the camera feed to a texture, and then renders the texture onto the IVA control panel? I imagine I would need to do something similar except that instead of rendering the texture, I would have to read the texture's data back (and then send it using away websockets of course). Any advice would be helpful as, athough I am familiar with programming as a whole, I am not familiar with Unity or KSP modding

I too have been thinking of using a second monitor for viewing hullcam/ docking port cam footage. However, I don't know what the best way to do this is. The best method I can think of is simply writing a program to screencapture the KSP window, and then display the camera footage to the second monitor. The problem is that for this to work, the camera's rendered image would still have to take up screen space on the main monitor, which would make the main monitor unusable for something like mission control or as something to simply display the view from the pod window. Any advice?

Considering that sooner or later I want to make a simpit ( ) my dream setup would be something like this: 1) main monitor: IVA view, but "out of the window" (so no HUD) 2) small monitor that is built into the simpit: switchable between displaying a navball, "guidance computer" terminal or video feed from a camera mod (KURS or HullCam) 3) projector: projects the "mission control", ei the maneuver planner and such. I really have no solid plan how to implement this, but my most plausible idea goes something like this: 1)somehow write a mod that places the IVA camera outside the cockpit (maybe something like this already exists?) 2)write simple program in java or c++ to screancapture the video from the in-game KURS camera window, and basically copy it a new OS window, which will be placed in the small simpit monitor (i don't know if Windows 10 allows two full screen applications, if not both the KSP and my program window will have to run in maximized borderless mode). This will allow the simpit video to have a camera feed from the KURS mod. And well here my idea gets stuck because well i don't know how to get the map view separate from the IVA view Another problem is that technicaly to screen capture the KURS in game window, it has to be rendered onscreen, and thus will obstruct what is supposed to be the view out of the window. Another thing is that even though I know how to program, i have very little knowledge of how the mod API or unity works

Nowadays, I mostly build only planes in KSP, and I like to fly them from the in-cockpit view. For the longest time I have noticed that, when using Mk2 and Mk3 cockpits, the view from the windows just seems kinda odd, as if the terrain was somehow scaled during rendering. Because of this I have a hard time judging distances, lining up turns, and landing crafts that use Mk2 and Mk3 cockpits when flying them from the in-cockpit view. However the Mk1 in-cockpit view just seems a lot more "normal", and I have a much better time flying planes that use it. I was just wondering, is this a me issue or have other people noticed this? Is this issue somehow caused by FOV, and could this be solved with a very-wide monitor setup? And yea I know that you can zoom in/out while using the in-cockpit view, but no zoom level seems to make the Mk2/Mk3 view look "normal".

That's unfortunate. I guess I could write a program to screencapture KSP and read the correct pixels, but that is not a clean solution considering the camera output is still going to take up the game window. I am not above trying to programming this sort of functionality when I get the time, but unfortunately I really don't understand how this mod works considering that the most I have ever contributed to a KSP plugin is around 20 lines of code and that I have no Unity experience

Something similar has probably been asked before, but would it be possible to make this mod render to an offscreen buffer whose contents can then be broadcast instead of drawing it onscreen?

Well its been a while but... There is (was) a STEM club that got funding from a government grant. Anyways what actually happened is that I completely lost motivation for my project, even though I had half the parts already bought. Now that its summer and I have plenty of free time that was previously occupied by school stuff, I want to resume building my panel. The problem is that now that school ended, I don't have access to a CNC machine anymore and cutting holes and rectangles with a hand drill is way to imprecise/inaccurate (As for me saying I might try to build a navball, I built a z80 computer instead :V That being said, the z80 would be a cool chip to use for a guidance computer, and I have previously considered using a TI-8x calculator (they use z80 CPUs) as a guidance computer.)

If this is what you mean, having more then one body's gravity pull on your ship should not be computationally expensive. I am assuming that each frame, it calculates a normal vector from your ship's center to the center of the planet, multiplies it by a scalar representing the amount of force, and uses this vector as the "gravity" force for all parts in the ship. It should not be computationally expensive to calculate such a vector for all planets in the system, and then add them together.

What about removing the microphone? Quite frankly if i was a hacker, looking at someone's face as they use the ipad would be very boring. Sound would be much more interesting/useful.

They are 32 bit floats; 8 bits store an exponent and 24 bits store the number, giving roughly 7 digits of precision. Note that there could be 7 digits to the left of decimal point and zero to the left, or 2 to the left and 5 to the right. (This is determined by the exponent.) But since degrees can't be higher then 360, this means that there should only be 3 digits to the left of the decimal, thus leaving 4 on the right side. However I don't see why you would need more then 1 digit to the right of the decimal point unless you where running a space program in real life Side note: since the arduinos don't have FPUs, would it be possible to use fixed point instead of floating point? This would increase speed, and could decrees memory usage.

Toggle switches would work too. Just use an binary-> 5v analog converter, and map the arduino's analog input onto the range [0,255]. Then, to test if switch n is on, check to see if bit n of the input is set one.

That could theoretically work if there is enough friction between the rollers and the ball, but it would probably be more complex a design as posted above, and calibration would be very hard.

@Pvt. KASA If you use thin cables, and make sure the pitch never rotates more than 360*, then i think it should be possible. Anyways, i may attempt a navball as a school project (i get funding for parts!), and will report how well it works Also, "tangle" is correct

I don't think slip rings are needed though. if your design is something like the pic, where your two ball hemispheres are mounted to a *yaw* motor, which is glued to a central plate, which is mounted on the *pitch* motor, you could just run the wires from the *yaw* motor to the outside through the central disk and a hallow axis that would mount the central disk to the *pitch* motor? Sorry if I confused you (Central disk is the rectangle inside the circle)

I... let this load while i went out to get some lunch. When i came back 45 minuts later this was all i saw: