richfiles

If I have some tape scales cut and printed from 0 through >9999 (for the radar altimeter), and I were to come up with a mechanism to make it work on an Arduino... Is there any interest in that? I spoke to the owner of a shop that makes signs and banners. and they are looking into the feasibility of it. I was thinking of having 10 meter increments from 0-500, maybe do 50 meter increments from 500 to maybe 2000, and from 2000 on up to >9999, do 100 meter increments. That would be 50 units, 30 units and 80 units, respectively. I could also potentially increment by 500 meters near the very top of the scale. If I do that, I can keep the total number of digits displayed below 128, meaning I could also possibly print a 7 bit dot pattern on the back side to optically read the absolute position of the tape. If I do this right, I think I could make a simple mechanism that only requires a few purchased rollers, and a flat plate of metal with holes drilled to make this work. The assembly wouldn't bee hard to make at all, I would think! Making one strip is still gonna cost materials, so maybe I would be able to have several strips made in parallel, and be more economical, price wise. Is that a thing anyone would be interested in? Thoughts?

Bummer Maybe someday...

Guys... Guys... I didn't get a tape meter... I got TWO. I've had them for years, and didn't realize I could mod them, cause they are a short end window type tape meter mechanism. If I machine out the side of the mechanism box, throw a pointer on it, I'll have a scrolling tape meter with absolute encoding of a minimum of 72 positions, and the capacity to loop. The default scale is 0-355 in increments of 5. If I black out some of the large numbers (so 0 goes to an "end" of the meter instead of looping), that's still quite a few digits. The mechanism is wide... maybe 8 inches wide, but it runs through a crown gear. If I cut off the side mounts, and remounted the crown gear facing back instead of up (oriented with the top of the unit facing forward, as per the nature of the mod), then the mechanism would still be wide, but would put all that width deeper into the control panel, and have an offset. I could probably still fit the DSKY panel in front of the mechanism, if I put the tape meter to the left of the DSKY. Maybe. This is all guestimation and speculation at this point. Wow There's a hellish bundle of wires, and I don't wanna damage it. It actually can return an ANALOG output, if you feed it a 400 Hz input, thanks to a resolver emulator transformer. It only has... Enough winding leads to code 72 different winding configurations! That's ONE transformer, with that many winding taps! To mod it, I need to strip out the wiring, but I might actually wanna keep the wiring, as keeping the wiring means being able to read the position with only three analog inputs, vs... a LOT of digital I/O... Probably enough to require a larger Arduino. I did look though, and It seems to skip every other position the very PRIMO multistack rotary switches. If I can actually hit every position, it may be possible to double the number of absolute positions to 144! One point of note, the mechanism really "chunks" between each position. There is a very strong detent on these. Fortunately, I can unscrew the spring, thus removing the hard detents, so I should be able to drive this easily with a motor. Tape Meter Video Alternatively, I could ditch the switches altogether. Direct drive it with a motor, and mount a pair of photointerruptors inside the unit to watch the holes pass by on the tape. I'd get a quadrature encoder doing that. I'd then need to index it at 0, and could move it by counting quadrature counts.

