stibbons

Check the documentation for lcd.print(). The second argument isn't related to decimal places, but sets which base to convert any numbers in the data to. Because Atmel Arduino boards like the Uno and Mega do not have a floating point unit, so any operations on them are done entirely in software and are considerably more expensive. Even better, printf and related functions in the arduino environment do not include support for floating point numbers either. If you want to print apoapsis as kilometres with one decimal point, using the standard Arduino libraries, you need to do something like char buf[9]; // buffer for formatted string long i = (long)VData.AP / 1000; // i contains AP in km long f = (long)VData.AP - (i * 1000); // f contains the fractional part of AP, three digits of precision f = f / 100; // f contains a single digit of precision snprintf(buf, 9, "%l.%l", i, f); // format number in buf lcd.print(buf);

Playing with RemoteTech gave me about a 75 second signal delay - I only just fixed it in time.

Very, very correct. Better option: Make sure file is owned by your user account (username ksp-linux-dedicated according to that screenshot) sudo chown ksp-linux-dedicated CKAN/registry.json Set the file permissions to something a little more reasonable - read/write for the user, read-only for everybody else chmod 644 CKAN/registry.json

Yes, that's why the code I write is under a licence that allows that. Other people have other opinions, and licence their code appropriately.

They were created to be shared on the author's terms. No, don't enforce additional licence criteria.

This was the second hit when I searched the Infernal Robotics thread for "0.22". http://forum.kerbalspaceprogram.com/threads/37707-0-90-Magic-Smoke-Industries-Infernal-Robotics-0-19-3?p=862172&highlight=0.22#post862172

Give it a bash. The KSPSerialIO plugin regex linked to has some pretty good example code to get you up and running with some indicator LEDs straight away.

I'm not sure what you mean. It's code that lets a momentary push button act as a toggle - pretty much exactly how the caps lock key on your keyboard works yes. NUM_READINGS is used in the button debouncing routine. It defines how many consecutive readings need to be high before the debounced button state is considered to be high. For my hardware, 3 is a pretty good number for a 5ms polling interval. Also, it's worth noting that this code is intended to be used for buttons that have pull-down resistors. If you're using the internal pull-up resistors on the arduino, it will only toggle state when the button is released not when it's pushed. Easiest thing to do for that sort of setup would be invert the result of the digitalRead.

I kind of want to buy one of these to play Farming Simulator. Kind of also want to buy one to butcher and use the joystick in my custom KSP panel build. That's a perfect size.

Converting is easy. A foot is 30cm and change. A yard is a metre and less change than anybody cares about. 5 miles is 8 kilometres. Seriously, eight kilometres and four metres - sorry, four yards. If that isn't exact enough for you, what were you doing using imperial units in the first place?

Check out Kanadarm.

My button handling uses some advanced concepts, but is fairly simple and, IMO, very efficient. It relies on storing button states as individual bits in larger numbers; an unsigned integer stores 16 inputs. This means a lot of bitwise math, which is hard for me to comprehend properly without my morning coffee. But it means I can latch all ten control group buttons in a few operations. First, reading in the inputs. Define a uint16_t buffer to hold the readings. Reading pins in to this buffer uses the same bit shifting code zitronen used in his example sketch. My live sketch is much more convoluted than this because I'm reading 32 pins through a multiplexed shield, so I haven't actually tested the below code. But it'll be close to working! uint16_t read_controlgroups() { uint16_t controlgroup_buf; for (int i=0; i<10; i++) { if (digitalRead(16+i)) { // first action group is on pin 16, so add that to i controlgroup_buf |= 1 << i; // bit-shift a 1 in to the buffer } else { controlgroup_buf &= ~(1 << i); // bit-shift a 0 in to the buffer } i << 6; // shift six more bits across so the first bit matches the first control group return controlgroup_buf; } To do software debouncing, I cribbed a technique from http://www.embedded.com/electronics-blogs/break-points/4024981/My-favorite-software-debouncers . Raw readings are placed in a circular buffer, and debouncing is done by a bitwise AND of all the buffer elements. #define NUM_READINGS 3 uint16_t raw_controlgroup[NUM_READINGS]; int controlgroup_idx = 0; // current index in the raw controlgroup buffer uint16_t debounce_controlgroups() { // First, read current CG status in to the buffer raw_controlgroup[controlgroup_idx] = read_controlgroups(); ++controlgroup_idx; if (controlgroup_idx == NUM_READINGS) controlgroup_idx = 0; uint16_t debounced = 0xffff; for (int i=0; i<NUM_READINGS; i++) { debounced = debounced & raw_controlgroup[i]; } return debounced; } Now for the button latching. We need to keep the last debounced state and the current debounced state. When a button's state changes from low to high, we need to flip the latched state. To figure that out I had to draw up a Karnaugh map for the first time since the late 90s, but ended up doing it like this: uint16_t cur_controlgroup = 0; // The most recent debounced controlgroup reading uint16_t last_controlgroup = 0; // The last debounced controlgroup reading uint16_t latched_controlgroup = 0; // Controlgroup state after latching button presses void latch_controlgroups() { // rotate and get new controlgroup readings last_controlgroup = cur_controlgroup; cur_controlgroup = debounce_controlgroups(); uint16_t mask; mask = ~last_controlgroup & cur_controlgroup; // Mask of all inputs that have changed between last and current mask = mask & cur_controlgroup; // Mask now only contains changed inputs that are high in current reading (and low in last) latched_controlgroup = latched_controlgroup ^ mask; // Apply mask to flip controlgroups that have changed } Set up your sketch to call latch_controlgroups() every 5ms, and the latched_controlgroup variable will contain control group states that flip on and off every time the buttons are pressed. You can just copy latched_controlgroup in to the ControlPacket.ControlGroup when you send a packet.

