Katamari

Just wanted to say that this looks awesome and so I downloaded this and a couple of your other mods through CKAN. Don't know if you get statistics on how many downloads go through it, so I just thought I would let you know here! That Space Casino looks awesome and having a contract telling me to do something awesome makes me a lot more likely to do it than just having the idea of something awesome.

I don't think it is a problem with the Arduino. I don't know where the gauges came from, but it is probably that the gauges were not made to be driven by a linear voltage source. I would suggest just going by trial and error. Try putting different analog tests out to it (just try regular analog outputs from the min to the max) and see where they line up on the gauge. Then either see if there is some sort of a fit line for them (Wolfram Alpha will probably let you put in points and try a line of best fit) or else just set specific ranges to attach to points and do a series of "if .. then, else ..." to set the gauge to specific values.

I didn't think about that... Hmmm, when time is no longer constant... Sounds like relativity, except that you are correct in that this cannot be accurately calculated from outside the game. Anyways, now that we have control groups, I am already really happy with where it is at! Individual resource outputs (just Max and Present of each resource type would be sufficient) would be cool to have rather than the pure percentage. If by "axes" that you are working on, you mean Current ship Axes and not "input axes", then that would be a pretty awesome addition. Unfortunately, I still think that resource consumption rate is kind of niche, but if you can find out how to do it, it would have its uses (Ex: calculating burn time remaining).

