harbingerx81

I think it is well worth price tag personally...The only downside is that it hits its max/min resistance pretty close to the center, about 50% of its range of motion is outside the range where it really has any effect. For me, this is just fine because I wanted full control with minimal movement, but it might make precise control a little difficult on small ships with quick turning speed. It is very solid on build quality though and the springs are the perfect stiffness to be able to move X-Y without accidentally twisting the Z axis. I'd call it a 9/10.

Well, you have the footprint you plan to fit all of your lights, buttons, displays, etc on, that is the 'board'...You keep coming up with more and more things to add and eventually run out of space, pushing bits outside the limits of the original dimensions...So, you go over [the edge of the] board... Good thing I am still waiting for my 3D printer, so all I have is a pile of electronics on my desk and can keep adding to that mess of wires without consequence for now...Instead, i just keep making more and more little circuit boards to wire into this monstrosity...

I know I talk about how much I prefer the Teensy 3.1 to the Arduino an awful lot on here, but this is another great example...I just got this in the mail a couple days ago: http://imgur.com/lNCAkBk A little pricey at $35, but it is a solid, compact, and spring return 3-axis stick with set screws to calibrate the resistances, perfect size for what I was after...Since the Teensy can simultaneously emulate serial, keyboard, mouse, and joystick across the USB connection, I have not needed to do anything with the MOD's control outputs and instead just rely on the built-in emulation... Setting this thing up for KSP was MUCH simpler than I was expecting...The code is literally: valueX = analogRead(2); valueY = analogRead(1); valueZ = analogRead(0); Joystick.X(valueX); Joystick.Y(valueY); Joystick.Z(valueZ); with no other effort required...The only other thing I needed to do was adjust the set screws so that my analogRead()s were fairly close to 512 (since from the factory all 3 were around 650-700) and then go into the control settings within the game and assign them as I would a normal joystick...I did not have to mess with software calibration or dead zone mapping at all to avoid drifting, things just worked perfectly with defaults. I have not even gotten around to reinstalling the MOD after .90 because I have been working more on construction and controls rather than coding for the display (and, admittedly, I have been playing too much after the update to get as much work done as I should). Since the board I am using can handle all the input data directly and with a greater range of function than using the control packet within the MOD, it makes things much simpler. Note: Not at ALL knocking the control features of the MOD of course , this just lets me go a little more overboard with my design.

This is what I am doing already, probably 2 x LCD displays and a second microcontroller dedicated to them...My suggestion is that you go with something beefier than an Arduino though, for a couple reasons...I would heavily suggest the Teensy 3.1: https://www.pjrc.com/teensy/teensy31.html A quick break down: ARM-Cortex-M4 running at 72 MHz (vs the Uno and Mega's 16 MHz) 256 KB Flash (Same as the Mega, much more than the Uno's 32 KB) 64 KB RAM (8x the Mega 32x the Uno) About $20 Fully compatible with the Arduino IDE and almost every library via an Addon downloaded from their website. **For one, updating an LCD/OLED is a relatively slow process depending on how many pixels are involved with the change and the Arduino can't really keep up...I have used several different screens on previous projects and it is always an issue, even when using something with a 128x128 resolution and what I am using in my KSP controller has a 240x320 res...Testing THAT display with an Arduino vrs The Teensy updates 3-4 times faster. **It has 3 Serial ports, so if you don't want to screw around dealing with SPI/I2C libraries to communicate between boards, the Teensy makes the process fast and easy. **You can emulate Keyboard, mouse, and joystick functionality over the same USB connection you use to read the serial data from KSP...This means that with very simple, out of the box code, you can control pretty much everything. **Cost/function they can't be beat if you want to stick with the Arduio IDE. Cons: They only come in a 'mini' profile, so they are not going to fit Arduino shields...Also, unless Zitronen has changed the packet structure since the last version I downloaded, you might have to modify things a little bit to account for the fact that the Teensy is 32-bit and some variable sizes may be different than the Arduino's.

SOLVED! I had to go play around in the registry... \HKEY_CURRENT_USER\Software\Squad\Kerbal Space Program The resolutions in there were stuck on ZERO for some reason...Changing them to something else (in this case I went with a windowed 1600x1200) allowed the game to launch and from there I set my fullscreen res back to 4622x2560 with no issue.

Nope...No change...Tried the previous set of drivers out, then updated back to the current version and continued to have the same error both times.

