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.