Search the Community

After attempting to determine frame rate loss and unnecessary lagging, I have been able to identify that a large portion of issues are being related to the physics engine running through the GPU and the utilization of said GPU will become choked if the perceived framerate exceeds what the engine is calculating in comparison to the GPU. This could be part of the engine to ensure that the engine physics can't run away with GPU utilization and cause damage or overheating on the cards. Full utilization can happen in the game with smaller vessels and when out of Kerbin, but why would the utilization drop when needing more resources due to the number of part, physics calculations, etc. Is this something that is being looked into or are we expected to see this resolve with the future patches and updates? Currently running these specs: AMD Ryzen 9 5900X 12-Core Processor 3.70 GHz EVGA 3080ti 12GB 64 GB DDR4 3200 MHz Ram Please let me know if there are any tips or if there is any other information required.

I got an awesome new gaming laptop to play KSP with, but it has poor battery life. So, I went and bought a new Maxoak 50000mAh power bank to use with it. It was going fine until it kept shutting itself off while I played KSP. If I wanted to play KSP, I'd have to lower my rig's GPU to low power mode, or else it would trip the power bank. I looked at what happens whenever I did this, and apparently the battery rapidly alternates between being charged and not being charged while on higher performance modes. It would be stable, but the Maxoak is programmed to automatically shut itself off if it's not charging something. This makes it totally unusable. I went to Reddit with this, and I've had no luck. Does anyone here know how to fix/workaround this?

Will Kerbal Space Program run well on AMD Ryzen 5 3400g with Radeon Vega 11 Graphics APU? Without a separate graphics card with, 16GB DDR4 2400MHz RAM; 500GB M.2 NVMe SSD; Asus EX-A320M Motherboard?

Hello Everyone, I looked up to the developers show case yesterday but one thing ravages me THE HARDWARE REQUIREMENTS OF THE NEW KSP 2.As the graphics are awesome so it may be a problem for many AMD and Intel low end processors and graphics card like GT 730 or GT 710.Will KSP 2 run on low end system like mine(for reference) I3 9100F GT 1030 16GB ddr4 ram. Thanks

I have a problem with the CPU temperature in my laptop (it gets hot terribly). I recently installed KSP 1.9 (unmoded) and it worked terribly (high temperature and 5-10 fps), previously I played version 1.4 or 1.3 a few years ago on the same computer and I didn't have this problem even with many mods. What is the reason? High terrain resolution in new versions? I don't know much about hardware, maybe only one core or something works? Thanks. I am using Dell Inspiron 3542 Intel Core i3-4005U 1.7 GB Intel HD Graphics 4400 / GeForce 820M 8 GB RAM

