richfiles

That's the thing... the "cracking" WAS DONE LEGALLY... That's the whole point of clean reverse engineering. A license and law are not one and the same. It's not illegal to reverse engineer something. It might be against the license to do so. That's where a clean reverse engineering effort comes into the picture. One team reverse engineers the game. Sure that violates the license, but no code is created. Since they created no code, there's no software in violation of the license. All they do is document the overall operations of the code... Not actual code, just what the code does. The second team takes that documentation and then writes NEW and ORIGINAL code, having never, ever actually seen the original GTA code before. By following the behavior documentation, they create an original LEGAL work that just so happens to be (mostly) compatible with the targeted software, and they have never looked at the target software's code. This is how reverse engineering works. Reverse engineering is legal! Even the team that created OpenIV said it themselves... They could have taken this to court to prove their case against Take-Two, and probably could have even won the case under fair use... They documented their reverse engineering process, and could prove in a court that their software was legit reverse engineered, and is not a derivative of licensed code, thus immune from Take_Two's C&D. They could have done that... IF they had the time and money to do it, and were willing to deal with the abysmal stress of it. Unfortunately, it's not worth the hell that the would go through by going to court against a giant company for them to fight it. They didn't give up cause they were wrong. They didn't give up because their software is illegal (it is NOT illegal) They gave up, cause fighting is hard, expensive, time consuming, and stressful. Take-Two are a bunch of two-faced liars when they claim OpenIV is illegal. They. Are. Lying. To. You! Their EULA is not law, and reverse engineering is legal. Don't be sheeple, people! As to the claim that going after the modding tool "makes sense"... Look at GTA V's rating on Steam right now... Take-Two vilified themselves. They WILL lose customers over this. People will stop buying Shark Cards over this... They won't lose everyone, no... But they lost a great deal of respect, and exchanged it with utter hatred and contempt. There are safe harbor laws... You don't go after an ISP for hosting a piracy website... You take down the website. Going after OpenIV is like going after the ISP cause there's a piracy site on it. What Take-Two did was morally bankrupt. It will hurt them in the long run, if they fail to fix this. OpenIV was never the problem. Taking down OpenIV didn't stop the online MP hacking (cause it has nothing to do with the online MP hacking), and they killed their own SP community because they are greedy $#!+$ that WANT Single Player to die down, and force people onto the more financially lucrative Multiplayer online mode, to be microtransactioned to death. You don't go after the ISP cause there's a piracy website hosted by it. You go after the site, not the ISP. You don't go after the modding tool, when a handful of mods enables monetized content. You go after the mods, not the tool. As long as Rockstar uses Take-Two as a publisher, Rockstar will never see another purchase from me again. I won't be paying jack$#!+ for any KSP DLC either. I REFUSE to support Take-Two in any way. They can burn for all I care.

If they show the work of legit reverse engineering it, they have every right to delve that deep in the code... The C&D should have gone out to individual mods/modders that openly cause problems or violate/access monetized content, not the tool. It's like sending a C&D to Microsoft to stop distributing office, cause someone plagiarized a book, or C&Ding the organization that distributes the Arduino IDE software, cause someone used an Arduino to jailbreak a console, or some such nonsense. Unless you own a genuine IBM PC, you're using reverse engineered technology... The process is well defined, and is 100% permissible in a court of law as a valid way to recreate a competitor's product, or derive a means to interface with it. This is how the PC clone market came about. It's most definitely not illegal in any way. That's why going after the tool is a bad move. They should have gone after the individual mods unlocking their monetized content. That would likely fall into the realm of piracy. From a business standpoint... Take Two may have shot themselves in the foot... GTA is a juggernaut that refuses to die down... It certainly won't just drop out of the sales rankings overnight, but this might be the first nail in that coffin. The start of a drawn out decline. Killing new and creative content in single player means single player is now officially all played out... There's literally nothing new to keep interest. That leaves only the cash grab that is GTA Online (and Shark Cards), and I suspect that will diminish over time too. As people who come in for the enjoyment of mods stop coming back to the game, and new people who might have considered getting GTA V for the mods decide to abandon it, that's that many fewer people that might have selected online instead of offline. I don't know... I can't predict what will happen. I just know I'm not giving Take-Two anymore of MY money... That INCLUDES paid DLC for KSP.