Hey guys, that video has a bus in it too. How dare Squad play off all of those lives lost in the Speed documentary.

I lost one just last night. :/ I play with TAC life support, and had a mission to rescue a kerbal from the Mun's surface. So I took my first Mun lander with a single-seat pod, added a probe core and radio antenna, and launched. Launch didn't go quite as efficiently as last time, and by the time I got to Mun orbit I knew I wouldn't have enough fuel to get home. But I figured I could at least get to orbit, and the pod was loaded with enough supplies to keep a kerbal alive for many weeks. The rescue site had just moved in to night, but no worries. I dropped the rescue pod about a kilometre away and EVAd the kerbal in out of the cold. A quick check of the fuel level said that I wouldn't be getting back to orbit, but even worse the life support console was telling me I only had about six hours of battery power left. That's nowhere near enough for Mun night even after shutting down all non-essential systems. I considered trying to launch retrograde and burn the last of my fuel in a suborbital hop, but would not have had enough to get back in to sunlight and successfully land again, so poor Barcus hunkered down for a cold night while an expensive and hastily-prepared rescue mission burned a very inefficient trajectory trying to get there in time. It didn't get there in time, touching down nearby a couple of hours too late. Sorry Barcus.

"1.0.2" not "1.02". Version numbers are not decimal. Sorry, I've been wanting to get that off my chest for weeks.

A fairing will probably help. I'd also consider lifting it attached to one of your other modules, with enough struts to maintain some rigidity. Also, instead of a pure puller approach, I'd try keeping the booster engines below, but putting the fuel tanks above. That'll lift the CoM at least.

My first thought was "psh, the default values shipped in the config file are what's in code". But I just checked my moving the Physics.cfg out of the game dir on my OS X laptop, launching the game to recreate it, then diffing the two, and there is one value that differs: peter@antilles:~/Library/Application Support/Steam/steamapps/common/Kerbal Space Program % mv Physics.cfg /tmp *launch game, let it get to menu screen, then immediately exit* peter@antilles:~/Library/Application Support/Steam/steamapps/common/Kerbal Space Program % diff -u /tmp/Physics.cfg Physics.cfg --- /tmp/Physics.cfg 2015-06-03 22:53:38.000000000 +1000 +++ Physics.cfg 2015-06-03 22:54:07.000000000 +1000 @@ -1,4 +1,4 @@ -dragMultiplier = 8.0 +dragMultiplier = 8 dragCubeMultiplier = 0.1 angularDragMultiplier = 2 liftMultiplier = 0.055 @@ -13,6 +13,9 @@ solarInsolationAtHome = 0.15 convectionDensityExponent = 1 convectionVelocityExponent = 3 +newtonianConvectionFactorBase = 2 +newtonianConvectionFactorTotal = 3 +newtonianVelocityExponent = 0 convectionFactorSplashed = 300 fullConvectionAreaMin = 0.2 fullToCrossSectionLerpStart = 0.8 @@ -23,9 +26,6 @@ partEmissivityExponent = 4 radiationFactor = 1 convectionFactor = 40 -newtonianConvectionFactorBase = 2 -newtonianConvectionFactorTotal = 3 -NewtonianVelocityExponent = 1.5 conductionFactor = 10 internalHeatProductionFactor = 0.03 aerodynamicHeatProductionFactor = 1 NewtonianVelocityExponent is set to 1.5 in the default config file, but in the absence of a config file the game sets it to 0. The other diffs can safely be ignored. That's unusual. EDIT: What this means is that if you want to be sure you're using the stock values * Delete Physics.cfg * Start the game, then exit it. * Edit Physics.cfg, search for NewtonianVelocityExponent, and change it to 1.5.

Actually, just putting the extracted folder in your GameData should just work. If that hasn't, a precise description of what you did (screenshots of your GameData are helpful) and startup logs will help narrow down what's wrong. Check the sticky posts in this forum for how to get as much useful info as possible. You might also want to check out mod managers. I use CKAN all the time, but there's a few other KSP-specific managers in the tools and applications subforum.

That is a vague possibility. Do you really think that it's worth manually auditing every page just to put a banner on instead of updating everything properly though?

The easiest way to check if a page is current is to look at the last modified date. Unfortunately that's currently in smallish type at the very bottom of the page. Anything modified after the 1st of May is almost certainly accurate. Last modified dates between 27th of April and 1st of May could be OK, but there have been some tweaks to aero between 1.0 and the most recent release. Anything before the 27th refers to considerably older versions. I think that's the best indication you're going to get for now. But I will point out that anybody can register a wiki account and add banners like the one on that second link to pages they notice are outdated.

First time it happened to me. The clamps were attached to a couple of Hammers, yeah. The SRBs were dropped long before I got suborbital though - I assumed it was fairing debris that mutated.

Not struts, but I'm still not sure how this happened.

In two and a bit years, maybe half a dozen. I'm very careful with my Kerbals.

What is the problem?

The wiki gives Kerbal's height as around 75cm. That's about hip level for my 175cm height. Yeah, that's the original Mk1 pod, which as I understand was the same size as the new Mk1 - 1.25m diameter.