Yeah, that is my next step after I get off work...I am going to try previous versions and maybe the newest beta of my drivers...I am leaning towards the Unity update being the cause, but it is odd that I have not seen anyone else report the same problem...My display/hardware setup is a little unique, but not unconventional enough that I should be a rare exception...Not to mention that I have reverted to something much more 'normal' and still experience the same issues.

The first time I ran in after a fresh install it crashed without generating a config file, after that I ran Launcher.exe, used the 'minimum' graphics settings and made sure that it was running in 32-bit and windowed...After running the launcher, I checked the config file it generated to make sure that the proper settings were saved into it... I just deleted the config again, ran it, got the same crash with no new config generated...Whatever is causing it must come before it tries to read the config.

Sigh...Well, it works perfect on my laptop under Linux...Don't know if I can handle playing it on there when I have gotten so used to it on my current rig...

Killed all non-essential NVIDIA tasks, video enhancement managers, etc...Same result.

Tried rebooting multiple times depending on the changes I have been trying...And no, no extra arguments...Since the last call shown in the log was a support DLL for unity followed by a Direct 3D device error, I also tried reinstalling my display drivers, but to no avail.

This crash is immediately on launch, in both windowed and fullscreen (I used the previous version in both modes and never had an issue Alt-Tabbing from fullscreen). The Dialog box appears before it makes visible attempt to launch a game window.

Sorry, Info added.

On launch I get the following dialog box: This is running the Windows 32-bit and 64-bit version immediately after the .90 update I am running NVIDIA Surround on a 2x SLI GTX 780's under Windows 8.1, all drivers are up to date, 8GB RAM, AMD FX-8370 @ 4 GHz. I have deleted all local files and done a fresh install. I have tried launching the game through Steam, Directly with the Launcher.exe, KSP.exe, and KSP_x64.exe. I have tried manually setting the starting resolution to many different options using Launcher.exe. I have tried launching in Fullscreen and Windowed mode at varying resolutions. I have tried disabling SLI, Surround, and running just on a single monitor. All of these steps have given the same non-results. EDIT: Adding relevant info Version number: build id = 00705 2014-12-15_13-42-05 Branch: master output_log.txt------------->

Very nice! I think I am going to have to add a lot more controls to mine (though probably not quite as many as you have) before I am done...I just need to wait for my shift registers to get here, since all I had laying around were SIPO...For some reason I had not thought about all the other gameplay related keybindings that I should add to things. Right now, I am stuck on some hardware serial issues because I am going to need to add a second microcontroller into the mix...The 240x320 LED screens I want to use take WAY too long to update even using a Teensy 3.1...Ends up clogging the serial buffer and causing all sorts of problems so I am going to outsource the problem...If I can ever get the damn things to talk to each other.

I wish that was my timeline...I have a kickstarter 3D printer coming sometime (hopefully) in Feb that I plan on using to make mine...I should have all the electronics done by the time it gets here, but they will just be a taunting jumble of wires and pretty lights for a while yet.

Is the 16-button joystick limit really an issue though when you can also send keyboard keystrokes? I am not exactly sure what he was asking about, but a prograde/retrograde/etc marker would be a great thing to be able to add...I plan to use a small LCD to simulate the navball in some way, which I should be able to work out using the pitch/roll/heading data...I was not even thinking about additional markers until now. I have no idea how the game or the plugin are actually coded, but I would think that there should be some kind of separate vector data that determines where the markers appear on the navball itself, along with things like normal/anti-normal and the maneuver nodes. If that is what he was talking about, I agree that would be icing on the cake.

Well, I just spent 3 hours trying to figure out how to get my Teensy version to correct for the structure padding issue on KSPBoardSendData()...All sorts of different variable arrangements, complicated buffers trying to arrange things correctly to get the right checksum, ridiculous bitmath, reading serial data and trying to convert the ACSII output into hex...Many many things that had me pulling my hair out... Then, the "eureka/you-stupid-...." moment finally came when I remembered that the Teensy has capabilities to do Serial + Joystick + Mouse + Keyboard emulation all at the same time, something I have never used...Less than a minute after this 'discovery', and one short line of code later (literally as simple as: Keyboard.print(" "); ), I launched with a hardware button and felt that all to familiar mix of accomplishment from solving the problem, and embarrassment that I did not think of the obvious sooner...

