Freshmeat

First of all, it is a sick setup you have. Very cool looking, and from the looks of it highly functional. Second, when I had dropouts, I had some more demanding tasks only run once or twice per second. It is quite sufficient to know for instance your fuel level to that timescale. And as zitronen said, increase your buffer. A Mega has a ton of ram compared to an Uno.

Advanced Fly-By-Wire, another rebirth from linuxgurugamer. I swear that man does not sleep at all.

Unfortunately, KSPSerialIO is a non configurable communications plugin on the KSP side, so you cannot plug anything into it and get it to work unless you can program it on microcontroller level. Back in the day I connected a wiimote to my PC though PPJoy, which seems to have evolved into vJoy. You might be able to get KSP to recognize your side panel that way.

My Eve descent/ascent vehicle looked like this: Sorry for the poor lightning, but I seem to have no other images. The lower stage fires to enter the atmosphere, and then discards. The real trick is the six wings shielded with large heat shields in the top, and an inflatable one in the bottom. Still goes for a rocky ride, but all tanks are empty to maximize drag/mass. The upper stabilizers are jettisoned after the parachutes engage, so they are clear from the landing site. Additional one way landers provide base camp and ISRU for filling up the tanks for return to orbit. Designed for four kerbals with life support for five days and absolutely no room to spare; the mission parameters stipulated immediate pickup by an orbital shuttle to return to the interplanetary transport craft.

Grats on getting the thread featured in daily Kerbal. Out of curiosity, what sets of information have you chosen for orbital parameters?

Ouch. Still, I'd love to have a front plate like that.

That is an impressive panel. How did you make the front plate?

Man, I have at least two (My controller has a keyboard chip for the functions I cannot get through KSPSerialIO), my standard keyboard, and at times my foot switches for controlling DayZ.

How did you make it? It looks very professional. @Lo Var Lachland I do not see the problem? Of course an "e" pressed on any keyboard is an "e", but on above keyboard you can find it very quickly. Unless you only can have one keyboard at a time on a Mac?

I have gotten most of my knowledge from these very forums, but a few video tutorials has been nice to watch as well. I like static images and text more than video, and learn more easily that way. Further, very shortly after I got the game, I took up my Introduction to Mechanics and reread the section on movement in a gravitational field, and a page from a high school textbook on Hohmann transfers, and another on the rocket equation. This helped me a lot in understanding why the advice I got elsewhere later on was right. If I should do it all again, I would probably have started at @OhioBob's excellent website on the subject.

I am so very grateful for the three of you to release this. Looking forward to download once I get my KSP back up and running.

So, do you have documentation for this. I am in the process of rebuilding and would like to consider all alternatives.

Thanks a lot. I am very impressed by the work you have done, and can do most of the basic stuff with kRPC already. Looking forward to go ahead with advanced stuff.

@razark

No pictures to show for it, but I mounted switches and selectors, and wrote the corresponding code. Fun quirk: If I update to fast, the LEDs start to flicker. Solved by a short delay in the test code, and once the actual code is written it will not be a problem. I made two power pins beside pin 7 and 8 on the perfboard, so I could use one of them for the abort switch (big round hole lower right atm), but it seems I managed to short out pin 7 while doing so. Well, for now I do not need that pin, but I ought to lift the pefboard and check it.

Asgaard Aeronautics: Guess what my favorite toy was when I was a child.

Today I mounted the status lights for the toggle groups. I use a WS2811 programmable LED strip for the lights, so I can switch between red and green. This registers faster than the position of a toggle, particularly in low light conditions. Below is a running light demo to check if it works: I printed the writing mirrored on a transparency sheet, and attached food wrapper paper below it to get a get a grey diffuse background. Below that is a 3d printed mounting that sets the LEDs a centimeter behind the surface to get a more even light. I also mounted a keypad I made sometime during the winter. I will need to print a grid for the keys as they are very wobbly, but it will do. It is just hooked up directly to the Arduino using the keypad library: I have several spaces left in the keypad as some functions where relegated to toggles and selectors, but I will probably find a use for them eventually. Next up is mounting the toggle switches and rotary selectors, and making connectors to the controller board I made.

