Freshmeat

Now I am just being troublesome, but I compared my calculated orbital periods with the GPP wiki and github/CelestialBodies.pdf and found some discrepancies. First of all, Nero is listed as having a period 0f 86y328d in the dossier. This is a typo, it should be 86y339d. A bit more worrisome is Otho. It has its SMA listed as 72718700 km, but the config file reads 71718700000, leading to a shorter orbital period as well (4948d vs 5052d), and an SOI of 1,701,552 km instead of 1,725,278 km. While this probably is a typo in the config, correcting it would be save breaking(?). I do not know whether the original distance had some significance, and going through the file history, it has always been so. I have not checked all other dossiers, as I hope to get at least some surprises during play through. CelestialBodies.pdf seems in correspondence with the config file apart from Otho. If you are preparing an update, you might want to update this. As the raw dossier images and kspedia files are not on github, I am afraid I cannot do more to help.

I have mulled this one over a bit before chiming in, but I do not think it would be worth developer time implementing, and we all got to prioritize. Most of the time you are going to add a new payload anyway, or just a slight tweak, necessitating going into VAB anyway. But in the end it is your time and your mod we are discussing, I am just a happy user.

Thanks a lot, this will sort it out shortly. I knew GM, but the SOI calculation is new to me. /me heads for the spreadsheet.

A maybe troublesome request: I am updating the software on my control panel and spreadsheet, and I would like to include the possibility of flying GPP. This means that I need the parameters of each body to encode. Looking through the GPP/GPP_planets cfg files, I can gather some, but not all. Most importantly, I miss the gravitational parameter and SOI radius of the bodies. I could calculate the gravitational parameter from geeASL, but two digit precision is on the low end. Do they inherit missing parameters from their template body, or can I look them up elsewhere, or get a data dump from the Gods of Creation? I must admit I do not feel inclined to do it experimentally.

Check out Pathfinder by Angel-125. Complex, but very powerful. I made a self sufficient base on Vall using it.

@garithmar: Thanks a bunch, you just saved me a ton of work.

I used it as a lifting engine for an intermediate class booster, in tandem with 6-8 Kickbacks. A lot cheaper than Mammoth, bigger payload than Twin Boar + Kickbacks. Also used it a few times for sustainer on really big builds, but I can usually downscale to a lighter or cheaper engine. This was before MH, so there might be better alternatives now.

This might be the time to add that I really appreciate NF construction as the base for most of my interplanetaries. I am a sucker for those trusses, and the texture getting a pass would be awesome.

As just around everybody else I have been following this in extreme anticipation. Thanks to the entire team for your effort.

I will raise the robotic arm of M.O.L.E. by Angel-125 as an answer. As it is a single unit, it does not summon the Kraken so eagerly as Infernal Robotics. I used it for station building a while ago, together with Konstruction weldable ports.

This is a difficult question, so I'd rather answer with the draft I like the most: This is the only screenshot I have of my Raven Vb LKO booster KSP version 1.3 something. It has flown dozens of missions during my most active career, and is probably my most used type of booster ever. It carries 20 t to LKO with a bit of fuel and a 1000 dv transfer stage, enough for my typical Mun or Minmus missions. It was useful even for sending unmanned probes on interplanetary missions. While not the most efficient in terms of cost/payload, it flies extremely stable and with good margins for error.

Hey, glad to see you are getting started. Looking forward to see what you come up with.

Nice work. I have the numbers in my spreadsheet, but never thought that Excel could be coerced to make meaningful plots of them.

Thanks for the kind words. I have given much thought on how to letter the surface, but in the end I have settled on printing on overhead and gluing the print to the panel. I considered letraset, but given my motor skills I was afraid that I would mess up the spacing and alignment. If you look closely you can see lettering around the rotary selectors, but the problem is that I am restricted to dark colors. So I tried to ensure that as little lettering as possible was necessary in the build. As for the code, feel free to ask questions, I am not exactly generous with comments nor consistent with variable names. Be aware that two plugins require an extra serial port, but I find it worth it.

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.

I am looking for a way to generate a list of parts that have no docking ports above them in the tree hierarchy. My guess is that it will be some form of recursion function, but my python skills are rudimentary. The motivation is to activate solar panels and cargo bays on my SSTO only, not the payload (that is conveniently separated from the vessel by docking ports). Can anyone help me out on this?

Looking over the answers, two things begin to dawn on me: 1) People build larger landers than I do, and travel more outside the Kerbin SOI. I should get more to other planets where I need that kind of power. 2) People build smaller interplanetary craft, so the very high mass of Nervs make them a less appealing choice. I ought to run more numbers when I build interplanetary to see if the Poodle is competitive. 3) I am not the only one who is a bit uneasy about the Wolfhound. The only non stock engine I use is NecroBones' three-Nervs-in-one-part, as I feel many mod engines might be badly balanced.

It is all about where you are in the game. I drop everything that is not needed on the ascent stage in exploration phase. It has been a while, but I seem to recall that it allowed me to drop engines as well and ascent on a single Spark, while three was necessary to ensure a reasonable deceleration on descent. If it is SSTO, it gets re-designated as a ferry. Then I would ferry crew from surface to transmunar shuttles, that would again rendezvous with SSTO's from Kerbin surface for a complete trip. I have yet to move out of the exploratory phase for planets, so there I use expendable landers.

The suggested 2.5m CSM modules are actually just what I am speaking of, because we all have build a craft like that. When I run the numbers, the Terrier comes out with a higher total dV due to its light weight, even when I haul a LEM. And 60 kN is abundant trust to handle every orbital maneuver I could dream of executing in a visit-a-moon scenario. The ISRU lander could very well be the actual case for which I would use it, but I tend to have the drills and converters in installations, or on much larger autonomous refuelling tankers.

With the new KSP loading, the Poodle suddenly became a hot topic, due to the redesign. This led me to wonder a bit on the actual use of the Poodle. When I design rockets, I almost never come up with a design where I would prefer the Poodle over the Terrier, which get a lot of use due to its light weight. If I need more power, I usually need so much more that I go for a Skipper. So it seems like I am missing something, please show or explain actual craft specs where you looked at the Poodle and thought: This is perfect.

Our schools just expect our kids to show up with a laptop. And the average lifetime of those laptops has turned out to be ~2 years, due to the amount of abuse they suffer at the hands of 11-year old kids........

MOLE comes with the most beautiful station arm that folds up nicely into a MK3 cargo bay with room to spare for an orange. Maybe that can be used?

@ohMorrissey Yes, like that. Only I used milis() instead to get a realtime delay.

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.