No. You are wrong. The software did not "pirate" anything. It was reverse engineered. If you think reverse engineering is wrong, then you had BETTER only buy your PC from IBM, cause EVERY non IBM PC was derived thanks to reverse engineering the original IBM PC. Courts have been slowly leaning toward EULAs not being binding contracts in recent years, particularly if you didn't agree to the terms BEFORE buying (this varies per jurisdiction). Even the creators of the mod stated that if they wanted to fight this, they Might be able to fend off Take-Two... But it could be months or years in court, and be very expensive and stressful, so they are caving to the demands for their own sanity and finances. That's the nature of the court systems. You don't need to be int he right... You only need to be rich enough to bleed the opponent into financial ruin. Rarely do cases actually GO to judgement... They are usually settled, which means the two parties come to an agreement outside of a court judgement. Understand what you are talking about before putting your foot in your mouth. Piracy would be distributing or acquiring the game without paying Take-Two and Rockstar for it. This is a modding tool. It implements the means to install and create mods for GTA. It doesn't pirate GTA. If a person creates a mod that pirates other content, that's not the mod tool's fault, it's the creator of the individual mod, which is a wholly separate thing from the mod TOOLS. Even the mods that were supposed to import GTA IV into GTA V REQUIRED you possess BOTH GTA V and IV, and simply loads GTA IV's data into V. A creative mod indeed, but it still requires you buy both games... And that is still not the Mod Tool... It's like blaming Microsoft Office for someone plagiarizing a book with it. The argument is simultaneously absurd and invalid.

For the first time in a long time, I find myself entirely apathetic to when Red Dead 2 comes out... I just no longer care... I was mortified that Take-Two bought KSP... I was mortified then, and even more so now...

But they are Jeb's Junkyard's "Rocket band-aids"... (they're just salvaged struts from vessels that either had too many boosters, or too few struts... thus ending up in Jeb's Junkyard).

I'm desperately wondering when the wheel bugs will be fixed. I will repeat this here... Auto strutting wheels to the rest of the vessel isn't a long term solution, as it breaks certain designs, such as my Gilly Vanilli rover, and I think Infernal Robotics vessels that have things like deployable wheeled vessels carried by other larger wheeled vessels... Since Gilly Vanilli was to be my circumnavigation vessel, and the update that forced wheels auto-strut was introduced right when I started my journey... Well, I still haven't finished my journey. My ONLY options are to stick with an out of date version, with fewer features. Wheels need to be fixed, and not with literal band-aids! I've refused to update, as I don't want to break my game or my save... Can anyone tell me if wheels are still bound by a forced auto-strut?

Yeah... it was HORRENDOUS!!! More than half the modules developed defects. Those are all supposed to be solid "8.8.8.8.8.8.8.8." As for the panels, my mill is too small. I'd like to see if I can get some mill time at my boss's machine shop. I'd screw the panel down to a chunk of wood, just to give it a secure backing surface to mount it by, and I'd mill out the openings... If I can't do that, it'll be me with a Dremel, a hack saw, and a file. Here's the newly built one, with LED displays NOT sourced from shady Chinese ebay sellers... There last one was dim cause it was set to a different intensity.