So, I've been playing with the scales for my meters. I've now got official scale templates for both the single and double edgewise meters. I've also done a test fit for permanent mounting (no tape! yay! ) as a proof of concept. It works! I'll probably use some black paint to paint the edges of the backlighting window, to prevent side spill into the meter movement groove. I'll build a simple light box as well, to contain and mount the LEDs. Another idea is to take a tiny meter movement, and gut it out of it's case, and then make a small slot on the right of the single meter with electric charge. I'd like to have a charge/discharge rate meter, but I don't feel I need to waste a full scale meter for it. I just want a short throw inverse logarithmic indicator, with maybe an inch or more (2-3 cm) of throw. Whether I do this at all is entirely dependent on if I can even find a meter that won't interfere with he magnetics of the existing meter. If I can't make that work, i'll skip it. As an alternative, I'll likely buy a small meter and just find a place to squeeze it in. That or I can have a dummy light on the DSKY. Red for drawing power, Green for generating, and off for standby (no power generated or consumed). Maybe I can have a DSKY key toggle the meter function? Still, I think I'd like to get the internal meter concept made. I just like the idea. I'm considering slightly deviating from the Apollo style. I've got grey paint, and will instead of laying polycarbonate panels above the aluminum, I'll lay the polycarb below. Nomenclature will shine through rectangular windows in the panels (I have a nibbler tool that makes great squared off holes). The edge of the cut aluminum will be painted grey, to mask the cuts. Switches can still be recessed. What I'd do is nibble out a large opening for the entire row of switches, let the wickets pop through, and mount the switches to a thicker aluminum plate that will sandwich between the polycarb nomenclature layer and the top laminated aluminum layer. It'll still mimic the recessed Apollo switches, just with the layers in different orders. I might still have an occasional top mounted nomenclature panel, if it's gonna cover a large area, like maybe the action groups switches, etc. It'll still be easier to just drill round holes in the aluminum in that case. I'll have to see how things go. Finally, I've been looking at how to build a basic home made brake press. That, for those who don't know, is a tool for bending metal. Since I'm only bending thin sheets of aluminum, I can get away with one of the super simple wood designs. All it takes is some screws, bolts and some hinges, plus a couple 2x4s. I think I've figured out my geometry for the horizontal control surface, and I'll be using those grey laminated aluminum panels I salvaged from those old 1960s era phase angle volt meters I posted a couple pages back. They are thin enough I can cut them with snips (though I'll likely still saw or dremel them, for the sakes of a clean cut). The right side joystick area will be rather narrow, as it only needs to accommodate the joystick and a couple switches. This leaves me a long strip of material leftover from the panel, that I think may be enough to serve as the drop panel to accommodate the DSKY height. The brake press will be used to bend the sides of the flat panels, and the drop down. I'll bend some thicker aluminum sheet to form the front and top and back panel of the instrument section. That could get tricky, and if my homemade brake press isn't good enough, I'll have to go and get a shop to do it. The bottom of the horizontal control panel will also be bade of thicker aluminum, and I have to think about whether I'm going to possibly do a backfill (cut foam to make room for switches, wire paths, etc), or if I'll have some sort of more solid internal vertical support structure (numerous standoffs, some sort of web of vertical walls, etc). The top panels will definitely need to be solidly supported, though I'll avoid actually screwing through the top surface simply to stabilize it. I want it as smooth as possible, as it is where my hands will rest. I'll only use screws at the edges of controls, switches, etc. Not for simply stabilizing open spaces. If I find myself truly needing to stabilize an open area, then i'll epoxy a thicker aluminum plate or a standoff to the bottom. No pics of new meters, as it's just prettier variations on the same. I'm gonna wait till I have the lot of them done before I post final results (not to mention, I'm gonna wait till I'm printing not he Nekoosa material too). Also... A quick measurement of every component, adding half an inch of space (a little over a cm) between each one, and adding just a little more than half an inch to the borders... nets me a MAIN control panel width of 33.5 inches (85 cm). I'll be honest... That's genuinely pushing the limits of what I can fit in front of my monitors! My center monitor is 21.5 inches wide. With the angle my two side monitors sit, that leaves me with 6 inches of overhang on either side. I'm thinking I may need to suspend my monitors from the upper level of my desk, cause I don't think that width will let the side monitors stands get remotely close enough to work. This means I need to buy three wall mountings for my monitors. I also have 10 inches between my keyboard tray and my monitor's bottom edge. The height of the instrument panel will be 7.5 inches, plus the horizontal control panel thickness. The DSKY is 9 inches tall, and I'll probably need an inch of thickness for the slider pots in the drop down... aka... Wow, I am cutting this CLOSE! The side effect of all of this... Is that I likely do NOT have room for my wide screen CRT, as I show it in my concept sketch. Not all hope is lost though... Since the keyboard tray stops at the edge of the throttle lever, I have all that space under the desk free. In theory, I could have an enclosure mounted under the edge, with an upward angled front face, so the CRTs can be mounted low and to the side. Considering that the Box-o-CRTs™ won't be sitting to the left anymore, I actually have some room... and yeah... My 7 edgewise meters are exactly 12.25 inches in width, and my current overhang is a total of about 12 inches. Since the meters are VERY short (only about 7 inches deep), I can basically make a box with just the meters, and nothing else. I might still make a longer box and put my 3.5 inch color CRT in it, cause I WOULD have room for that! I'd put my ∆V meter to the right of the navball, have the naval, DSKY, and Vertical Velocity meter as my main panel... Yeah, I think that'll be the way to go. That makes the main panel about 21 inches wide... almost exactly the width of my center monitor! Yeah, that's pretty much perfect. As much as I like the idea of the modified electric gen/draw meter mod, it's not easy to fit it inside, despite the space available, and it does screw with the meter's look... It squeezes things. I think I'll take advantage of the small size of the color CRT, and the empty corner it'll leave int he panel for a tiny charge meter. I might even mount the rotary switch on that panel, just since it'll be very nicely visible there.

He means having the seat laying you on your back, either partially or fully, to simulate a launch position... That would be pretty hardcore, but probably not something comfortable for long term play.

I'd say sticking with the first letter similarities is the bigger naming theme to follow, and I don't think you need to use nearly as much of the names to still fit both the naming convention, and make it feel right: Mermes Vete Mares (This works well) Dres (This is already a combo of the two... just shorter. Ceter would have worked too, and still kept the name short) Jeus (The Jeus is leus! This would have been a good alternative)

I never realized the source for the OPM planet names... Nifty! Still, I'm fine with Jool being the "Great Green Jewel Jool" of the Commonwealth Kerbin system.

I am enjoying being creative and trying to pack as much Apolloishness onto my own desk mounted controller as I can... Still, it is truly a shame I can't find the room for something as truly awesome as your simpit! Keep up the awesome work! This is a truly inspiring simpit!

Bummer. I was really hoping whether a node was being edited or not could be exported. Same for the estimated burn time. I think that maybe a delta-V total reset button would be fair. A manual lock for setting the total delta-V to whatever the node delta-V is at at the moment. I'd be fine with a guesstimate function that looks at changes within a short window. If any value goes up, assume editing. If any value goes down... Ehh... That's touch, especially if you're close to the node you just set. Eeewwww! manual stuff! It's okay though, I have a ton of unused keys that need jobs on my DSKY, and it's RIGHT NEXT to where this meter/display hybrid thingy™ will be! Is there something special about the Estimated Burn time, or the game state that defines whether the game is editing a node... Are the so closed off that we have no access to them? Have we not found those variables? I'm just a little curious why we have access to some variables, at the plug-in end, but not others? What is it that defines that cutoff? Sorry! It's my newbishness to programming that leaves me not getting the whys and the hows behind this stuff. Obviously, I know the plugin doesn't transmit those pieces of data, but my curiosity is still there. Is this similar to the reason we don't have the ability to toggle the map or precision mode either?

I don't know about that! I just... multiply the conversation! I wouldn't stop posting here. I'd post the details of construction on my own thread, and finished bits and bobs here. Bob is now panicking - He thinks he's finished! That or screw it. Image dump! Helps when I ACTUALLY hit "Insert other media" instead of "Save"... This is my most up to date concept art for what I propose the finished project will look like. It's a mix of my original whole desk sketch, and my more detailed controller only sketch, updated with rough color, and up to date on the current proposed appearance! Glorious manual art, at its not so finest! Who needs Faux-toshop, when you have a LINE and BUCKET and SELECT tool! Some of my proposed changes are simple. The added height of the DSKY, due to me underestimating the size of the LED displays... Well, I solved that by moving my shelving and desk lighting sliders to the space in front of the DSKY. This allows the keys to be placed much closer to the bottom edge. In addition, I realized that since the lighting slider potentiometers themselves are very low profile parts, and those are now in front of the DSKY, I could thin the horizontal panel in front of the DSKY, so it'd be even lower, allowing the DSKY to drop even further down! The catch? It makes my metal bending geometry WAY more complex. It goes from a relatively simple fold with a cutout, to... well... That. I'll probably have to do the chassis in more pieces than originally intended. I can deal with that. Another thought that occurred to me, Is those Phase Angle Voltmeter panels I found from a few pages back... That aluminum is only 1/16 inch (1.6 mm) thick. While using it structurally isn't feasible, mounting it to a block of wood and drilling out holes for switches might make a reasonably thin front end that can be easily screwed together using wood screws. It'd dampen any give, and make it feel far more solid that way, and I could avoid a LOT of "strange geometry" bends. I can work with smaller pieces and join them all to the wood, not each other.I can cover aluminum seams with my nomenclature panels. Still don't know if polycarbonate or acrylic would be better. Poly is easier to work with, but I also feel like it is a softer material. Will it scratch more easily? I dunno. Acrylic is more prone to cracking, but I think that's because it's generally harder (but more brittle) than polycarbonate. Regarding the toggles... Their number, nor their specific orientation should be even remotely considered final or accurate. They are not to scale, and merely represent "here be toggles". The rotary knob is not finalized either. I am actually considering making the left space a part of the controller surface as well. If I do that, I may place power controls over there, possibly extra action groups. I know one of you guys has more than 10 action groups, thanks to some enhanced or extended action groups mod. Honestly... All switches are TBD. I requested some info on node delta-v on the Arduino software thread, but assuming the packet can provide me the necessary information (or I can figure out a way to get the thing to take a wild crack at the numbers), then there's a new instrument that'll make it's way into the cluster! It's easy to display the remaining delta-v of a maneuver node as a number, but representing it as an analog output requires comparing that value with a known starting, or total value. If I can get that value, then I can do the following: So this is my latest idea. It works the same way a CD/DVD/BluRay carriage moves. There is a smooth steel rod and a threaded steel shaft attached to a stepper motor. The carriage contains a pair of tiny displays (with an integrated driver) that displays the m/s of remaining delta-V to complete a node and the estimated burn time. I have a baker's dozen of these tiny DLG1414 - Alphanumeric 4 Char. Dot Matrix Display modules with an integrated controller. I've got a bunch more of the red versions, and some 8 digit yellow ones... But this is KERBAL Space Program! Green is keen! I would have either a triangular green LED as a pointer, or the top left most display character displaying an arrow, along with a fixed scale, backlit with just un-labeled scale divisions. The device would need to receive total delta-V for the next node, remaining delta-v for the next node, and estimated burn time. I know time to next node is already sent, and remaining node delta-v is also sent. I can probably take total delta-v as the max number that's stable after a couple seconds of that value exceeding 0, or immediately take current delta-v at the moment of any warp. The system would save that total delta-v, and move the carriage to the top of the scale. It would decrement the delta-v scale position, based on the percent of the total that the current delta-v remaining sits at. Total delta-v would be reset when the reported delta-v is returned as 0, and the software would await a new "total" delta-v. The carriage would remain at the bottom, until a new value above 0 m/s was transmitted for the node delta-V value. That's the hard way... I presume. What would be nicer, is if the node total and node remaining delta-v were just simply both sent in the packet. Alternately, a mode locked flag would work too. If a node if unlocked, then delta-v would be known as being adjusted. Once locked, the a carriage would move up, display the remaining delta-V, and move the meter down, comparing the remaining to the total (remaining value at moment node locked flag was sent). This lets a simple single bit toggle make double use of the node delta-v value, and not require an entire new float value to be transmitted. Time to node is already displayed on the DSKY, but I'd like the estimated remaining burn time, when KSP has it calculated, to be displayed on the carriage. The yellow wire is scrap from my old employer. Those cables used to be used on... something... I can't recall exactly what, but the cables are rated for heavy movement in industrial settings, and could handle a carriage moving up and down 6 inches, for the life of the controller. TOTALLY superfluous gadget, but I know HOW to build it, so really... Why would I not build it! It'd be cool! **EDIT** Bummer... There does not appear to be any current way to output the state of whether you are or are not editing a maneuver node. There also does not appear to be easy access to KSP's Estimated Burn variable. At least it sounds like we may not have access to it yet. Not all hope is lost though... Automagically setting the total delta-v to the highest value of "delta-v to next node" and updating it for at least a second after any change ought to get most maneuvers entered. I still have free DSKY buttons though, so i'll have a "∆V SET" key, which will manually set the total delta-V for next node value to the current delta-V for next node, and then set the carriage to the top of the meter (if it's not already there). The problem with auto set, is it can recognize the highest entered amount easily, and with some creative programming, you can even set it to keep updating as long as changes keep occurring within a set period of time. This is... okayish... Problem is, it fails HARD if you set up a maneuver node moments before acting on it. It would assume your immediate burn is merely more adjusting of the total. The result is the meter would count down delta-V on the display, but the carriage would stay at the top, and not count down the scale. When you hit 0, or canceled the maneuver node, the carriage would suddenly move to the bottom all at once. If you interrupted your burn for over a second, then continued, it'd point down the scale from that point. Likewise, if you adjust a maneuver node's delta-v high, and you stop adjusting, to think about it, then start adjusting down (and never back up), it'd not count that as total delta-v, but rather start dropping the meter, as if you had started to burn... The Arduino is blind to what is actually raising or lowering the delta-v... A maneuver node being edited, or an ACTUAL maneuver! It must always guess, and can never know with certainty. A manual ∆V SET button solves this, manually, till we can hopefully, someday gain access to the variables. As for estimated burn time... Same deal. No access to the internal variable that represents it, at the moment. It IS possible to calculate though. Apparently, if you have the right formula, you can figure the thrust, the ships mass, the fuel, and all that fun stuff, and have the Arduino crunch the formula with it's little 8-bit CPU that could, and then you'd have an Arduino local estimated burn time... That is, if you know how to do the formula on the Arduino, in theory, it's possible. The problem is knowing thrust. That's a value that doesn't seem to be there as well... So you get to calculate your thrust too, off of the ship's mass/acceleration, or something. I think the game may do it the same way, maybe. Would explain the need to tap your throttle to get a number to appear after you've staged... It needs to figure out your thrust. Or something... I don't know the first thing about that math formula, much less how to actually do it on an Arduino. I may, if I build it, just duplicate the time to node value on the bottom carriage display (It's also one of the selectable display options in the "Time to:" line of the DSKY), and display the delta-v for next node on the top line of the carriage (this is what will always display there). Setting the total will store the max value read and update the value for an additional 1 second after max value is reached, the value goes down, and it continues to change (any change will reset the 1 second lock out). It should catch most tweaks, and if it doesn't, I can manually force a lock to the current value with a button. Any time the node reads 0, it'll clear the total ∆V value and set it to 0 as well, dropping the carriage to the bottom, if it wasn't already there.

