c4ooo

Nope its my own software

No there's not, but it should be easy to modify the code to do so.

Does anyone know a good method of painting wooden boards (MDF) so that they look nice? Years ago I tried matte black spray paint, but the finish was rough and the paint rubbed off onto skin.

As some of you know, I have wonted to build a control panel for a long while, and have even write my own KSP plugin + openGL application for it. Recently I have started building it and have finished the frame and cut out the wooden panels to fit on the frame. The panels aren't really "mounted" in the sense that i will still have to take them off to make cutouts for the switches, as well as paint them. The two big holes in the middle are for a laptop and a monitor. The laptop will serve as the multifunctional display / guidance computer while the monitor will display the video output from the PC running KSP, serving as the cockpit window.

Is there a mod to make cockpits/ command modules transparent while IVAing inside them? For the simpit I am building, I would like to use a desktop monitor as a window view, and would like the window to "work" from any IVA camera angle, without having to line up the view with the cockpit's/command module's actual window.

Do you think something like this could be used for a stall alarm? I think real planes use pressure sensors in special areas on the wing.

It should be in the same folder as the game's exe file, or in a sub folder titled "logs" iirc

IIRC I didn't like the idea of negative headings. Otherwise, the range -180 to 180 could have been used

Yep pretty much, although of course if you pull up sharply, VData.ProgradePitch will lag behind VData.Pitch (changing your pitch doesn't immediately change vertical velocity). As for the NormalHeading value, this should be the Heading of the Normal vector. There is no Pitch for the Normal vector becouse it always sits on the orbital plane (Pitch = 0). I didn't know this at the time of my pull request, but sending this isn't necessary - the NormalHeading should always be ProgradeHeading + 90. Thus it probz wont hurt to remove it. Also you can easily get the Radial vector pitch/heading from the the Prograde and Normal vectors, so no need to send that either.

Well, haven't had time to work on the UI changes I was planning, but I did make this orbit viewer widget: It can display your current trajectory, (all your encounters and escapes), and your planned trajectory. The view can be changed by dragging with the right mouse button down (or WASD), and zooming with the scroll wheel (or QE).You can select what patch (a section of the flight path) you want to view with the UP/DOWN arrow keys. I have also added some more readouts to the navball rendering.

So, with the fuel data work right now, there is no way to detect if an side booster/engine has run out of fuel, should something be done about it? Also should I fix the stupid thing where you can only target Vessels and not celestial bodies?

Does anyone know how to the the anomolies for the transitions between orbits in patchedConicsSolver's flight plan? Edit: To add on, I am programming an external orbit viewer. I can draw individual orbits, but I am not sure where to get all the required data. patchedConicSolver.flightPlan only seems to have the orbits created by maneuver nodes, not by gravity assists and stuff. Edit 2: I have figured out most of the orbit stuff I need to know, but I still can't figure out how to get the anomalies for the orbit patches ends/starts.

New release! Firstly I've a "controller" widget, as well as support for USB Joysticks, allowing you to control your rockets: Secondly, I've small changes that should be pretty insignificant. In the future, I plan to switch from a window based UI to a divider based UI, and make the whole thing look more like an actual MFD, as well as adding more cool display widgets to make this a useful application! If anyone has tried this, please do offer some feadback, I want to improve it! (And I promise i'll stick around to see your posts )

I hate to triple post, but it's been a while an I've made some changes. First of all, I have refactored most of the plugin code into separate files, and moved the MFD code into a separate repository. This should make everything easier for me to manage, and the refactor will allow me to add support for multiple client connections. when I get around to it. Secondly, I improved the protocol. Instead of trying to reexplain the protocol every time i change it, which probably has led to some confusion, I simply have created a set of Java and C++ bindings. The bindings come with an example script, and I think providing the bindings should make this plugin easy to work with. I have added some features to YARK, such as an "11th" SAS mode that allows the client to specify a custom vector to point the ship at. If anyone is confused by the helper methods in the ControlPacket Class/Struct, I will be happy to document them!

Can I PermaPrune Squad default parts to speed up the game loading? Or will it not effect the loading times?

I think more "easter eggs" and land marks should be added to make exploring Kerbin and other planets more interesting. Not sure what those would be, but maybe caves you could fly through or something would be awesome. Also more realistic terrain like forests with dense vegetation that you could crash into would be awesome to see, although this seems technically challenging to implement, and not really relevant since this is a *space* game after all.

Ha well- simple solution but it works; thanks!

I yoinked the code and it seems to work somewhat. However there are two problems I have with it. First of all, it seems to overshoot all the time, but this should be easy to fix by adjusting the values in around line 242. Second of all though, although Rolling and Pitching seem to work fine, adjusting the Heading makes the craft/navball rotate "straight" to the left/right instead of along an arc. For example, after setting my target pitch to 45, roll to 0, and heading to 0, the code orients the craft like this: As Increment target heading, I expect the craft to rotate along the green line, but instead it rotates along the blue line. Do you have any idea what could be causing this? I replaced the getReferenceAttitude(activeReference) on line 235 with Quaternion.LookRotation(north, east), where "north" points to the north of the planet and "east" points east. Edit: IDK why i always find solutions soon after I post about something, but I think this code works for calculating goalOrientation: https://pastebin.com/G8LABpbm

Is there a good way to detect a "Revert to launch"? Neither the ActiveVessel.id nor the SceneManager.GetActiveScene().buildIndex seem to change.

Yes! Sorry for the late reply, I haven't been active much, and apparently I am not subscribed to email notifications for this thread :(

@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

The output vector's value's seem kinda meaningless

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.

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

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 have an extra monitor. List of Widgets and controls: +Navball +Map for airplanes Mouse Wheel - zoom Hold Mouse wheel button - Pan around map Double click mouse wheel - reset to craft +Attitude Indicator +"Soyuz Navball" +Orbit Display Arrow Up/Down - select orbit to highlight When selecting a orbit patch with a maneuver node: [X] - Delete Man. [H/N] - Adjust Prograde [J/L] - Adjust radial [I/K] - Adjust Normal [U/O] - Adjust Time [Shift] - Adjust Faster [C] - Create a new maneuver node. Should be created in the middle of the current orbit patch. Might be a bit buggy, and you would have to set the time with U/O.. +Fuel levels +Docking Alignment Basically once you are close to target, use WASD to move the orange reticle to the middle. Then use IJKL to move the purple reticle to the middle. Simultaneously use HN to control your approach. [X] - Stabilizes your position relative to the target docking port. +Various graphs +Controller for SAS/AG +Basic Airplane autopilot YARK-MFD requires at least openGL 3.3, and is currently only compiled for 64 bit windows. Compiling to linux should be possible using the provided cmakelists.txt. YARK-MFD can be downloaded here, and the YARK plugin (required) here. Source code for YARK-MFD is here. Compiling YARK-MFD requires SDL2, glm, freetype and glew (see /Lib folder).