My Mark IIb control panel broke down in the spring due to a careless shortcut, and I have been building and redesigning this one on and off since then. I actually missed 1.5 completely, but finally the hardware is at an acceptable configuration. So, after a few time consuming mistakes, I flew an initial test flight with my Flight Control Mk IIId, and was happy with the result. What started when I looked at the price of a joystick with throttle and thought I could make one cheaper did turn out to be a hobby consuming hundreds of euros and opening a whole new field of learning. When I started, I knew a bit of electrics, barely more than Ohms law and the underlying physics. I had written small pieces of software in a lot of languages, but never looked at the beast known as C. The layout: When I realized I needed to redo the panel, I gave some thought to what functionality I was using at the most, and what I needed to see while I still could see the navball. This meant that the two main LCD displays was kept center top, providing me with whatever information I need at the current stage in flight. Below that analogue gauges showing information I need to be aware of approximate magnitude of without having to read a number. A real time clock is also center, it starts blinking a 'b' once time reach past 10 pm for reasons that should be obvious. The joysticks are placed at a distance that corresponds quite close to how far my hands are when I put them in front of me. I used to have them in the corners, but It turned out that I always was pulling a bit off axis as I had to reach to the side for them. Throttle is by the left hand, as I need attitude and throttle control in conjunction far more often than throttle ans translational control. Below the throttle is a momentary brake, and the big red stage button and its toggle. Toggle switches right upper corner have their functionality lit up either red or green, and as they are rather big I can reach them with either hand. The keypad on right side, on the other hand, is so small I need to focus on it. Apart from time warp control, it is mostly used for tertiary functions, such as science gathering, switching navball mode when I want something else than the default, or cycle camera or craft focus. Lower right corner is a number of rotary knobs. This is partially selectors for SAS mode, cam mode/map/IVA and control panel mode (rocket, aeroplane or rover), partially a set of trimmers for the attitude joystick and engine percentage. The LED display in that area show the value of a trimmer when said trimmer is adjusted. Finally, the big red abort button is well out of reach in case I should hit it accidentally, but easy to hit if I actually need it. As with the stage button, is has a toggle switch that physically disables the circuit when locked. The hardware For this panel I went with an Arduino Due. My previous build used a Mega, but I had instances of it not being fast enough when doing a bit of trigonometry and some square roots for my LCD displays. The Due runs at a native 3.3V, so I had to make a level shift protoboard for those units that run at 5V. The 5V are supplied by an old PC PSU, but given the low demands of the system I can keep said PSU off and just use the 5V 2A always on line. Still, nice to have all the power I can dream of within easy reach. Luckily, KSPSerialIO and Win10 talks just fine with this board, although I also have a CH340G USB to serial adapter connected to Serial1. I finally caved in and bought a crimping tool and proper connectors for my wires instead of soldering bits of header to the wire, and ribbon cables for most of the long connections. The protoboards I use are laid out as breadboards, saving a lot of soldering as well, and the wires on the board are single core. These improvements in manufacturing have been costly, but well worth the investment. Loose wire strands generate a lot of noise, and I had to scrap two protoboards where I could not locate the culprit. I have in recent years started to suffer from farsightedness, a fact I found out by having more and more difficulty soldering said protoboards. When soldering these days I use a magnifying lamp my wife exchanged for a better one (she does needlework), and have a set of reading glasses to go with my contact lenses. The annunciator and toggle status lights are all WS2812B LED strips, which saved me a ton of soldering. They are mounted on the button of 3d printed grids and shine through a layer of PVC slides with the actual print and food wrapping paper beneath to diffuse the light sufficiently. All digital switches are connected to 74HC165 or CD4021 shift in registers, and the rotary selectors are connected to 74HC147 encoders, which in turn are connected to shift registers. The reason for using 74HCxxx IC's is that they run at the Dues native 3.3V, so I did not have to level shift the signal to 5V. That was not the case for the 7seg LED modules, that are bought as units with integrated MAX7219 IC's, or the 4x20 LCD displays and the DS3231 real time clock, both types are 5V I2C connected units. The translational joystick is carried directly from my last control panel, and I am still very happy with it. It consists of a thumb joystick and a small piece of stick between two micro switches for three axis control, in a 3d printed casing. While I do use the twist of my attitude joystick for rotation, I would not like to depend on it for fine control or fast reaction. I use a slide potentiometer for throttle. I spent a bit more to get a fader for a mixer instead of a standard pot, I wore my previous throttle out and had problems with unintended engine ignition. The keypad is made from scratch with push buttons on a protoboard and another 3d printed grid to keep them aligned. There are still quite some empty positions on the keypad for when I get ideas to expand my functionality. The software On this panel, I have several functionalities that cannot be activated through KSPSerialIO, so I turned to kRPC. Unfortunately, while I could make a working Python client for kRPC and it even did some of the computational heavy lifting for the Arduino, I experienced considerable latency. This is surely partially due to my very imperfect implementation of the serial communications, but I knew that KSPSerialIO worked fast and out-of-the-box, once I added __attribute__((packed)) to the packets due to 32-bit architecture of the Due. So in the end I just decided to use both plugins, with kRPC handling complicated, non time dependent operations. First iteration had me send information to an Uno over I2C to send to kRPC, but in the end I connected a secondary serial port and cut the middle man. The Interesting ability of kRPC is to access almost everything in the game. In every vessel I made, I assigned solar panels to action group 1, ladders to AG2, science to AG3, engine mode to AG10 and so on. With kRPC, I just ask nicely to open all solar panels, with the important qualifier that there is no docking port between them and the root part in the three hierarchy. This means that when I carry a station part in my spaceplane and extend the solar panels, the solar panels of the station part does not try to unfold inside the cargo bay. In a similar vein, I have toggles for radiators and cargo bays. Science and repeatable science is on different push buttons, although I need to fiddle a bit with this part of the code: If I carry two goo containers, I only want one to open at a time. The code looks for the smallest storage of electrical charge and ties it to a toggle as well. This means that if I forget to extend my solar panels and a probe goes dead, I have a reserve of power to reactivate it. Admit it, you have been there as well. Communications between the kRPC client and the Due is still the biggest issue in the software. I sometimes get massive timeouts, and I still need to implement fast and reliable transfer from the client to the Due. kRPC can access information about misalignment between two vessels when docking, radio signal strenght, and the life support resources. I would like to have an alarm going of based on that information. On the KSPSerialIO side, there is lots of code reuse. I had made functions to deal with LED displays and the information on the LCDs is mostly carry over. Interesting notes are that I calculate circularization dV during the orbital phase of ascent when in rocket mode, and the deviation from KSC runway in aeroplane mode. I also have distance, relative velocity and approximate expected time of arrival showing up during rendezvous. Code to do While the controller works, there is still lot to be done. I have a 7seg to spare that should show time to maneuver node or rendezvous, and most of the annunciator is not programmed yet. Also, It would be nice to be able to call kRPC autopilot sequences from my panel, I have several standard launchers that could benefit from automated launch. Also, a general clean up of things that work but need polish on the second LCD display, it is not fully utilized yet. Source Code and thanks I finally learned how to use GitHub, so my code is available there for both Arduino and kRPC client. I learned a lot from reading other peoples code on the web, and especially @PeteWasEre have good example of using kRPC. As always, @stibbons is a fountain of knowledge, as well as the kRPC discord. And everybody else in the KSPSerialIO thread.