Does Delta V for next node show a live updated value for whatever projected delta-V expenditure a node will need, live as the node updates (as you edit). The reason I ask, is I need to be able to know both the live value (for both setting and burning), as well as the total Node Delta-V to represent a node that is set (not being edited). Is there any way to know that a maneuver node is "set" as opposed to being edited? I mean, I can guesstimate stuff my assuming the Delta V for next node value is assumed set if any warp or thrust factors are triggered, but that only works from a zero acceleration state. If I am burning and setting up a maneuver node as I burn (I realize this isn't very accurate, and that it results in the maneuver node being off till you readjust it again (after you stop burning), but it's certainly a thing that can be done. Also... I'm not sure if I saw an estimated burn time value being transmitted. I'd need that too. What I'm aiming to do is to use a stepper and threaded rod assembly, plus a second smooth rod, to create a sliding carriage. No that carriage, will be a triangular green LED to serve as a pointer, and a green LED display to display delta-V and burn time, on the carriage. The carriage would have an Arduino Pro Mini mounted on the back, and would use a cable I have (LOTS of scrap from my old job) that was meant to carry power to a moving assembly. Long story short, i want to recreate the burn display on the right of the navball in KSP, in actual hardware. To do that, I need: Total delta-v (next node) Remaining delta-v (next node) Estimated Burn Time (Next Node) Is it possible to get these numbers? Thanks! **EDIT** What about a "Node Locked" bit? It wouldn't take very much data in the packet... FAR better than a whole extra float! Basically, Node locked would be low while adjusting a maneuver node, and would ho high when you are no longer adjusting. Whatever value node delta-v is at when Node Locked goes high, is the value to be copied into a Total Node Delta-V variable. Make sense? This makes it super easy to have the Arduino be able to update a percent of X value for displaying via an analog meter (or in my case, a servometric meter) for maneuver node burns. Having the estimated burn time would also be awesome. We could do things like divide the number by 2 in the Arduino and feed it to an event alarm, display it, etc!

I've never seen it. That particular phrase is just an old anime meme. If I recall when when I was young, and the old Full House series was still on, I think the little girl used to say "How rude". No clue if new series used that, or dropped in a "How Lewd". I know Bob Saget's comedy gets pretty raunchy (the dead opposite of his full house character), so I suppose it could have been introduced into the show as a joke, but if so, they did not coin it.

Valentina: "H-how lewd!" Jeb: "Bill, Bob... We're leaving Valentina here and launching TOMORROW!"

So, as a side note to the earlier discussion about using CRTs and small LCDs and such, I thought I'd share this. Dave Jones, over at the EEvblog did a recent video on a Chinese ••variant of the Raspberry Pi called the Orange Pi. They are much cheaper, but more significantly, are actually open source, unlike the Raspberry Pi. Distribution is still quite limited, as they're currently only for sale outside of China via alibaba, but their website is http://www.orangepi.org/ It's recommended that you look to the linux communities to get the OS for it, and not download it from China, as Google will flag the download site as a site that frequently is risky. Instead, get a good and proper linux distro for it. All the Orange Pi variants run an "AllWinner H3", which is a Chinese made ARM Cortex A7 Quad core processor. The Orange Pi One is their version of a RPi Zero. It's not quite as small, but it's $10, and not as rare as •••unicorns. It runs a Quad 1.2 GHz CPU The Orange Pi PC is $15, and is probably the minimum, bare bones model that supports composite video out. It runs a Quad 1.6 GHz CPU There are a variety of models, some bigger, but these are the two small/cheap ones, and seemed suitable for the video stuff being discussed here earlier. if you wanna go all out, some of the larger boards support SATA for storage and offer onboard WiFi and Gigabit Ethernet. Not bad! •• These are not direct clones. They have the same CPU architecture, but to run a Pi OS, you have to specifically build it for the Orange Pi. ••• I wanted a Raspberry Pi Zero, but I suspect unicorns are more common. I'd probably have a far better chance at putting out unicorn bait, and then asking one to "magic" me a Pi Zero into existence, than waiting for a Pi Zero to actually become available to purchase in the traditional manner.

Modded my first Dual Edgewise Meter today! I think this was actually easier than the single edgewise meter. Can't tell if it's cause of the different style, or my experience not he first one. Hope it's the second option! Two down, but still five to go! Still, shame all my meter's aren't dualies! I can't complain though, these things rock! The example above doesn't look quite as nice as my other examples, but that's cause I cut up the paper scales from the single edgewise meter fittings and cobbled this together. Didn't have time to redo the files on the computer to print new scales. (my fault, I had the whole day off, but I only did one meter). It'll still have a horizontal header with text labels at the top, and the scale will obviously be properly printed, but this is how it'll come together. Also, I forgot to put the sides on! Also, it's upside down! I DID manage to find the broken pointer inside my broken unit. Turns out, the pointer is actually HOLLOW! I think it's INCREDIBLY thin aluminum, but it's so TINY. Anyway, i found a component lead just the right thickness to insert into the hole. I soldered it to the brass movement and inserted it into the pointer, with a dab of glue. It physically works, but the weight of a 1 inch resistor lead unbalances the meter, and I can't use ferrous metals on the other side, as they react to the magnets of the meter movement assembly. I'll try copper, as I have some solid strand copper wire. I just need to balance the weight out. Once it's neutral, it'll work again, though the increased mass will mean it will have to overcome more inertia, and move less responsively... Hmm... Uber slow response meter... I KNOW! Xenon! I have plenty more pictures of the build process, but I might decide to save them for when I start a dedicated build thread... Seems maybe I really ought to think about maybe doing that sooner than later. I mean, if people want them here, I'm fine with that too. It certainly keeps this wonderful thread lively with discussion anyway!

Aww geez... I've long considered that I REALLY should start my own thread at some point, but I keep digging myself deeper and deeper here though. I honestly should consider it though. So glad that people appreciate my work though, and thanks for the compliments!

Thanks! I figured it was likely an arbitrary representation, but i've been 99.7% invested in the hardware side, and dreading the software side of my controller project... I barely know a thing about C. Good to know one aspect of the customization looks fairly straight forward. It also made sense to ask. Why reinvent the wheel if someone else already figured out a solution!

I've been slowly building an Arduino based controller to play KSP. The style is themed after the Apollo capsules. I have been looking forward to flying to Sarnus, Urlum, Neidon, and Plock with real instruments for so long! It'll be great when I really can! In the mean time... Keep up the good work! It's so hard to wait so long, cause this build is taking FOREEEEEVER! Just amazing work! Thank you!

Has anyone used the SOI byte for modded games, such as games running Kopernicus, with add ons like Outer Planets Mod, etc? Is there a hard limit to 9 planets per sun and 9 moons per planet with the existing byte (decimal) format? How many suns are permitted? I think OPM also has a moon orbiting another moon, orbiting a planet, orbiting the sun... Is it even POSSIBLE to transmit those SoI locations over the packet in it's current incarnation, or am I missing something in how the packet is set up? OPM is actually my intended reward for when i finish my build, so full capacity to implement OPM is pretty important to me. Can a modded install just bump the sun digit arbitrarily to represent planet/moon counts higher than 9, provided both halves of the software are configured to do this?

I know nothing of programming, but what would be involved in making the old Biodomes and Stanford Torus part pack 1.1.2 compatible, and to optionally tie in to CivPop when installed? I absolutely LOVED the old models for the old biodome and the old torus. I think the last version it worked cleanly in was 0.90, and I think the last update on is was 0.24, but I'm not entirely sure. I really miss it, and like that the parts were still VAB sized. I actually launched the torus once... God, that was some beautiful Kerbodyne tier asparagus staging... 13 stacks of Kerbodyne S3-14400 Tanks, each stacked 3 high! As I understand it, those packs were, I think, released way back, and then work transitioned into CivPop... Or something like that.

So... fair warning, this is still using paper scales, and not even correct ones. This will look even better once I reprint this as a single piece scale on the Nekoosa material, with no seams, and even better translucency! I need to now readjust the dimensions of the scale so I now have a single scale that covers the entire space, with no seams, and I need to slightly reduce the height. Internally, there were a pair of posts that prevented the polycarbonate from reaching the very edges of the housing, but that's fine. It's close enough it'll just work. I will use the zero calibration adjust to move the zero point up a bit, and I'll run the meter at around 90% of it's full range to represent 100% on the scale. (I'll fine tune it once I'm actually building the driver. The driver will take the PWM output of the Arduino, and for the four single edgewise meters, generate a 4-20 mA current loop to drive the meters (I'll probably be driving around 4-18 mA). For the dual edgewise meters and the vertical velocity meter, I'll have the PWM power a MOSFET driver that will generate a 0-10 volt signal (I'll actually generate around 0-9 volts, since I'm not using that top 10% of the range). I will probably run a thin edge of black paint on the inside of the polycarbonate to mask the edges, so I don't get that shine through where the scale meets the housing. I think i'm going to also ditch the left label, as it just down't fit with the Apollo themed meters. NASA left the gap entirely exposed. Other things to do, is to cut a sheet of black plastic or cardstock and make a light box, so the light doesn't shine up through the gap for the meter pointer. First step was to cut out the front face of the meter. I used my hot air rework station to carefully heat the polycarbonate (lexan) till it followed the curve of the old front face properly. I heated the ends and used a ruler to apply sharp bends and to form the ends around those posts. This took a while... Kinda not looking forward to doing this 6 more times! Here's a shot of the formed polycarbonate window. I drilled a hole in each end through the thickest part of the meter. I used a flat head (flush fit) machine screw, since that allows the outer housing to slide back over without interference. To make it flush mount, I had to countersink the hole, for the screw head to sit in. You can see the bottom screw poking up through the polycarbonate at the bottom. And it's screwed on tight! I was gonna use 4 screws, but honestly, it's VERY secure this way. The formed fitting ends do help with that, though. Unlike acrylic (plexiglass), polycarbonate (lexan) flexes nicely. Acrylic would have probably cracked if I tried to tighten a nut down on a curved surface like that. Polycarbonate IS the way to go. I seemed to be able to use 140°C on my hot air station to get the polycarb to flex. Never tested lower. I got some bubbling when I held the heat on it for long periods. This is because polycarbonate is hydroscopic (it can absorb water over time). If you heat treat it before working with it, you "bake" the water out of it, and it doesn't bubble. If you don't, then the water can reach boiling, and form a steam pocket as it expands. This will be behind a diffusing label, so I honestly don't care about a few bubbles at the ends. No bubbles formed in the mild heating involved in creating the curve. And here are the authentic meters, for comparison. They made the scales in different ways, between the Command Module and Lunar Module. I think I'm pretty much as close as I'm gonna ever get, with this setup! All that remains for this one to be 100% complete, is a proper scale design, fitted to the new configuration, and finally printing the scales on the Nekoosa material. Now to do it 6 more times!