There are days when I wish the server farms of YouTube/Google had necks I could physically wring, just for this reason! Freakin' wacko nutters! Too bad I can't do that, cause Google doesn't have people running things, and is clearly the real Skynet. Stop sending me their conspiracy cancer, and let me bask in the space program's spacey goodness! Gotta love these Kerbal controller projects... Time, money, and always yet another twenty things to do yet... I'm still blown away by the +50% failure rate of the green LED displays I got off ebay for the DSKY in my Kerbal Instrument Panel! Still a little miffed, and that was 2015!!! Between modding meters, trying to arrange having the tape meter printed by a screen printing shop, still having another diode ROM to assemble for the last general purpose DSKY readout, still not having any of the metal panels cut for the meters, displays, toggles, joysticks, etc to mount into... And most of all... STILL understanding C programming as clearly as mud... Yeah, this project moves like rush hour traffic! Stop and go... I make a bunch of progress on some random day of the week, then find when I actually have that long three day weekend, I sleep halfway into the afternoon all three days, sleeping through several alarms on my phone... I'm telling' ya! My subconscious knows what days I don't work! The thing that really got me this past week though... I spent the better part of a week looking up how to build a one transistor LED driver to go between the 74HC154 decoder chip (which has active low logic outputs) and the inputs of my diode ROMs, which power the cathode of the LED segment displays... I need to output a negative voltage to drive a negative voltage at a higher current, and most transistor amplifiers are inverting... negative in becomes positive out, and vice versa. I wanted to avoid doubling my part count with a 2 transistor amplifier, so I looked into MOSFETs instead of Bipolar Junction Transistors... Turns out there's plenty of small MOSFETS perfect for a non-inverting amplifier... And I ordered the wrong one... D'oh!!! Aaaaand... The DSKY is waiting on parts... agaaaain...

http://hackaday.com/2017/05/30/microchips-pic32mz-da-the-microcontroller-with-a-gpu/ Just saw over at Hackaday, that Microchip has released a microcontroller with a 2D GPU and 32K of RAM to make enough room for graphics. For the various navball and custom display projects... This seems extraordinarily promising!

It's been a long time since I looked at it... Might just be a power supply issue. It uses ECL chips (Emitter Coupled Logic) rather than the typical TTL or CMOS versions, as ECL comprised some of the fastest chip speeds until CMOS overtook it int he early 1990s. Problem is, it's kinda power hungry, so it has a big beefy 400 or 500 watt power supply. If it's just a power issue, then it's an easy fix... I just never got around to bothering to look. I THINK it's A Gould Biomation K100-D... But I'd have to runout to my storage unit to see. I think it had 16 lower speed 20 MHz probe channels, and 16 active probe channels, good for up to 100 MHz (though it only has a memory of 1024 words). Looking at the manuals online, I'm seeing dates of 1980 and 1981... Definitely not bad speeds for that era! These days, that's nothing. Basic entry level stuff. The main issue is the SIZE! It's HUGE! 19.5 kg/43 pounds, 22x45x55 cm (9x18x19 inches). It's a bench beast! I also have the service manual for it... So I probably COULD actually pinpoint a fault in the unit if I really wanted to. I just haven't had the desire to go digging. As for the tape length, 1 meter is the limit for my specific tape meter, because it's in a continuous loop. A reel to reel style tape meter could be made longer than a meter, if desired. It would only require a different scale. As for format... I don't know yet. The shop knows this is a one off, low priority job that'll only net a small fraction of a fee, compared to large batch orders. They've been too busy lately. I asked what format i could submit a file in though, so if it's something I can work in, I might do the layout myself... Honestly, I was probably gonna work in a large high res image format, if they can accept that. Unless they say otherwise, that's all I can think of. As for the design, it's a bit inconvenient, as it requires each printing to cure, as the tape has to be rotated around to expose the next blank section, while the previously printed section faces down then. My particular design will take three separate printings, so it's a really unusual print job.

I have an old Gould Biomation Logic analyzer that I've always wondered if I could ever repair. It's ANCIENT... Maybe late 1970s or VERY early 80s. It has a CRT screen... The catch... It's mostly built using small scale logic, early memory chips, ECL (emitter coupled logic) gates... Really old stuff! The thing is just HUGE! I got it for free ages ago, and ultimately, I've decided my next oscilloscope MUST be a mixed signal oscilloscope, with a logic analyzer function built in. A modern analyzer would be more useful, both function wise, and for not taking half my workbench. For me, I'd want to be able to use it to analyze pulse propagation in the neural networks for my robots, in relation to motor drive outputs. Also probably Arduino stuff... Regarding the tape, I don't yet know what the costs will be. My tape meter will be 3 feet long (just short of 1 meter), simply because that's how long my tape is. Truth is, if i wanted to work with other materials, i might have simply done a much longer meter, with even more divisions. Since my meter is a fixed length loop, I had to work within the available space. At the very least, I'll share my experience with having the tape made. If the price comes back as being quite reasonable though, I don't think shipping will be an issue. A first class package under 8 ounces can ship from US to Germany for around $14. Those flat rate boxes are way overpriced.

