stibbons

Yep, truly loving how much work we put in to spoiling everybody's fun.

I'm impressed with how thoroughly we're all destroying a fun thought exercise right now. Great job team.

Unfortunately, removing 32 bit support in the most recent macOS releases means the CKAN GUI is no longer functional. The reasons behind that are a little byzantine, but there it is. If you're running High Sierra (10.13) or older, CKAN will launch and run normally. But in Catalina or later you're restricted to command-line or consoleui use. The consoleui works for most things, but requires a little bit of familiarity with using Terminal, and is just outright a little bit strange if you're not used to this style of app. To run CKAN in consoleui mode on macOS, download the CKAN.dmg installer, open it, and drag the CKAN app in to your Applications folder as normal. Then run Terminal, and in the terminal window, type /Applications/CKAN.app/Contents/MacOS/CKAN consoleui

Wait am I even still called a system administrator? I thought I'd been retconned to "devops engineer".

Yep. The Unix epoch is 00:00 on 1st of January 1970 UTC. If you're in a negative timezone, which basically just means the Americas, then that will display as December 31, 1969.

`KSP.app` is an application bundle, a folder that contains the executable and all of its related resources in a well-defined layout that the operating system treats as a single application. If you're navigating around using a commandline, you can just `cd` in to it. In Finder, right click and select "Show package contents". The path that you want should be `KSP.app/Contents/Resources/Data/Managed`

Gah, I forgot the one other thing fairly simple thing you can try to test this theory, without having to recompile your controller fimrware. It might be worth experimenting with the RefreshRate in the config file. The default is 125 milliseconds, maybe try doubling that to 250 and see how you go.

Now the harder stuff. I do not know why. Yet. But let me ask the stupid questions: what exactly do you mean by unresponsive? Does it just stop updating LEDs? Does it just stop sending data from your joysticks? Is it both? Does it catch fire (OK maybe not, but I definitely had a small fire on my controller thanks to a shorted LED at one point)? My first thought was maybe you were leaking memory somehow and the arduino was resetting. But that doesn't seem likely - you've got a lot of free RAM, and I don't see any obvious leaks in this code (although there might be some in the library?). And you're also turning all of your LEDs on in your init. If the arduino was resetting then your board would light up. So that's not it. Your thinking around the volume of info getting from the game to your mega is overloading things could be right. I think that would mean that the serial buffer on your Arduino is filling up faster than your sketch is able to read it. You can check that! The serial buffer should be 64 bytes, I think, and `Serial.available()` will tell you how many bytes are in the buffer. So you could temporarily repurpose one of your LEDs and use it to tell you if the buffer ever gets full. Remove the code from messageHandler that updates your Brake LED (because nobody should ever be using the brakes, gosh!), and then put something like this at the top of your loop(). Note that the best place for it is right before you call the simpit update, because that's the fullest the buffer will get. // The serial receive buffer should be 64 bytes. // Check how much is there, and flip a warning light on if we've filled it: if (Serial.available() > 63) { digitalWrite(BRAKES_LED, HIGH); } And then play until your board stops. If the brake light comes on at any point there, then you know to blame the buffer. Finally, you can also get more logging out of the game. It's worth turning on the debug flag in the Kerbal Simpit config file. Play until you get the problem, and then upload the KSP.log file somewhere I can get to it. With the debug flag on, Simpit logs a lot. You should be able to find messages from it by just searching the log file for "KerbalSimpit".