Yes, here we blow again! My mark II suffered a slight accident early this summer. It was somewhat falling apart already, but I had too much fun playing to really wanting to tear everything up. Well, at least it is summer holidays, the economy says no going anywhere, and I have hoarded new components since late 2016. I bought a Due to have some heavy muscle for autopilot functions, and given that the Mega still smells burned it is probably not a good idea to rely on it. However, it turns out that python is actually doable, and I can create a structure with kRPC very much like what I am used to in KSPSerialIO. And kRPC gives several new options, including a some of those I usually have programmed an action group for. So the plan is to make the enclosure and wire it up as fast as time and lazyness permits, get the basics going, and then gradually add more advanced functionality once it is going. To save some time, the form factor is going to be the same as mk II, but this time I had an aluminum sheet lying around to use as cover plate. Further, I have spend quite some time rearranging the layout so the joysticks will be closer and all information will be displayed in the middle, with LCD displays top middle and gauges for fuel, charge, altitude and monoprop just below. I can reuse the joystick and translation assembly from mark II, but annunciator and toggle status panel will be build with WS2811 addressable LED strips instead of MAX7219 and dual colored LED, saving a ton of wiring. The toggles will be fed directly into CD4021 shift in registers on above perfboard instead of multiplexing them. It took some three days to get all the soldering done. Testing it, I got absolute garbage, quite disheartening - even more so since all connections had been tested as they were soldered. It turned out that I had just ordered a new couple of 4021s to replace the ones I used in mk II, as I was afraid they had been damaged. These two new ICs where nearest the Arduino, and where malfunctioning. Since shift registers shift all data through them, they garbled input from the outer registers as well. But once they where replaced, things looked up, apart from me forgetting to pull down pin 7 and 8 on the last register, as I do not connect anything to them. They are just left connected to the header column 15 bottom, which of course will read anything when left for themselves. The headers at columns 5-6, 7 and 15-16 are to be connected to rotary selectors for SAS mode, camera mode, and panel mode. The mess beside them are digital to binary encoding, saving me some 10 inputs. So next up is to solder those last two 20k resistors and find a route for a wire to ground (black, running along row Q). Then repairing the 6 lead wire I need to connect this to a perfboard yet to be designed, managing connection to the Due. And then installing the LED strip and 20 toggle switches, and their connectors to this perfboard.

I think you've hit the lightning really dead on this time. Impressive work. Looks not-photoshopped.

This one will save more grievance than any other part of the patch, I guess.

I seem to recall there was a mod that allowed for screenshots in higher resolutions. Try to browse the add on library post and see if you can find something.

These days I have a stock SSTO spaceplane that carries 36t to LKO. I use it because it is a fun way to launch, and I try to build a space station by modules. It takes longer to launch than an expendable rocket, and is only slightly cheaper, so if playtime is limited it is not a recommendable route. That being said, I spend as much time setting up a rendezvous and docking, and that time is independent of vessel. And it gives me a huge satisfaction to take off against the rising sun in full eye candy:

You change inclination by burning in normal direction at ascending node or anti-normal at descending node (or is it the other way around? Tired and cannot play KSP atm). They are the ones marked AN and DN in map view.

@naru1305 You can get the directions without digging in the KSP API by using kRPC. That will however entail writing your own client in python. I am slowly getting my own toes wet in that particular can of worms, but I foresee several weeks of work before I get beyond simple attitude control.

@Scorch93 The reason why it changes is that you SASPin<Up,Down>Check are defined inside controls(). It means they get redefined at every loop. You need to declare them as static in their declaration. In Demo16, zitronen has included the functions to separate the first and last bits, call setSASMode with your desired mode, it resides in output.ino. @naru1305 You want to talk to @stibbons, he did a software navball implementation. And @richfiles has been working on a hardware navball for quite a while, I seem to recall a discussion in the Custom Hardware thread as well, but I think @Pvt. KASA had to abandon it for some reason?