Hello all, Today I want to share with you our development process of making two control panels and I’ll try to answer your most frequent questions. Me and my friend (Ferrdo_Kerman on this forum) always wanted to build control panel for Kerbal Space Program, so we can have even greater experience while playing this fantastic game. This year we finally had this opportunity and time to make this happen. Ferrdo is very skilled in HW and SW so he is the one who decided which HW do we need, how to put it together and also rewrote the base code that we have used from another project. My job was less technical, I worked on design, box, switches variants and I helped with the soldering of course But let’s start from beginning. 1. Preparation Phase We were inspired by hugopeeters project. He made excellent job and our life much more easier because we didn’t have to start from scratch. So really big thanks and credit goes to him. You can check his project with many details here: I will not go so deep into the details because they are already covered in his project but I will just mention that for the communication with the game we used KSPSerialIO plugin which can be found here: https://forum.kerbalspaceprogram.com/index.php?/topic/60281-hardware-plugin-arduino-based-physical-display-serial-port-io-tutorial-10-06-17/ So we bought our first Arduino mega, cables, basic switches, basic stuff and started on our panels. We mainly bought items from local store with electronics and also from e-bay. 2. First steps Ferdo started on LED bars because we assume that this can be the biggest problem and we wanted to solve this in the beginning. From start we had only bars that are now used as G-Force and Athmosphere indicators. This is how they look from behind also with integrated circuits: Even though it went somehow let’s say a Kerbal way, it was a success! After that we moved to display and basic switches. 3. Display and Cardboard prototype We have continued with display because we wanted to test also basic switches and if they are responding correctly regarding the code. While Ferrdo was working on the display and also adjusting the code, I’ve started with the basic cardboard prototype so we can manipulate with the HW easier. In this stage we have decided that we will use another bars for fuels, mono, power etc., and that we will use these old bars as G-Force and Atmosphere indicators. Because in this phase we already know everything that will be on our control panels I have started designing the panel. 4. Design After some adjustments we ended with final version of our design: I’ve prepared vector files based on this design and one of our colleagues helps us to make a prototype from wood so we can check if everything is OK before we will order final panel made of stainless steel from external company. Everything was OK so we have ordered our steel panels from external company. We haven’t had good luck with the first company and they didn’t do the labels correctly. In fact they were barely visible. Luckily we found another company and they reworked our panels to the final look. This was the most expensive part of our panels and one piece cost us almost 100 euros (because of double work). But when they arrived we were finally happy with the outcome. While we were waiting for steel panels from external company we was soldering all parts for the second panel and I was able to prepare box cases from wood. 5. Another Led bars and finishing touches The set of five LED bars took us some time to finish because there were a lot of soldering and coding work. But finally we were really close to the end and therefore hyped. We went to the local store to buy final LED lights (I think it was 7865th visit of this store :D) and started to mounting everything to the panel. It was a really big mess of cables. We did the final soldering and check and we finally put everything inside the box. After some finishing touches everything was functioning correctly! Everything was a little more complicated as described here because we were learning on the fly You can find the source code to this Arduino project at: https://github.com/ferrdo4/KerbalController Video from action is coming soon!

After looking in to the internet, I couldn't find any info of what is a good CPU performance in KSP (measured in parts). I just want to know whats the limit of parts your CPU can handle until your timer becomes yellow.

Hi So I just sold off my RX 580 graphics card and is currently using my backup GT610, and I am wondering if there are any ways to make ksp playable on that graphics card without sacrificing too much. I have a watercooled R5 1600x CPU and 16 gigs of ram, and I am currently getting around 4 fps with settings maxed out. What can I do to get my framerate above 30 fps while sacrificing the least amount of detail? Thanks!

Somehow my steam recognizes my joystick (Logitech extreme 3d pro) as a generic gamepad, and is stuck in some weird control profile. I can't seem to delete the profile or reset anything regarding to the joystick. When I open the joystick in the device manager I can see that it's working by testing everything in the properties. I've spent hours trying to figure this out, and haven't found anything pertinent to my situation. Please help me out!

Winter is coming.... ...and I need something to occupy my time while hanging out indoors. Anyone up for working together on a control panel? I'm not a software mod'er, so I need help with actually integrating with KSP, but I am pretty good with electronic design, Raspberry Pi/Aduino, etc... Essentially, I'm thinking of building a small instrument cluster and a cluster of tactile controls (buttons, switches, joystick?) that would sit in an angled enclosure that would sit on your desk. Anyone up for teaming up?