Quick little update... I have found a screen printing shop willing to source me the ink for my Radar Altimeter tape meter (to stamp numbers myself). Thing is... They actually appear to be both set up for, and willing to actually do a proper screen printing of the entire actual tape! They have a screen printing setup normally used for printing onto table cloths that can easily accommodate the tape's length, and can be vertically offset to support a shim that would prevent creasing the tape (since it's in a loop). Since I'll have a half window gap between the bottom of '0m' and the top of '>10000m', the tape can easily be printed in two separate passes. They'll only need to align the second printing with the first half, and all should be good... I also came up with a three pass option that prints a divider that is similar tot he end of tape markings on actual NASA tape meters. I'm gonna try to print that. I'm using a scale split into three resolutions... 0 - 1000 is in 10 meter increments. 1100 - 3000 is in 100 meter increments. 3500 - >9999 is in 500 meter increments. I didn't wanna deal with trying to figure out a logarithmic scale, but I wanted better resolution for landing, so I did it in three distinct steps. Software will compensate for the steps. Here's the thing... I don't know what I'll be quoted for the job yet, as I'd only be having them print the two tapes I have (one to use, and one so I'll have a spare)... Thing is, economy comes from quantity. If others are interested in tape meters though, I see no reason I couldn't have additional prints made for anyone interested in tape meters for their own builds. I could have them print it on vinyl sheets? undeveloped film reels? Film leader... I dunno. long story short... I might potentially have a Radar Altimeter tape meter scale ready for manufacture with a professional printer... Just attach the roll to your own mechanism, however way you like. So, is anyone actually interested in such a thing?

Small update... I may have found a screen printing shop willing to either source me the ink for the tape meter (to stamp myself), or even to actually screen print the entire actual tape! They have a screen printing setup normally used for printing on table cloths that can easily accommodate the tape's length, and can be vertically offset to support a shim that would prevent creasing the tape (since it's in a loop). Since I'll have a half window gap between the bottom of '0m' and the top of '>10000m', the tape can easily be printed in two separate passes. They'll only need to align the second printing with the first half, and all should be good... I don't know what I'll be quoted for the job yet, as it'd be a one off... Economy comes from quantity, so it might not be all that cheap. Actually, I'll probably have them print both tapes, so I'll have a spare. It's almost a shame I have proper tape meters... As if I had to make it from scratch, I'd have already bought a roll of film leader, and I could have made dozens of these... I could have offered them to anyone interested in tape meters for their own builds. I suppose it's still possible. I don't know if they reuse the screens, or if they are one use items... If one use, I also don't know if they retain them or not. I submitted some files to the screen printer, including this concept sketch. I'll have 10 meter increments between 0 and 1000 meters, 100 meter increments between 1100 meters and 3000 meters, and 500 meter increments between 3500 meters and 8500 meters, with the final unit being >9999 meters. It's a total of 135 total increments, with the tape supporting 144 total increments. The difference covers the "gap" dividing the top and bottom of the scale, and will allow the window to never show both ends of the scale at the same time. I modeled the end of scale marker off NASA meters, pictured. Measuring the tape was tricky, and I repeated several times, hoping I got it right. For the encoder, I may as well just utilize the sprocket holes. I should be able to position some photodiodes in the right place to make it work. I will still need one index to zero the tape. I'd rather not punch an extra hole in the old tape if it can be avoided, so I might just add a screen printed dot near the edge of the tape, and pick it up with a reflective photodiode/LED pair.