I would recommend against having resource draw as an output to the Arduino because that is just making for a very large packet of data to send back and forth. If the Arduino gets the the actual amount (preferably in a float to a high precision), then you can calculate the draw rate really easily. Just store the value from the current data packet, then read in the new data packet. Subtract the old charge from the new charge and divide by the time between when the packets were received. A very quick and dirty way to do this is shown below by only changing the loop() (I assume that the electric charge is VData.charge): void loop() { // Store time and charge from last reading unsigned long oldTime = currentTime; float oldCharge = VData.charge; input(); output(); // Find change in charge and time unsigned long currentTime = millis(); unsigned long deltaTimeMillis = currentTime - oldTime; float deltaTSeconds = deltaTimeMillis/1000; float deltaCharge = VData.charge - oldCharge; // Calculate draw float draw = deltaCharge/deltaTSeconds; } It could be made slightly better, but the point is that this should be possible from only reading the charge and time of each data packet from the game.

Thanks for explaining that for him, Zitronen. Sorry, I forgot that I should probably have explained how to code for it. Also, Mulbin, if you want a good introductory guide to read through and explain how to code in Arduino and some simple circuits, I would suggest you check out the PDF here: http://ardx.org/src/guide/2/ARDX-EG-ADAF-WEB.pdf It is a really short guide that starts off with a coding explanation followed by examples of how to build circuits and how to program them. Additionally, it also teaches how to use shift registers in one of the sections if you are still looking at using them. One thing it does not cover is the pinMode(pin, INPUT_PULLUP) command, but the official explanation of how INPUT_PULLUP works can be found here: http://arduino.cc/en/Tutorial/InputPullupSerial#.UxzOGIVhdFs

This is how you will want to hook up (sorry about the odd symbols, the software isn't really made for Arduino). V_High is your 5V output from the Arduino, Input_Pin is the pin to read from, and Ground is your standard ground. What happens is that while the switch is open, the pin should read ground, but when you close the switch, there will be no voltage drop across it, so the pin will read high. Then the 5V will drop across the resistor and the LED then be back to ground, so it will power the LED. Remember, input pins act like voltmeters, so they do not normally really take any current flow through them.

So since I know C, I tried last night to see how C# works and glance through the KSP Assembly library to see if I could locate the "read sas/lights/etc. status". After an hour, I now fully understand why they say C# is not like C and also I realize how little I understand about classes (and how hard it is to find documentation on the KSP C# library). About all I could figure out was what all was under the activevessel.orbital object and all the data that could be read from that. I do not think I will be going back for more. So that random tidbit aside, here are my thoughts on what I would like to see (and I have no clue if any of these are possible): Personally, I would like a few additional readins to KSP; specifically the Action Groups 1-10 and Kill Thrust. Most of the rest of the ones Mulbin mentioned, I rarely ever use. After that would be some of the readouts that the library can currently send in to KSP but can't read out (i.e. SAS, Landing Gear, Lights). This would be moreso for confirmation or just to kind of ensure that everything lines up.

So I have to ask, because I am really wanting to make a cool-looking control panel, but I have no experiences and am living at college, so I can't easily head to a machine shop until I have a plan. Your panels look really cool. What are you using to make them (or what would you suggest to make them from) and how are you printing onto them? My first guess would be Masonite and then painted over, but I honestly don't know.

When you added in what you had in the KSPIODEMO File, I found your problem. As you might have found out, the #define [i]word[/i] value creates global variables using the preprocessor. All that this means is that every time it sees the word, it just replaces it with the specific value that you gave. Additionally, unlike calling "int variable = value", this value cannot be changed within the program (cannot do value = value + 1 or anything). That is why the common notation for these types of variables is to put them in all caps. Arduino actually already has some of these built-in but that you never noticed. For example: TRUE is actually just the number one (try seeing what TRUE + TRUE is) and FALSE is zero. You cannot reassign these values, but having them makes it easier to read. When Zitronen originally sent out the KSPIODemo file for Arduino output, it had another block of "define"'s that you appear to have misplaced along the way. As such, just add the following into your KSPIODemo file (mine is right below the section labeled "pins for input" and right before the section labeled "macro"): #define SAS 7 #define RCS 6 #define LIGHTS 5 #define GEAR 4 #define BRAKES 3 #define PRECISION 2 #define ABORT 1 #define STAGE 0 This should clear up the problem. The way that the Arduino IDE/program appears to work is that each of the additional tabs are essentially header files that are automatically included (if you have any background in C). They just include additional functions that you might want to use within your code but that you don't want in your "main" file in order to keep the main file neat and so that you can copy these functions over to other sketches without having to copy them from within the code file (just copy the files for these tabs). Since these files only contain functions, it does not matter what order they are, if that clears it up for you. As far as I can tell, the Arduino software tells which file is the main one and which are the additional tabs by the main file must have the same name as the folder it is in. That is why if you try to open any of the additional files by themselves, it will ask if you want to put it into a new folder.

Just tried it using simple tactile buttons. The lights, gear, brakes, and abort all work. I could not get staging to work, though. Neither for initial takeoff/first stage nor any other stage after the first.

There really is no wrong way to do it per se, but since Zitronen's input and output macros are done so well, I would recommend just making it a separate function so that if he updates the library (the functions probably should just be turned into a library at this point), then you would not have to rewrite it. I would recommend checking the feedback from the plugin. The game readings can be different from the Arduino if you use the keyboard to change any values (try toggling the SAS using the keyboard and with the Arduino plugged in and you will see what I mean). Haven't tried it, so read Zitronen's post below.

Physics objects load at about 2.3km, so if you put it maybe 2.5 or 3 km away, you will be fine.

Just tested with my Leonardo using the default script. Only tested very limited; no docking, SOI changes, or anything like that. I could not really see a delay with either 38400 baud or at 115200 baud, so if Mulbin was having delays, I do not know what could be the cause. The in-game indicators in the top right worked correctly (I assume the specific method is a temporary measure). Also the toggling worked as well as it ever could. As you said, the game only registers a change if the Arduino sends a different value than before (one of the reads is different) and it will set it to the proper value sent from the Arduino. As such, you can have the Arduino be an optional input but won't cause any problems if you switch to purely keyboard mid-game. As I said, this is the best system I can think of and it works perfectly in my limited testing. Indicators also all work properly as expected (as they did in the purely Arduino-receive version), and I had no other noticeable problems (random crashes or slowdowns) with vanilla KSP in my limited testing. At Mulbin: very nice looking frontplate. Is that a printed metal board? I only fool around with things and most of my Arduino projects don't have a case or are enclosed in LEGOs due to my limited resource for making nice things, but I am hoping to learn/get my hands on the means to do nicer things. Also, any suggestions on good sites for cool-looking switches and such? The only hobby electronic sites I know of are Adafruit and Sparkfun which have a nice but limited selection.

I honestly know very little about Unity engine or C#, but my first thought seriously was a buffer buildup when Mulbin said there was a large time delay. Glad to hear that it was fixed. I will create a stock version and try this version out tonight if I get a chance. I assume it has all the same functionality so that the previous demo code still applies for data structures and sending/receiving. Also, if my Arduino experience carries over to computers and serial data: for the purposes of the computer reading serial data, do you just have it read the most recent chunk (either counting back so many bytes from the end or else searching for a specific identifier) and then just flush all the rest rather than reading every set? Or have you just increased the checking frequency to higher than the Arduino's sending frequency? As I said, I only know the Arduino side, so if it is neither of these, then I probably would not understand, but it is just an idea.

Zitronen, I just wanted to say Thank you for making this. I love KSP and enjoy working with Arduinos and I am so glad there is now an easy way to interface between them that is only going to become better.