KSP sometimes causes my mac to suffer an error related force shutdown when I attempt to defocus KSP. This has happen once or more per day. I think it is a memory related issue. My specialty is making missiles, not fixing hardware. (But I am great at breaking hardware) Don't quote me on this I come here instead of apple because my warranty ran out and I might have to pay money to get it checked. Plus, they would find where my secret base is. Specs: MacBook Air (11-inch, Early 2015) Processor: 1.6 GHz Intel Core i5 Memory: 8 GB 1600 MHz DDR3 Graphics: Intel HD Graphics 6000 1536 MB

I tried the Alt-F9 video recording feature that comes with my new Geforce card software, and found it really easy to use. I was hoping to have a dogfight thread where each participant record some of the videos, but was wondering how common is video recording capability in our community. Most people probably don't have dedicated recording software, and I don't either, so I was wondering how many people have Geforce Experience, and if you tried recording video with it? cuz I think Nvidia cards are pretty common these days.

So after seeing @richfiles, and @stibbons controllers, I've started thinking about maybe (key word maybe) making one of these things. Bear in mind that I have no experience with arduino, or anything other than wiring motors and lights to batterys. Here are my basic ideas. Please tell me if some really aren't possible. Kindle fire for streaming navball from Telemachus 7 segment displays for velocity, altitude, apo/periapsis Joysticks for rotation/translation Toggle switches for SAS, RCS, and etc keypad for action groups, maybe a gutted computer numpad Stage button, one of those buttons with the clear cover for abort action group Master caution, like when my ship reaches critical temperature I don't know if this is possibe, but a terrain alarm, with a button that would light up and yell "terrain!" at you, if the ship is under a certain altitude, going above a certain speed throttle lever ??? I might add more to this list, remember that this is all in my head, and I don't know all that much about electronics, so keep that in mind. The main problem about this is money, as I'm not an adult, and I don't have a job. I would love to make this dream a reality, but we'll see...

I have been working for the past couple of years on a project to create analog gauges that could display some of the game information. Finally, I also developed a program to display the ground tracks and flight profile. Both rely on the mod telemachus and its http server to get the necessary data. Here is the final result. I didn't spend much time on the board itself, as I wanted it to work properly first. The gauges display most ressources of the game (liquid fuel, oxidizer, monopropellant, etc...) and three other parameters: Gs, vertical speed and atmospheric density. I also used two 8 digits 7-segments display for altitude and speed since both these values can vary a lot in the game, it didn't seem appropiate to use the analogue gauges. I recuperated the screen from an old laptop to diplay ground tracks or flight profile. 1) Gauges The core of the gauges is a micro stepper motor X27-168. They are sold as automotive spare parts, mostly for US brands, and quite easy to find. There are quite a lot information about them, especially on Guy Carpenter blog http://guy.carpenter.id.au/gaugette/ The plastic support is 3D printed In order to control the motor, I am using an arduino Uno and the motor driver vid6606. Through my various trials these came to be the best solution. It gives smooth needle movement and is a very flexible solution to add/remove gauges. Each one of those can control 4 motors. The arduino itself is connected by USB to a raspberry pi that sends the http request and calculate the required position for each motor. I had initially tried to control all motors directly via the raspberry pi, but the result wasn't as good: when all values were updated simultaneously, some lag and stutter could appear on the gauges. 2) Ground tracks and flight profile I thought it could be cool to have be able to visualize the ground tracks of a vessel in orbit. Again this is using data pulled from telemachus. Some settings available: However, this is only good in orbit, so I was also inspired by the mod Houston and made a mode to display the flight profile when not in orbit: I initially wanted this to be also diplayed by the rapberry pi, but it wasn't as smooth as when using my laptop, so I finally gave up on that. It was the first time for me to code and I'm sure it could be made much lighter to work well with the rapberry pi though. I had a great time creating all this (more maybe than using it...), I hope you like it too. Let me know what you think!