I like the look of the film! It's a bit darker than I was hoping, but I'd also like to find a VERY thin sheet of translucent white diffuser film, not enough to blur the LEDs, but enough to create a lightening effect behind the film. I specifically got a combination of neutral tint film (20%) and some reflective gold tint. I've placed the gold tint under the neutral tint, because I wanted to subdue the gold reflection. I'm... Actually wondering if this was 20% opacity or 20% transmission... Now that I look at the product page... It's just listed as "medium black"... Did I read another product's title? As you can see below, when you combine an overhead light and a flash, you can see through the film, but in the normal lighting of my room without the overhead light, it's pretty good at concealing the electronics underneath. I might still try to find a white mild diffuser to go beneath... Something like maybe what's in the backlight of an LCD. That might work. Good transmissibility too. If laid flat against the LEDs, it shouldn't distort or diffuse the segments much at all. If I do find a suitable whitening layer to put beneath it, I might order an even lighter neutral tint, to get a lighter grey. The bubbles are... Not gonna be part of the final product. These were haphazardly stuck together for visual testing. I'll need to very carefully bond the two sheets together. I think the best way to do it will be to take a roller and roll the two sheets together against my granite surface plate (a very smooth slab of granite, polished to a high degree of precision flatness, used in machine shops to make measurements on). I have a toner transfer drum from a photocopier somewhere... That thing's super smooth, and a rather large diameter. It'd be perfect for rolling the films together. I'm really liking how this looks!

I spent $15 to experiment with window tint. I ordered some grey tint (20%), and some reflective gold tint. I want to use it to try to loosely mimic the DSKY electroluminescent displays. I want to add a slight gold tinge to it, so I'm going to experiment with the grey over the gold layer, to see how it looks, It might not look good at all, but I won't know unless I try it. I also remember why I had the LEDs cranked up to max! It's gonna be shining through multiple layers of tint. I'm also on the home stretch as far as diode ROMs are concerned. I finished the third, and final, Altitude display ROM, and already started on the final General Purpose display ROM. After that, I only need to do the Speed display ROM, which is gonna be a really small one (--, m.S, K.S, c, and the test character). I dug out my breadboard to prototype the LED decoder/driver. I just need to figure out what parts are ideal for the task. The fact that it needs to be non-inverting slightly complicates it, but not much. **EDIT** I'm now wondering if I should add "c" and "AU" to the General Purpose display ROM. It'd be easy enough to add to the new one being built, but I'll have to tack it onto the old one. Not impossible, or even hard. Just slightly inconvenient.