I can't promise quality, but I have always had good luck ordering from Aliexpress...Here is the best option I have found on there: http://www.aliexpress.com/item/KD2-22-ON-ON-Momentary-illuminated-push-button-switch-RED-GREEN/2021412603.html hard to go wrong with 20 for 10$ shipped, but I have no idea what the specs are as far as LED/incandescent lamps and voltage. (Oh, and shipping to the US from China is anywhere from 2 weeks to a month, so that could play a factor...) Personally, I am going to go with an RGB led mounted next to the switches that will change from red to green as the button is hit. This is a quick sketch-up of what I am going for: http://imgur.com/5v70ZPi Alt Display LED Displays for AP, PE, and ALT with time to AP and AE...I am going to make the ":" solid when displaying hours/minutes and flashing when displaying minutes/seconds Velocity display: Since you have orbital, vertical, and surface velocity to track, I am going to have one display with buttons to change which is displayed, the current mode will be indicated by LED. Fuel Gauge: I plan to use and LCD screen to show colored bars displaying things like fuel, oxidizer, electricity, etc...There will be a button and a pair of LEDs here as well allowing you to toggle the display from current stage to total levels. Staging button and a read out of the stage number. RGB Indicators: to indicate things like air density and G force, I will probably add some others to this later on. Action Groups: each button with an RGB Led to indicate off/on in red/green Throttle control: with leds colored along side going from green to red based on power. Maneuver Nodes and the remaining delta v required...This will also display the mission time when there is no current node, and the button / led will toggle between them when there is. Audible alarm with an alarm silence button and flashing LED Panic/Abort of course. Navigation system...I am not sure yet how I am going to handle this, but it will basically replace the nav ball somehow with another LCD. I may or may not eventually and a pair of small joysticks to handle steering and RCS toggling...What I would REALLY love to do is find a small 4 - axis control stick that won't cost more than the rest of the project put together...I have found a couple nice ones on Aliexpress for around $30-40, but the shipping on them ends up bring the total to close to $100

Well, I found a solution...It is a bit ugly, but it looks like it will do the job... What I did was strip out all of the checksum code, remove the rx_len to structSize comparison, re-order the struct of VesselData so that VData.id is that LAST byte, set VData.id=id rather than using the buffer, and drop the initial value of rx_array_inx from 1 to 0... It definitely was the a padding issue and when I start adding in control outputs I am sure I will have to make the same hacks. The gcc __attribute__ modifier you suggested is probably the more elegant (and correct) way to do things, but is something I am unfamiliar with in my playing around so far....Eventually I will go back and learn things the right way.

Yeah, I have tried that too...Going to take a break from it for a while, because I must be missing something silly...Not sure how the sizeOf() something consisting of 3x int32_t's (12 bytes), 2x uint32_t's (8 bytes), 39x floats (156 bytes), plus and extra byte for the 'id' (12+8+156+1 = 177 last I checked) is being reported as 180 bytes... Ahh...Good call...If it is padding that first byte holding the 'id', that would definitely explain the 3 byte difference...When I get back to it next time that will be where I start.

Huh...And at a quick glance...I honestly have no idea how it can be off by 3 bytes...

Found where the problem is...I don't have time at the moment to figure out a fix though. I added these lines into the SerialCOMS and found that rx_len is 177 and structSize is 180, so it does look like it is just a matter of matching up the bit lengths between the 8-bit and 32-bit architectures.

Haha, I know...The little things are monsters, especially at a ~$20 price tag... I will have to check out your port in more detail if I can't get things to work straight from Zitronen's with only a little modification...Part of what I love about the Teensy is the fact that they made an add-on allowing normal use of the Arduino IDE to program them...Saved me a great deal of time (and allowed me to be lazy) not having to figure out winAVR and the coding differences. If nothing else, I can probably just write the data parser over again from scratch (though I mine will be ugly and inefficient), but I am pretty sure all it will take is a little tweaking on the buffering and addressing to get it working. I was just curious about whether or not it had already been done by someone on here.

It might be somewhere in the thread, but I did not take the time to scan all 50+ pages...Do you have any info on compatibility with the Teensy? In most cases it seems to be totally compatible with Arduino code, but sometimes (like this) there seem to be minor issues. Looks like I get initial connectivity as the launch pad loads, I get the 'starting' and 'using' messages for the correct serial port, and the green LED will light during load. After that, no LEDs and I do not seem to get data on my LED-Displays. I have used the same code and connections on an Uno and it works fine, but I am planning on running a lot of peripherals that I think will more than max out the UNO and even a MEGA in terms of computing power...I am guessing the problem stems from the memory and buffer manipulation in the SerialCOMS section and I am going to experiment with the hopes of fixing it, but I figured I would see if you had any existing info first.