Came up with Yet Another Unbuilt Idea™ Be aware that this started as a sketch to see if I could use this particular part for this idea... Sadly, the part is WAY too small, but if one were to find a larger part, it's ENTIRELY feasible! Since this part turned out to be too tiny, I just sorta... start letting my mind wander into other idea possibilities. I pretty much ramble on about several different ways to make flag indicators. All of them are possible, most of them require some fairly intricate modding. If you're going for an authentic Retro look, this is certainly a reasonable idea. This uses those tiny sub-miniature edgewise analog meters you see in old battery operated devices back in the day as a stand in for an Apollo style "Three State Flag Indicator". By pasting a black and white stripe pattern and a red mark on the meter's scale, and by pasting a grey (or whatever color your panel is... the idea is to match the panel color) mask to the pointer, you can recreate the three state flag indicators that were used extensively in the Apollo program. By driving the meter at 0%, 50%, or 100% power, you get three possible outputs. When no power is applied (either due to power being shut off, or all signals set low), you get the red marker showing. If you apply 50% signal tot he meter, the mask covers both the red and the striped areas, showing only the panel color. This is considered to be the "inactive" state. You could consider this to be an "active off". You must still apply 50% power to set this state. The final state is "active". This is basically considered to be fully "on", and requires the meter to be driven at 100%. This is also close to how the Apollo flag indicators actually worked. They would likely have used separate solenoids for the two powered states, and the striped pattern appeared to be the background (and backlit, based on some images I've seen). Certain flags may have had different configurations. Either way, it's a general proof of concept on how these flags worked. With a bigger meter, you could have one state be part of the background (pasted to the scales), and have two full sized states painted on a mobile mask with a full sized window. I honestly would love to use some of these for my toggle switches. What I REALLY want to do is have the controller read the state of all action groups and toggleable states (RCS, SAS, etc) and display those states on the flag indicators, as opposed to displaying based on the physical switch state. The trick then, is if KSP sends a state to the controller, and it does not match the physical toggle state, then it should set the fault state (0% power to the meter) to indicate a fault, and interrupt the controller from sending thew switch state until the switch is manually toggled to match the in game state being reported (at which point it will show the active or inactive states, based on what KSP reports). When a switch is toggled, the change of state (locally) should send the new state to KSP. If it is necessary, there can be some logic to skip the fault detection routine until KSP returns the same state as the recently toggled switch. What that means, if it can be made to work, is you can have toggle switches, and you would be able to change between vessels without your inputs getting involuntarily swapped between said vessels. An easier method (to program) would simply lock toggle controls on detection of a fault. Mismatched controls would go to the fault flag. You would update the toggles to the state you want, and then press a Master Alarm button to reset the fault alarm. That would trigger an update toggle routine that would then resume sending out the current toggle state. After that, It would continue to compare what KSP sends to the controller with the toggle states, set the flag indicators, and update KSP based on toggle changes. The meters I used in this photo... are unfortunately, disturbingly small. The seller says the fronts are 1.2 x 1.3 cm! YIKES... Unfortunately, that means the viewable window is absolutely tiny (looks like it'd only be about 5mm2 with a meter this small. At least the pics still worked fine as an example. There ARE bigger meters, available. One Soviet style meter I saw looked very suitable. Ideally, you want a 1 cm / 0.5 inch tall window, but you'd want it to be at least 2-4 cm / 1.5 inch long. Those meters seem to be hard to come by at larger quantities, and the prices seem higher, unfortunately. An alternate method would be to use a traditional panel meter. Rather than cutting a square mask to attach to the pointer, you attach an arc shaped mask to a traditional shaped meter's pointer. You can get standard meters in 0-5 volt range with a 45x45 mm case. That's still quite big (9 mm spacing between flag indicators... yikes!), but it could be useful for doing a few real cheap ones. Likewise, since most of the meter is a plastic housing, you might be able to use a dremel to hack off parts of the case, to narrow it down. We're talking extreme efforts here, though. The ONLY benefit to this method, is the cost and availability factor. Size and availability of the meter (and price... always price) seems to be the big factors in the feasibility of this. If you CAN find the right size meter, at the right quantity, for the right price, then it's a potentially great idea. Problem, is I've only ever seen a single large lot of ideally sized meters appear at a reasonable price ONCE in the time I've been working on this project... And I passed them up. The meters since then have all been either too small, too big, too few, or WAY too expensive. Surplus is the ONLY viable option, as new ones can be found, but at ridiculous prices. Interestingly enough... One of the cheaper methods I've found may actually be micro stepper motors. Some types you can buy 10 for under $4 shipped! Attaching a printed wheel to the shaft with the three flag status patterns ought to be super simple... The catch is that a micro stepper uses 4 wires to drive, and don't have position feedback. You need a controller, and an external means of feedback to make it work. You can index the wheel by having an optical sensor to index it, but it is an extra part to deal with. Looks like the EasyDriver Stepper Motor board can be found on eBay for around $2 a board... You'll need a board for EACH stepper though! If you had the standard 15 toggles, then you could do it with 15 micro steppers, 15 EasyDriver PCBs, and either 15 or 30 optical sensors (depends on if you are doing home position indexing or absolute position encoding. There's also the mechanical assembly. You'd have to attach the flag indicator wheel to the stepper shaft, and then have a way to mount the stepper and optical sensors securely. It's an incredible amount of "fiddley" work, but it seems to potentially be the cheapest option for a 3 state flag indicator though. Unfortunately, that's the problem... NONE of these methods come without you being saddled with some intensively intricate labor on very small and numerous parts! The simplest, and EASIEST way of doing flag indicators is still to go with flip-dots. Buying a flip-dot matrix is the cheapest method, and the parts are simple to work with, and ALREADY MADE! Of course, the catch is they don't have a three state output. They are only 2 state devices. For all the yammering I'm doing here, the easiest method will STILL be to just buy some darned flip-dots, and have a separate fault LED to illuminate it. The three state option CAN be mimicked by painting white stripes to the black side, painting the other side a light grey (or whatever matches your case), and then have a red LED aimed into the gap where the flip dot window is. An LED should light up the window red, and give you your elusive third state. Last time I got a quote (in March), they cost about $90 USD for a 7x7 matrix, or about $45 USD for a pair of 1x7 boards. So, for $45, you could do 14 flag indicators, and half that will get you 7. It's about $3.21 per indicator for the lower quantity, and about $1.83 if you get the larger grid. Those quotes are old, but probably still close. I'm still pretty set on the flip dots, but ultimately I had seriously considered the other options as possible alternatives, before making that decision absolutely... There's simply not enough time in the day to screw around with this stuff! As elaborate as all these ideas are, sometimes K.I.S.S. is the best policy... Of course, theres also the SUPER DOOPER easiest method... Just use LEDs!

Went to grab my dremel to cut light windows for the backlighting... Spent around half an hour looking. MFW I remembered lending it to a friend to make a new jig for his knife sharpener... And I realized this while he just left for a 2 day rock/metal concert-festival event. No dremel for me! ╱)⤳⁔⤺(╲ Sadly, I've also missed my free time window. I'm working afternoons, after my main job this week, and I work the weekend. I may or may not have Thursday afternoon free to work on this, but I don't get another full day off till Monday! I think what I'm gonna do is gut the entire front face of the meter, and replace it with a (One? a pair of?) polycarbonate (lexan) sheets. I can use my hot air rework station to heat it enough to bend the ends so I can fold it over enough to put screws into it to secure it. This will let me greatly simplify the scales. I'll still need a lower scale and an upper scale, but the upper will be narrow, and meant to just cover the gap the pointer passes through. This mod will make it look even more Apollo like, if I can do it right. I can even secure the scales (which will be printed on the Nekoosa synthetic paper) with the screws, by binding the ends of the scales between the polycarbonate and the meter housing. I think... I have to take some risks to do this. I will pretty much have to gut the entire front of the meter, but it also means lighting will be SUPER easy. Just set an LED or two behind the polycarbonate, far enough from the front to allow for uniform lighting. The plastic is all black. The scales are the grey layers, and the blue is the polycarbonate. The image on the left is the stock meter configuration, and the pointer fits the gap between the two scales. Originally, the scales were aluminum, and the gap between the two scales was black. The upper scale is suspended only by it's ends. The two images on the right show what I'd do with the polycarbonate. They would follow the curve of the meter, obviously. I show two options for doing this. The right most one is actually looking pretty tempting. I might abandon the upper layer all together, and just have no label on that section at all. I think I can make that look the most Apollo-ish, as it appears the Apollo meters did not shield the slot that the pointer protrudes from. That would actually make the horizontal "header" legend text very easy, as I can make the polycarbonate protrude all the way to the left at the very top (an inverted "L" shape)... The pointer will not pass that region. I can electrically drive the meter between 0 and around 90-95%, so that the pointer is maxed just below that top header. That'll also keep the pointer from slamming into the polycarbonate piece. The big deal is being able to form the polycarbonate. I might use the cut out segment of the meter as a jig (or even just a model to make a jig) to lightly heat the polycarbonate and bend it to the correct arc. I just need a couple tabs on the ends that I can heat further and bend vertically, so they can be drilled and used as mounts to screw it securely. The scales will extend here too, and that is how I will secure the scales. Mind you, this assembly then slides into another assembly that basically serves as the outer enclosure and front window. I like this idea a lot... It's just freaky to literally cut out the entire front of a meter you spent $20 on, and that normally goes for $80...

The fishing game is a mod, not an easter egg. (but it WAS used as an April Fools joke). I'd be equally supportive of a Kerbal Classic package... Basically, a collection of classic versions of KSP from the earliest up to the beta. Sell it for cheap... If .25 and .90 are "too modern" for a cheap classic pack, hold off on adding those till some KSP 1.? is released, where there is more of a difference in capabilities. Otherwise, there could be tiers. $5 could get you Kerbal Vintage (up to .18 or so), and maybe $10 or $15 could get you Kerbal Classic (Kerbal Vintage, plus the newer versions, up to 0.90)? It'd make it possible to earn Squad some extra cash, and get around Steam limitations. Maybe they could even arrange a discount for existing Kerbal owners? Either way, it lets both them and Steam offer old content for sale as a new inventory item. Each version (or at least each significant revision) would be the most up to date build of it's particular release, unless a particular older build is more famed, and each would be treated as it's own separate download, with the game folder including the version number to differentiate versions. Shame Steam can't consolidate hours across multiple versions of the same game, as this type of release would treat each game as a separate version. Just thinking out loud... I'd certainly pay $10-15 for every pre-release version, and $5 for the really old versions.

Here's to hoping someone can compile a version of this to run on Macs! This looks INCREDIBLY useful!