FOR ROCKET USE ONLY: A Kerbal Sim-pit Build Log A name derived from the first piece I bought, a racing car ignition switch with "FOR RACING USE ONLY" printed across the top. This Project started mid 2016 and while its a matter of months off being in a completed form, like most maker projects, I don't ever think Ill be "Finished" with it Aim My aim is to make a sim-pit that surrounds a keyboard that includes a joystick (microswitch, not POTs) and as many switches and buttons I can. After many months of looking at layouts and design themes, I've settled on going for the most Raster Prop Monitor looking IVA theme I can, basing a lot of my panels on this mod. If you don’t know RPM it adds a fully usable IVA into Vessels and looks so aesthetically pleasing: EDIT: This is actually the command pod from the ALCOR mod The Idea is to go more for fun to use than practical. I want as many missile switches and pointless (but useful) knobs and flashing lights as I can. Basically I really want to go for that Arcade, really fun to use feeling even if its not overly practical. Hardware/Software I'm currently using two Arduinos and coding with Arduino's IDE; Arduino Due Old Arduino Uno knockoff (Freetronics Eleven if anyone cares) Arduino Mega The Due uses the <Keyboard.h> library to emulate button presses to control KSP. Flicking a switch will emulate a keyboard pressing a button, for example, flick the light switch, the Due sends a “U” to the computer. But because the switch can be stuck in the on position, the Due only sends the command when there is a change in state. *** The <Keyboard.h> portion of the project has been scrapped in favour of using Kerbal SerialIO's control functions. This means I have lost some functionality meaning a keyboard is still necessary however there are also a lot of pros of doing it this way. This completely removes the use of the Due. The keyboard emulation may return if the build gets an upgrade/increase in size. *** My KSP uses a mod called Kerbal Serial IO by Zitronen, the mod does nothing to the game but sends data packets to and from KSP to the Arduino via Serial communication. Way too technical for me but once I got mine working, it has infinite potential. I'm able to access data from KSP and either print it or use it as logic for warning lights. Their is infinite possibilities with this thing. I have also been able to get my code working with WIN10 as some people couldn't get the control packets working on windows 10, the bug has been fixed and I am now using the control packet to control KSP. I am using two DuinoTech 128x64 Dot Matrix LCDs as my HUD. Arduino has its <LiquidCrystal.H> library making it so easy to code for the screen. Controlled by four buttons to switch between different data sets relevant to different situations and a neat little protoPCB to make all the wires a lot neater. The whole build is designed on five identical sized panels to allow for easy modular use incase I rebuild the enclosure (thinking about a full seated simulator in the future, maybe) Current Stage Here's a few things I've currently got working Currently Built/Working: Staging Button and Stage lock Switch (Prototype) Toggle Switches emulating keyboard press (Controls SAS, RCS, LIGHTS, GEAR) Dual LCD Heads Up Display with real time Data from KSP (currently only displays speed) Fully implemented as of early 2018 Communication from KSP to Arduino (KerbalSerialIO Mod) with onscreen *LED connection Status indicator Control Packets sent from the Arduino to Kerbal via Kerbal SerialIO LED warning Matrix Apollo Style toggle switch guards Laser Cut acrylic panels Custom Enclosure surrounding Keyboard Planned: Custom Enclosure surrounding Keyboard ({Implemented Mid 2018) Joysticks for Attitude and for Throttle (Purchased but not coded and implemented) Controls for LCD Screen changing the Data printed on screen (Implemented early 2018) Possible second LCD for more Heads up Data (Implemented early 2018) Warning LED matrix (Designed and built early 2018) Laser cut acrylic panels with back lit text. (Implemented early 2018, no backlit text.) Possible custom analogue throttle Resources + Credit Ill post all my code but most of it for the Uno is Zitronen’s “Demo16” Code which I have modified. I'll make it clear in the Code what is mine and what was original. All code for my keyboard emulating Due is original. I will comment in code if that changes. *Due removed from build I’ll also make sure to give credit where it's due (in the forum or in the code) as I’m taking a lot of inspiration from other Build logs as I find the fascinating. If I miss something, I apologise. GitHub Code Not really updating anymore, will post final code when done, not posting every iteration Build Logs 18/12/16 For Rocket Use Only First Prototype - 27/12/16 Heads Up Display Screen 27/4/17