Hey mate. Sorry you've been having troubles. Let me start with the easiest stuff first: I'm not familiar with rotary encoders at all tbh, but I assume you're using the library at https://github.com/brianlow/Rotary to work with it (that's the one I installed in my IDE to get your sketch to compile). You're right, the first thing to check is that it actually works at all. If it were me I'd test it with one of the Rotary library examples - it looks like your code basically replicates what the Polling example does. After that, I'd be thinking about whether or not turning rotary encoder events are just getting lost because your code is so busy doing other things that it can't poll fast enough. Did it just recently stop working after you had the rest of your setup finalised? Or did it stop somewhere along the way of adding more functionality to your sketch? It might be that you have to delve in to figuring out how to use interrupts to do some processing of events from your encoders. That said, I can't see anything wrong with your code, but I do have some suggestions! Your SAS calls, like mySimpit.send(28, (unsigned char*) &sas_Counter, 1); // sends the new SAS mode setting to Simpit feel clumsy. Do you really need to use the pointers there? I thought just `mySimpit.send(28, sas_Counter, 1);` would work. And, indeed, I had to change the code to that to make it compile on my local machine using Arduino 1.8.3 and Simpit 1.4.0. Haven't actually run it though. Your joystick read routines will be slightly faster with a series of if/else statements rather than just ifs. Like this int rot_Y_Read = analogRead(ROT_Y); if (rot_Y_Read < 518 && rot_Y_Read > 508) { rot_Y_Mapped = 0; } else if (rot_Y_Read <= 508) { rot_Y_Mapped = map(rot_Y_Read, 344, 508, -32768, 0); } else if (rot_Y_Read >= 518) { rot_Y_Mapped = map(rot_Y_Read, 518, 680, 0, 32767); } The only other thing I'll say is that digitalWrite is surprisingly slow. Your messageHandler currently writes every single action LED whenever you get an ACTIONSTATUS message. If you keep variables tracking what the LED currently is, you can write messageHandler so it only updates the LED if it changes. Something like // First we need a global variable to remember SAS state: int sasActive = 0; // You could use a shorter type here if you're tight on space. // Then we do this in messageHandler: // Check if SAS_ACTION in our actions packet matches what we remember. // If not, remember the current value and write it to the LED. if (actions & SAS_ACTION != sasActive) { sasActive = actions & SAS_ACTION; digitalWrite(SAS_LED, sasActive); } // no else required any more! OK. That's the easy stuff.

OBS

It isn't.

To answer a fairly old question: yes, without ARP the resource channels will not be sent at all. I'll make sure the documentation is clearer on this. Getting stage and vessel resources isn't exactly a trivial thing - there's some calculation involved. Rather than reinvent the wheel I chose to use the very tidy API that Alternate Resources Panel provides for its data. (for bonus points, even though simpit only supports stock resources, using ARP makes it really really easy to write a companion plugin for modded resources)

What's a space camp?

I've spent a week waiting for somebody to point out the misspelling here, and now I'm worried that it's actually some sort of forum in-joke that I've managed to miss out on. But, to be fair, Mr. Hadfield does rock a good hat.

<kerbalised voice-over>It was</kerbalised voice-over>

Because I happened to be awake at the right time, version 1.4.1 is available, built against KSP 1.10.0. Should pop up in the next CKAN index run.

Back after an extended break from all things Kerbal with some small maintenance releases. Arduino library is now up to 1.4.0. This release has some minor changes to the function definitions, to work with recent Arduino releases. I've tested with Arduino 1.8.13, on macOS. Kerbal Simpit plugin has been updated to (coincidentally) 1.4.0 as well. This release builds against KSP 1.9.1, and removes a lot of old code that's now bundled with Unity. CKAN and AVC should find the new plugin now. Arduino is waiting for a library manager rescan, and I promise for sure I'll actually check to make sure it updated tomorrow. No real changes apart from just blowing off the dust, but I expect to find some time to catch up a little more in coming weeks.

Found out about Curtas via William Gibson, and I'm also in the "gosh maybe I could sell a kidney to buy one of those" camp.

Meanwhile, parts of Australia casually sauntered past 48°C (118 and change in the old scale) over the last few weeks. The weather station in my yard has only (only?!) hit a top of 44 this month, and I'm counting myself fortunate.

A non-exhaustive list of mods that can help: Telemachus can send telemetry over a websocket. kRPC provides telemetry and full RPC control over a protobuf interface. It has Python and C++ client libraries, amongst others. KSPSerialIO and Kerbal Simpit can also be used to get telemetry out of the game, but both are limited to serial ports only. I like them (obviously), but they may not be the best choice if you're building a Pi-based interface.

My first change to somebody else's mod was a small patch for chatterer, to play a sound file when a vessel first launches. Because obviously. I don't think it was ever merged. After that came a handful of changes to KSPSerialIO, adding functionality for things I wanted to be able to do. And, eventually, I started writing my own serial mod, based on alternative ideas for a lighter weight serial protocol, and because I got tired of maintaining a fork of the code for Linux.

I suspect you're misinterpreting the question. Can MechJeb successfully dock with a vessel currently landed on a low gravity moon like Pol?

I was curious about that too. The FAQ entry I pasted above names 20th March 2013, and Wikipedia agrees. So I dug up the Steam announcement at https://store.steampowered.com/news/10192/ and it's definitely March for the first Early Access release. That'd be 0.19.1, released a couple days before on the 18th. The confusion probably came about because the oldest package steamdb has seems to be November.

If it's not available through the KSP store, then I suspect your only legal option is to buy a Steam key.