I know this has absolutely nothing to do with KSP, or the instrument panel I'm building, but I think talking tools is probably still fair game. Given all the talk of what people have achieved with their 3D printers, the temptation to turn this into the X axis of a GIANT 3D printer is SO tempting... It's Yuge! It comes from one of these: It's an automated pipettor machine, and the lab where I work scrapped that assembly out, and I got it. I just need to install steppers and belts to it, and a bed, to make it into a functional single axis platform. Overall, It's 46 inches (116 cm) long and 28 inches (71 cm) deep. The linear mechanism is nearly 41 inches (104 cm) long, so accounting for end stop sensors, it would presumably allow a 20 inch (50 cm) bed to move 20 inches (50 cm) along the axis of travel... That's still an incredible amount of potential build volume, even if it's just one axis. The mounting points (where you'd attach the bed) are 23 inches (58 cm) on the inside edge, and 26 inches (66 cm) on the outside edge, so bed depth would be based on how you mounted it to the traveling linear mechanism. Honestly, it's probably easiest to mount on the inside. If you have the Y axis feature a full enough travel span to cover the full bed depth, you could potentially have a build area of 20 x 23 inches (50 x 58 cm), plus whatever the Z height ends up adding for the overal volume! That's incredible, considering the build volume of most cheap 3D printers! I'm trying to consider what would get me up and running the quickest and the cheapest (If i ever decide it's not good enough, I could always rebuild the Y and Z axes for something better). While I know they aren't as rigid as a fully framed mechanism, I've considered the "inverted L" shape mechanisms like what's on the Tronyx X1, but I have significant concerns about the stability of that if it's gotta extend out 23 inches (58 cm), vs the X1's 6 inches (15 cm). Having the two screw mechanism for the Z axis, and y on a belt, like is seen on some other Tronyx models seems to make a lot more sense. It seems like that would be far more rigid. I simultaneously want to and don't want to know what this assembly cost... I got it for free!

I got them from All Electronics as surplus, so they may be older parts. I would have to look at actual date codes or the datasheet when I get home to be certain, but part of me wants to say late 1990s or early 2000s. A lot of my annunciator LEDs also are salvaged from equipment of similar period.

I don't know about one wire interfaces, but all you need is the bandwidth to transmit the angular position for an axis at least once every or every other frame. If you miss a transmission, It's not the end of the world, as the next frame, the data will catch up. (frame being a reference to updates sent by KSP). The general configuration is as follows: [Main Microcontroller] | | (1 wire bus + power) | |-->[Roll Axis Micro]<--[Roll Index Photo Diode] | '--->[Roll Motor] | v [First Slip Ring] | |-->[Pitch Axis Micro]<--[Pitch Index Photo Diode] | '--->[Pitch Motor] | v [Second Slip Ring] | '-->[Yaw Axis Micro]<--[Yaw Index Photo Diode] '--->[Yaw Motor] You use a small micro for each axis controller. All each micro needs to do is have a position in memory where it expects the axis is, a position recieved over the 1 wire bus, and then it just has to step the motor int he right direction to make the expected ball position match the commanded ball position. Whenever it gets the index signal, it'll reset the expected ball position to a known value, and let the program drive the motor to update it. That way, the ball stays synchronized automatically, with each revolution. When it powers up, or you go to a new vessel or something like that, it should automatically spin the ball till it indexes, so it "learns" it's real position. The index should be measured going clockwise and counter clockwise, as you may get two different values depending on direction. The direction the motor is going should determine what index value expected motor position is reset to when the index is sensed. You still absolutely need to have the photo diodes though. You just don't need to send their state over the slip rings. Each of the three small micro controllers are a self contained axis driver. The benefit of this design is you design the axis controls once, and just repeat it three times, the only coding difference being which packet of three each axis controller listens too. Each micro does its own motor control, its own index calibration, and reads only its own packet. It only requires 3 wires, period, for the whole system, if you're sticking with a 1-wire bus. This layout eliminates any motor leads going through slip rings. only power and data. Each small micro can be directly wired to each motor's driver.

@Pvt. KASA That is an EXCELLENT slip ring design! That's actually similar to ones I used to instal when assembling synchros at my old job. I... was not expecting you to go that style, or land on such an undeniably solid design! Excellent work! For additional noise tolerance, you can consider using multiple wipers to contact the rings. I'd suggest providing power and ground, and then your data signal. Rather than trying to directly command the motors, I'd say, setup your index locally to your controller. Have a tiny micro, like a teensy or an Arduino pro mini or micro. You can just send a value to the microcontroller to represent the desired position of the axis being driven. The micro would then drive the motor in whatever way it needs to to get the motor to rotate that axis toward the goal. Every time the index is triggered, the micro should check if the motor step count matches when it expected the index. If it matches, then carry on. If it does not match, then it should reset the current position to match the index position, and allow the program to continue running the motor till expected position matches current and position. That accounts for any mis steps, and lets the micro on each axis update the ball position without any external guidance, save for just the coordinates. and the values for the desired navball position.

Change of plans on the test character... With each segment drawing approximately 19-20 mA at full brightness, it turns out driving all 30 segments of the display for the test character... ehh... well, draws a few milliamps... About 570-580 mA per display pair. I think I've actually got them a hair too bright, so I may drop a few more ohms on each anode to fine tune the brightness and drop the current a bit more. Still, even if I bring it down to 15 mA per segment, or even less, that'd still be around 450 mA... The 2N3904/6 transistors I have on hand are only rated to 200 mA. Even at the full 19-20 mA, unmodified, the max number of segments on when NOT displaying the test character is 11 segments... vs 30 for the test character. 11 segments drawing 19 mA is 209 mA, almost within the spec as is! For that reason, I think I will switch back to the concept of having the test character be it's own line, and I'll probably just tie them all together and trigger it with either a relay or a power transistor. Even for the regular characters, a 74HC154 4-to-16 decoder chip still only drives 20 mA per output, so I'll have to configure a non-inverting buffer amplifier to drive the LEDs. Derp! Forgetting the important facts. I really wish it didn't need to be non-inverting. I have plenty of BJT type transistors on hand... but most circuits with BJTs invert. I might have to see if I have any mosfets.

SOIC/TSSOP adapter boards showed up yesterday, just in time for my three day weekend. I tried assembling one, but I started REAL late, and I was just eying it off the data sheet pinout (no schematics or plans), and I kinda realized I wanted to change something after the fact... Eh... that's why I ordered a sheet of 20 boards... You just snap them off as you use them. I also have extra chips, and the one I have now isn't bad, just not configured the way I want it. I decided to keep consistency across all displays. The same binary number will always select the same symbol, on any display, and if a display has additional symbols, those will use higher binary values to select. It'll be a simple, consistent pattern I can use for all displays. I think I'll also have the display test character be selected in software after all**... I was gonna break out all the character selects to a single driver, and have that one line activate all of them, but I may as well keep it all consistent, and just so it in software. I also need to remember to include driver transistors. I'm driving as many as 30 LED segments from a single line. I need moar than 20 mA to do that. I may also have a shot at trying to get some work done on the analog meter mods and the light boxes. I realized the PERFECT material to use for assembling the light boxes. I have some double sided copper clad ultra thin PC board material. When I bought it, i thought it was just sheet copper... It's that thin. I can just cut it with a scissor, and solder the pieces together. I can even create the intricate inner light boxes to focus red, yellow and green LED light on the portions of the meter that must be a specific color, and I can even secure the LEDs to the lightbox by just soldering all the cathode leads tot he lightbox itself, and making it my ground. So, hopefully more news this weekend!

I'm building a custom controller/instrument panel, so I can't really say too much for commercial options, but to me the ideal retail controller would be a three axis joystick of any decent quality paired with the Saitek Farming Simulator side controller This thing is almost laid out perfectly for KSP... Action groups up top, a 3 axis stick for RCS, and enough controls to do most major functions. I find it amazing that a farm ing controller is so well suited for a space exploration game! I guess there's a reason a new tractor or harvester costs as much as a house! Complicated machines!

WHY!!! Why must every order include EVERY part needed, EXCEPT the ONE single thing you forgot... Why does every order need a forgotten part! Turns out I never considered soldering the decoder chips when I did my ebay order for the square pin female header sockets. They arrived in the mail (ordered 100x 40 pin header sockets... They ought to last! ), and the second I saw them I realized I goofed... No, they were perfect. I jsut faield to remember to order oanother item. For the "Time to:" and "Speed" displays, I only need a 3-to-8 decoder, which is a DIP chip. My 4-to-16 decoder chips, which are needed for the larger distance units displays, nis in a 24 pin SOIC surface mount package, and I have NO proto boards compatible with SOIC chips on hand. No problem... I'll just order some and... EVERYTHING from China. Nothing local, and it's all the SLOW Chinese shipping. Earliest I'll see them is middle of April or early May. I hate waiting! Anyway, I ordered them anyway, I need them. Even if I ordered from Adafruit, they'll still take long enough that the increased cost per unit doesn't really justify getting parts a week before the earliest China shipping date... I did replace my dying car, so I could probably afford to drive up to Minneapolis, but having bought a replacement car, by the time I got there, I'd not have enough to buy the overprices Schmart Boards from Micro Center that woudl let me proceed... All in all, it's a game of hurry up and wait. I decided against dead bug construction, considering I'm kinda keeping busy anyway. I'll just wait. Let this be a lesson on making shopping lists!

In all honesty, it's not even hard to source slip rings. Ebay has them in 6 and 12 conductor versions for fairly reasonable prices. The magic of a navball is it's ability to continuously spin without hitting any mechanical limits. It's also the mechanical complexity that has led to the modern day "glass cockpit", where all the old traditionally mechanical instruments are now just LCD screens. I think it was @stibbons that made a nice little LCD based navball. For the three axis navballs that are required in space faring vessels, there is a requirement for both precision and accuracy. A BB8 style mechanism requires the ability to detect the absolute position of the ball, which almost guarantees the need to do visual processing, and to have a camera being able to see the ball. Having a rotating roller wheel could work, but you'd still need a pair of them, and they'd still require slip rings or else they would be limited to a restricted number of rotations before needing to reset. If they undergo a moment of reset, the ball's motion will hitch for a moment as the wheel flips. I've worked with the rotating magnetic fields of three phase sinusoidal drives and motors long enough to be able to visualize the rotation if the fields in relation to the inputs. When dealing with wheels and balls and circles and spheres and whatnot... It all comes down to sinusoidal patterns, when you graph it out. Anything that has a limited range of motion will abruptly have to stop at some point an backtrack. There's simply no avoiding it. Slip rings let the motion continue along the path it wants to take. It's truly as simple as that. The Air Force and NASA had the mechanics of the navball down to a science, literally. As long as you can get the motors and encoders to physically fit inside the ball, it's not hard. If you counterbalance it, and you have room for the swinging motor, you can even have one of the motors NASA puts inside the ball on the outside The reason NASA puts two motors inside the ball is to keep the unit compact, balanced, and fast. A large diameter object takes more time to accelerate and decelerate than a tight, compact diameter object that keeps it's center of mass internal. While @Pvt. KASA has already made homemade slip rings, I can't stress enough how easy it is to just buy them. They are simply not even a hurdle or challenge to face. It's a little extra work to make them yourself, like he did, but they are absolutely not hard to source, nor are they overly expensive. If reducing things down to power and serial, something like a TRRS plug and jack could probably sufficient too. The point is though, that trying to skip out on the slip rings simply makes no sense. Limiting the number of spins, forcing reset cycles, etc... It is literally not necessary. a 6 conductor slip ring is about $3-4 on ebay, and a 12 conductor slip ring is about $8. You can get 18 and even 24 conductor slip rings, but they are more expensive, closer to $15-25. With a little Machining or 3D printing, you can make the mechanical bits you need, use a purchased slip ring, plus your motors and encoders, and you'll have everything you need for a navball!

Couldn't have covered that better myself @Krewmember I actually would like to motorize mine as well. I think I'm going to consider salvaging the tuner wheel from an old stereo and using cables and a pulley to drive the lever. I happen to have some nice little gear motors with slip clutches on them that ought to work well for driving it, but letting the mechanism slip so it can be adjusted by hand as well. At the very least I'll have min/max throttle buttons. I think the button on the tip of my joystick might serve as a "Kill Thrust" button, but I would like dedicated buttons for the task on the panel too. I also like the way the lever's firmness is adjusted on the example you showed. The two screws that go into the plastic block tighten the compression on the plastic bushing, generating the lever's physical resistance. On mine, the PC board on the bottom is actually quite thick, and a screw tightens down on a "spring" made out of a routed region of the PC board. Tighten the screw, and the routed segment of PC board compresses harder against the bottom of a cam built into the shape of the lever. I think the picture you posted is a more robust system than mine. Mine has a really high quality potentiometer though, and the PC board based spring does seem to actually work though, so I can't complain. I only spent $10 and some shipping on that video effects board, and I got all those illuminated regengendable buttons for my DSKY, and that throttle, and the insanely valuable dot-matrix character displays I'll use in my ∆V carriage meter out of that purchase! Hmm... Now that I think about it, I bet if I got the pulley mechanism just right, and the slip clutch on the motor provides just the right amount of friction, I bet I could remove the PC board form he bottom and let the motor/clutch mechanism, be 100% of the lever physical resistance, saving me a small amount of thickness. The lever is one of the thicker elements of my control panel, and I have to physically place it as far left as possible on my build, as it's current thickness will actually interfere with my keyboard tray that would sit immediately below the control panel and slide out. Hmm... Things to ponder and tinker with!