Pictured above, the current (as of Dec 2020) mockup of my end goals for this project. Construction of the custom desk is complete! It just needs electrical work! I've been working on this project on and off since around June of 2015... I initially first appeared on Page 6 of the Simpit Repository where I showed off some really nice hardware I'd collected for the project. The goal is to create a controller using real instruments to provide readouts of orbital data, temperature, fuel, electricity, and other critical values. The controller will have joysticks and toggle switches and other controls to command the in game vessel. I'm using this project as an opportunity to force myself to learn C programming, and as a furthering of my electronics hobby. While this thread has a LONG way to go to catch up with my progress, I'll work on it over time. INSTRUMENT PANEL PROGRESS STATUS DESIGN HARDWARE SOFTWARE Assembly: Completion % 100% = Difficulty••• Completion % 100% = Difficulty••• Completion % 100% = Difficulty••• Analog Resource Meters 0% • Vertical Velocity Meter 90% • 0% • Radar Altimeter Tape Meter 80% • 0% • DSKY Numeric Readouts 10% • DSKY Units Readouts: ------- ------- ------- Diode ROMs ------- Address Decoders 75% • 25% • 0% •/• DSKY Annunciators 90% • 75% • 0% • DSKY Keypad 90% • 90% • 0% • Delta V Carriage Meter 25% • 0% • 0% • Navball Controller: ------- ------- ------- 400Hz Sine Gen ------- 115vac Amplifier ------- Synchro Emus 25% • 0% • 5% • AUX Data Display 25% • 0% • 0% • Velocity Readout 95% • 0% • Attitude Rate Meters 50% • 0% • 0% • Bezels 10% • 0% • ------- CONTROLLER PROGRESS STATUS Not yet officially started, but many individual components and designs have been established, including the support frame. The control panel, fortunately, is a much simpler build electronics wise. It's mostly machining panels and mounting hardware. Solder all the bits together, add some communication to the instrument panel's main controller, and that's it! Part of why this has taken so long, is it's not only a learning process, but I've split my time with other projects. My custom mechanical keyboard was built to work with this Kerbal controller build, and will actually slot into the controller! The number pad magnetically detaches, so when my keyboard tray is extended, I have full use of the extended keyboard, but with the tray pushed in, I can set the number pad aside, and use only the core keyboard! This is the button that started it all. I was inspired by how AWESOME this button looked, and how big and red and "Aborty" it could potentially be! The Instrument panel enclosure is a re-purposed Harris Stereo 5 console that was saved from the local AM radio station. You can see several instruments here. On the right is my analog vertical velocity meter, and in the middle, my FDAI. The Flight Director-Attitude Indicator, more commonly known around these parts as a navball, is a real awesome find! I'm in the process of building a controller for it, but that is a daunting task... It requires nine 28 volt amplitude modulated sinusoidal outputs that are controlled by multiplying DACs, and a 115 volt sinusoidal reference source to provide both power and synchronization for all the 9 other signals. This is the keypad I made for my "DSKY", inspired by the DSKY (DiSplay KeYboard) of the Apollo Guidance Computer (AGC). It normally lights green, but can flash red if there is an alarm condition... Such as the "I'm about to pop like an overheated popcorn kernel" condition. My throttle lever (as well as the keys for my DSKY keypad) were salvaged from an old video effects controller board. I have a LOT of these relegendable, backlit push buttons, in two different sizes. My analog meters are inspired by the edgewise meters used in the Apollo Command Module, Lunar Module, and Space Shuttle. I'm taking the extra effort to print proper scales that use the Futura typeface that NASA used, and follow an overall design that visually resembles the Apollo instruments. Likewise, Tape Meters were also used as instruments on Apollo, and even more so in the first revision of the Space Shuttle, before the glass cockpit upgrades. Tape meters have a long tape on spools. The numbers scroll passed a stationary pointer, the opposite of what an analog meter does, where the pointer moves over a fixed scale. This allows very large scales to be depicted, limited only by tape length. The meter I have will be reprinted with numbers corresponding to the radar altimeter. This is the complete DSKY. I'm currently working on it, and getting it to the point where I can control all the LEDs right now. Current progress has all the large numeric LEDs controlled by MAX7219 controller chips, and the small 7 segment display and one of the three alphanumeric displays is currently functional. https://www.youtube.com/watch?v=8Cwm_xQZsFo https://www.youtube.com/watch?v=LwXZKIfvEkI https://www.youtube.com/watch?v=1Wlv3oyobcg Flashy, isn't it! I've been making diode ROMs to decode characters for some of the LEDs. These cost me literally nothing but time to make, and they satisfy my interest in basic digital circuits. I also rather find I enjoy three dimensional free form circuitry! So yeah... I'm enjoying this part! In all honesty, I really should have started this post back then! I was just collecting parts back in those days, and always said I'd start a dedicated thread when I began assembling things... The Simpit Repository is now up to 23 pages at the moment I'm typing this... It just grew to incredible proportions, and a few times I felt a little bad for dominating the thread with build posts (that really belonged here), but at the same time, I knew my work was showing other people how to do things, and keeping the Repository frequently in the lime light. It just grew to a size that felt too big to abandon, and too big to move the content. I'm starting this post, because I think this build HAS started moving at an accelerated pace, and It should have a dedicated place. I'll build this post up gradually, to cover not only the new content, but to consolidate the content I posted in the Simpit Repository here as well, so the entire build process is properly detailed. I had debated whether I should move content (remove from the Simpit Repository, and replace it here), but I think that'd be unfair to those who replied or were inspired by that content. I'll eventually consolidate everything here, but I'll leave my old posts at the Repository alone. as for new posts, I'll still post at the repository, but I'll no longer post massive multi-image mega build posts... I'll keep my posts there a bit more basic, and put the details all in this post. I'll still offer my knowledge to answer questions people have at the repository. That won't change. It's just silly that I've taken THIS LONG...

