stibbons

I've been (*gasp*) playing without this for the last little while, my controller is partially disassembled waiting for me to rebuild chunks of it. The former. Treat it as a single uint16_t (because that's literally what it is) and iterate through bits 0-9.

I never keep old versions. 1.1.2 worked ok. 1.1.3 works better. Looking forward to 1.2.

WHEEL_WEIGHT_STRESS_MULTIPLIER and WHEEL_SLIP_STRESS_MULTIPLIER in settings.cfg. I would assume you'd set them both to 0 to completely disable.

To add to the common mods, FAR, KIS, BAC. Possibly EVE (although case sensitivity could be an issue) and AVP. CKAN is worthy, and AVC bit me just the other day. Ap and Pe, AN and DN match what's used in-game. Inc, ecc, SMA are more obscure but possibly helpful. ISP is the only addition I can think of to TWR. COL, COM, COD. AoA may only be relevant to the air-breathing crowd, not sure. LKO, HKO for different Kerbin orbits. I'm not sure if people use KSO or similar much, I tend to just refer to those orbits as synchronous (or stationary if I'm really careful with them). KSC, KSC2 are the only places I can think of.

I try hard to not generate debris in the first place. The first stage is planned to be not quite orbital. For missions in the Kerbin system, I plan the transfer to either intercept the target or come around on a free return and intercept Kerbin. Either way the upper stage only needs minor correction and there's no debris. Less experienced with interplanetary missions, but the few I've done have also had transfer stages that were either dropped to the surface or deliberately left in orbit as Remotetech relays.

When I don't want to be accessible I ignore calls and messages. But that's up to me to decide, not my tech and certainly not anybody else.

I didn't put my Pebble on this morning. Have been missing calls and messages all day. May have to resort to something as drastic as turning the ringer on.

The thing I don't like about that switch is that it's latching. When you hit it, it needs to be twisted to unlatch and open again. But you can find a lot of similar-looking non-latching ones by asking eBay for "mushroom switch".

My desktop machine dual-boots Windows 10 and Linux. It gets a full shutdown (not hibernation at all) when I'm not using it. I have two OS X laptops, a work and personal machine. I put them to sleep when I'm not using them (just shut the lid), but will need a reboot, oh, maybe once a month give or take. I know it needs a reboot when the wifi adaptor stops seeing available networks on wakeup, or the machine wakes up and goes back to sleep again, or something similarly screwy happens. Shut it down, start up again, everything back to normal. I haven't had to run Windows servers professionally for a while, but when I did they only needed to be rebooted after patching. They were no more or less reliable than the Linux servers sitting in the same racks.

Hi please let me know where I expressed an opinion one way or the other on what was written.

*senryu. Although I suspect zappai might be even more appropriate.

50m/s is 180km/hr, or a bit over 110 miles/hr for the metrically challenged. I wouldn't want to taxi that fast on a dirt road no matter what wheels I've got underneath me.

Aaand between when I last looked at that video five days ago and today, comments have been disabled on it. Oops.

If you dig through this thread, and the professional/educational threads linked in it, you'll find quite a few senior and retiree users.

I'm not sure you did.

I think it's quite hard to achieve that, except you are using exclusively matrix drivers like the MAX7219 with a digital brightness control feature. A hardware solution with a main PWM signal controlling a bunch of transistors connected by much more wires could also work Yeah, for the MAX7219 drivers I'm already setting a very low brightness. And the other LEDs are also under digital control and driven using the FastLED library. FastLED does the hard work scaling colour values down for lower brightness. I'm already driving most of the displays with quite low brightness, and then use photographic tricks to make the colours appear brighter in pictures. Tempted to redesign the displays a little to include dim covers. Nope, I hadn't heard of it before, but it looks pretty nice. I had a lot of problems getting I2C to work, because the built in Arduino libraries for it aren't well suited to the data rates KSPSerialIO needs. I wrote my own I2C driver libraries instead. See this post for a longer explanation about how and why.

I've never played a career without TAC-LS. And I've never sent a manned mission further than a couple of asteroid intercepts just outside Kerbin SOI. These two facts are... not entirely unrelated.

There's been discussion about it recently, and I think "The Firefly Verse consists of one central star, which is orbited by 4 other stars, 7 artificial or proto-stars, and about 260 planets and moons" explains why it hasn't been done.

"What is the mechanism to straighten it out?" he asks, while the grid fins are clearly visible and moving to adjust attitude. Gosh.

Hah. I don't remember why I picked blue way back at the start of this project. I think it came down to which colours the big seven segment displays were available in, and the blue one looked nicest. I still have plans to add a display brightness control, but so far I've found that the hard wired brightness I have set now seems to work well under all lighting conditions I play the game in. No. A single Mega would probably be OK for this many controls and LEDs, but definitely can't drive the display as well. I'm using three different microcontrollers An Arduino Mega for the serial connection to my computer, and it has all of the inputs connected to it. An Arduino Leonardo (a pro micro board), which controls all of the LEDs and outputs. A Teensy that just drives the TFT screen. Rendering the navball takes some pretty serious processing. I'm using I2C to send data to all three controllers. The Mega acts as an I2C master, and whenever it receives a data packet from the game it sends that packet to all of the slaves. The slaves then display information out of the data packet in their own time.

I believe the thread you're thinking of is this one.

Dang, sorry the update didn't come through. Better luck next week!

I'm going by what is documented in the unofficial KSP API docs: They have an automatically generated list of all of the public objects available, and user-provided documentation on how those objects work. The ManeuverNode class just plain doesn't export any information about estimated burn time. I even took a quick glance at the source for the BetterBurnTime mod, and it looks like the mod is doing exactly what I mentioned above; tracking engines in the current stage, adding up total thrust, and calculating burn time base on current dV. As for defining a "node is being edited" state, still no idea. But, poking around the API a little more, I suppose one could in theory hook in to the OnGizmoUpdated callback on the Maneuver Gizmo, and record the current dV after updating as "total" for the node.

The game doesn't export anything relating to starting or "total" dV for a maneuver (that I could see, would love to be corrected). And I wasn't satisfied with any of the heuristics I could come up with in half an hour of pondering when this last came up a couple weeks ago. Estimated burn time would have to be calculated plugin side, based on maneuver delta V and thrust available in the current stage. But it's not impossible. That's the thing: How do you tell when the node isn't being adjusted? The best I've come up with is a collection of naive assumptions working together. dV only increases via manipulation. If dV remains stable for n seconds, assume the node isn't being manipulated any more (I personally hate this one). Start doing complex and expensive measurements of the rate of change and make assumptions about maximum thrust / how finely people are able to tune nodes. Assume a dead zone around 0. All of that feels so much more messy and error-prone than just putting a lock toggle on the side of the dV display.

That's a really nice build! Would be keen to see what information you're displaying in the different modes as well. That sounds similar to the EngNumber library I threw together for my controller. It converts numbers to engineering notation - scientific notation modified so the exponent is always a power of three - with a fixed number of significant digits. Very little of that library is my code. It mostly came from a discussion on the arduino mailing list about enhancing the print code (see the readme for full attribution). So the inner loops are written in inline assembly and are scary fast. Right now it's hardcoded for four-digit displays, but I'd be happy to generalise it a little more if there's interest.