I was wondering which SI prefixes KSP uses in game, and are there any that are skipped? I ask because I know it skips km on your altimeter... (I'm so wrong! i guess I must typically timewarp from LKO to any other body and never noticed Km before! LOL ). It just goes from counting hundreds of thousands of meters and then rolls over into, if I recall correctly, Megameters. After that, I know I've seen Gigameter measurements before in the map views. Does KSP skip any other units than km, or is it just that one unit that gets skipped? I think I recall seeing km used in map view for distance to target, and in standard view to show distance to other objects. I just don't know if km is used for any orbital data... Altitude, Apoapsis, Periapsis, etc. I'm currently in the process of building a digital orbital data readout to fit into a larger scale custom controller for the game. I'd like to keep the units displayed on the controller matching the units displayed on screen. It'd be disorienting to have my readout show 100 km, and the altimeter on screen say 100000 m. I know they are the same, but it's not consistent. I'm occupying myself with continuing my controller build, since my motherboard unfortunately died. It's hard to run KSP to check for units of measure when your computer ain't even functioning. Who knows... Maybe I can get some progress in before the motherboard is repaired/replaced. Adittionally, I also wonder how high do the SI prefixes go? I want my readouts to go as high as they need to go to cover whatever KSP can throw at it... m, km, Mm, Gm, Tm, Pm, Em, Zm, Ym... What's the largest SI prefix KSP actually supports? Are there any other prefixes that KSP tosses out due to the number of digits the altimeter displays? Does the map view use km for any orbital characteristics? I got some nice 14 segment alphanumeric displays that are smaller than my main numeric displays. They are at the end of each relevant numerical display, and will show the correct SI units. I can make the displays support all units (as well as "m.S" and "ΔV"), but it will require more work to add the extra characters. Don't ask me why, but I'm doing a diode matrix ROM for them. It'll be kinda retro, but extra work to have extra characters supported. So... yeah... Just curious if I should plan on supporting them? Thanks in advance. *UPDATE* So, apparently, I am just blind. I never noticed the use of Km as an altimeter measurement, likely cause it occurs in a range that I rarely orbit at (or stay at for long). I can salvage this post though, as now I need to catalog the transition points. Where does KSP switch from m to Km, Km to Mm, Mm to Gm and so on. When I get my motherboard back from being serviced, I'll fire up KSP and check it out, recording the transition points here (unless someone beats me to it).

No longer maintained: I don't maintain this mod any more. @Simpit Team have taken over supporting and working on the mod, please see their new release thread. What does it do? This plugin maintains serial connections to one or more hardware devices. Each device can register to receive information that it explicitly wants to receive (for sending to a display, setting off an alarm, triggering a PC shutdown when your vessel runs out of power, etc). A device can also send commands back to the game (stage your rockets with a big red button, build a custom HOTAS to pilot planes, control your EVAing Kerbals with your treadmill, etc). The plugin comes with a companion Arduino library, to make it easy to get started building interactive Kerbal hardware. No really, what does it do? It lets you build things like this: What does it run on? I officially support and test this plugin with 32- and 64- bit KSP on Windows 10, MacOS and Linux. Previous versions of Windows... probably work, but you're on your own. Most microcontrollers should be supported, but only a few have been thoroughly tested so far. Refer to the Supported Devices page of the documentation wiki for more details. If you're using something different, I'd genuinely love to hear about it. What sort of information can I send and receive? The plugin currently sends: Altitude data (sea level and surface. Velocity data (orbital, surface and vertical). Apsides data (apoapsis and periapsis). Time to next pair of apsides. Resource levels (stock fuels, ore, ablator, etc). Action group status. Target information (distance, and relative velocity). Current SoI. The plugin is able to receive commands to control: Custom action group commands, with full support for Action Groups Extended actions. Regular action groups (staging, abort, RCS etc). Main throttle. Vessel rotation and translation. Wheel steer and throttle. Eventually the plugin will be capable of sending most of the telemetry you'd expect from stock KSP and mods such as KER. It will allow full control of vessels and Kerbals, and some limited interface control. Where can I get it? Search for "Kerbal Simpit" on CKAN. I only support installation of this plugin through CKAN or similar mod managers. The only other automated module manager I'm aware of KSP Mod Admin, but I've been struggling for weeks to get it to run on any of my test systems. If there are others around, I'd love to add support for them. Note for the few folk who tried out prerelease builds: You should probably remove the custom CKAN repo from Settings -> CKAN Settings. I'm not uploading releases there any more, and it will eventually go away. The source code is available from https://bitbucket.org/pjhardy/kerbalsimpit/overview . Binary releases sit in https://bitbucket.org/pjhardy/kerbalsimpit/downloads/ . What else do I need? This mod uses Alternate Resource Panel for all of its resource information. Without it, none of the resource providers will send data. This mod will make use of Action Groups Extended if it's installed. With it, all 250 action groups can be accessed. Without it, only the stock 10 action groups will work. Where can I get the Arduino library? Search for "Kerbal Sim Pit" in the Arduino Library Manager. Its source repository is at https://bitbucket.org/pjhardy/kerbalsimpit-arduino/overview . How can I use it? For full documentation, refer to https://kerbalsimpit-arduino.readthedocs.io/en/stable/index.html Quickstart guide: Install the plugin. Configure the plugin. An example config is in `GameData/KerbalSimpit/PluginData/Settings.cfg.sample`. Either copy that file to Settings.cfg or just launch the game once and let the plugin generate a default config. Refer to the Plugin Configuration page on the wiki for details on how to set up ports. Install the Arduino IDE and install the library. In the IDE, browse to File -> Examples -> Kerbal Simpit. Select the KerbalSimpitHelloWorld sketch and flash it to your board. Run the game again. The plugin will log successful device handshakes to KSP.log. Changelog: Full changelog is available from https://bitbucket.org/pjhardy/kerbalsimpit/src/master/CHANGELOG.md?fileviewer=file-view-default License: This project is licensed under the Simplified BSD License.

i am resuming an old project i had but did not document. it was to make a custom ksp cockpit In Real Life and use it to play the game. there was also a mission control. it wasn't that good. my new version will feature a 2 person cockpit, electronic flight instrument system, switches, and buttons etc. there will be an external mission control as well. i will document all my code and mods that i use so that if any one would like to try and build it them self they can. 1. design phase main switch board images SAS mode light board: Control section Engine control section i'm going to add a fuel pump section that will not let my engines start till the fuel pumps are switched on

KSP runs reasonably well for me right now. However, sometimes when I'm in a high part-count scene the frame rate I'm able to draw drops down to about 20fps. This isn't horrible, but it is noticeable. I'm considering upgrading some components. However, I'm not certain if the bottleneck is in the CPU or GPU. Is there a way to easily find out which is the constraining resource? - Garrett

Hi there! Some mates and I participated in this year's SpaceApps contest by NASA on the Jet Set Mars challenge. We focused on developing a complete solution for a Mars-suitable jetpack which included an exoskeleton and a custom HUD. It seems NASA liked it, because we are currently Top-5 on Best use of Hardware category. Aaaaaand, of course, we used KSP to simulate it! Here is the video: https://www.youtube.com/watch?v=fwtIp6Wt2hk The official NASA project page: https://2016.spaceappschallenge.org/challenges/tech/jet-set-mars/projects/mars-upv Our website: http://www.marsupv.com/ In our prototype, the helmet included a IMU to sense the orientation of the wearer's head. This information was then sent to KSP via a custom HID USB device the game interpreted as a joystick input. Besides the helmet movement, our prototype had two joysticks which enabled full use of KSP's EVA functionallity (and the prop-pack reacted moving the nozzles and illuminating) Hope you like it! Germán PS: if you want to see more, our github repo is on NASA's website. We are part of http://www.makersupv.com/, a student community on the Universitat Politècnica de València, Spain.

"Kermander1000" ... another KSP kermand console cockpit thingy ! - Some time ago i wanted to build a control console for a farming simulator to drive tractors and combines, but kermanding a rocket is much more fun. While looking through possible solutions on how to extract data from KSP, i found the ready to use solution : KSPSerialIO (thx @zitronen ) This base frame has carried a flightsim cockpit for many years, hope its capable for space action: I have printed some panels with my 3D-printer, soldered some stuff and written some code into a MEGA. I will build some single modules which will be assembled into a console. Some useful and some senseless displays will be available, some switches do work and some will not. Imagine confused and even tough successful Kerbonauts The 'AnalogGauges2', 'StatusIndicator' and 'MasterIndicatorButton' (AG2, SI, MIND) are fully operational and already succeeded in many missions. The 'ActionGroupControl' (AGC) still needs soldering and coding work to be done. See the following pictures for an impression of my dirty workbench and the modules i'm working on : Could be that all those flashing lights could cause unwanted visual restrictions, i will add a 'No Light'-Switch somewhere

Well this thread is inspired by this cute video thumbnail, generic theme and lyrics: Mister Trouble never hangs around When he hears this Mighty sound. "Here I come to save the day" That means that Mighty Mouse is on his way. Yes sir, when there is a wrong to right Mighty Mouse will join the fight. On the sea or on the land, He gets the situation well in hand. rule: pretty simple share stuff about your mouse and eventually comments about yours or others contributors mouse keep things fun and cool. (non mouse users are welcome to because well evolution is like that ; ) 1 - : Mine really start looking like this and this are it's best friends because well getting old is hard even for a computer mouse but who said lifting rocket in ksp is an easy task ? ; )

Hey guys, I'm looking at getting myself a Das Keyboard to replace yet another keyboard that I've abused to death. I'm pretty sure that it will suit me (coder and gamer) but I wanted to get some feedback from someone who actually has one and uses it in anger (or at least under duress). In particular I can't decide if I should go for the Cherry MX brown switches (softer) or the more "clacky" Cherry MX blue. They say that the blue is good for increased typing speeds, but I'm just not sure if I want that much clack! Other Q's I've got. - How easy is it to clean? do they keys come off easily or do you feel like you're forcing a flimsy plastic clip each to you take them off? - Is it as tough as it looks in the pics. Could I defend my office with it?! - something I look for in IO hardware - Any Linux users know if the media keys work out of the box, or if that requires some key-mapping. Thanks!