stibbons

Apologies, it is on CKAN, but travel and some other commitments over the last couple of months meant the latest release was marked for KSP 1.4.4. I've just pushed an update for KSP 1.5.1, CKAN will have it shortly. ACTIONSTATUS_MESSAGE only works for regular action groups - see the documentation for what it supports. Currently the plugin does not send the status of regular action groups. But it makes sense to also be able to subscribe to custom action group notifications. I'll add that to the backlog (and I promise I'll actually do some work on the backlog soon). Odd. I've tested the Arduino library with multiple hardware serial ports on an Arduino Mega and Leonardo boards. And I've tested it works with SoftwareSerial. But haven't tried it with the Due. I don't yet have an answer, but will look in to it. I haven't personally tested it, but it should be getting the correct names for all non-stock planets, yes.

For surprisingly small values of "we", undoubtedly.

Sorry, who did that? Where?

Sure. If you dig around in the fan works forum you should find a couple of controllers built like this. I'd steer clear of cheaper keyboards with membrane switches, the contacts will be especially annoying to solder to.

In general it's a good option, yes. But right now your system is set up with /boot outside the LVM. Once upon a time the bootloader was unable to read kernels from LVM volumes, so a separate partition to boot from was required. That's no longer the case, but I don't know if the Ubuntu installer still defaults to that layout or not. At any rate, resizing that partition isn't really an option for you unfortunately. The two main causes of this I've seen were reserved space on the filesystem, and open file handles for deleted files. The EXT filesystem allows to reserve disk space that can only be written to by the superuser (root). From the mke2fs man page: The numbers in your screen shot don't seem to line up to account for this. But just in case, it may be worth checking the reserved block count by using the `dumpe2fs` command, which will dump information about the filesystem including the reserved blocks percentage, and the `tune2fs` command to (slightly) decrease the percentage on the filesystem. You're only a little short, so if it's set to 5%, changing it to 3 or 4 should see you clear for now. Secondly, if one process has a file open and another process deletes it, the file will still be taking up space on the filesystem even though it can't be seen via ls or with disk space reporting tools. You can use tools like `lsof` to look for open files on the /boot filesystem, or if your machine has been running for a long time it may be easier to just reboot. Seeing as the upgrade tool is reporting a 1KB difference, it may also just be because of block size issues. Easiest way? Look at what's in /boot and clean it up. 242MB seems like a lot. I don't have an Ubuntu machine handy, but my Debian home server has the currently running kernel and a backup of the previous version, and right now it's taking up 43MB. Use apt to see what kernel packages (if Ubuntu is still similar to Debian, you can search for `linux-image-*` packages) are installed, and remove old ones. Even just removing one should get you under the limit.

Also not supported in the Windows build. This visual bug did exist in previous 1.4.x releases on Linux and macOS. But I just fired up 1.4.5 on my macOS machine and it's working OK there. I don't have access to my Linux box because I'm on the wrong continent, but pretty sure it's fixed there too. If you can replicate OpenGL problems on platforms where it's the default renderer, then it's worth filing a bug about. But issues with the OpenGL renderer that are exclusive to Windows almost certainly won't be looked at because, as linuxgurugamer said, Squad don't support that setup.

But will it blend? (also, maybe consider a spoiler tag?)

The process of breaking source code down to tokens is known as lexing. Once that is done, a parser assigns meaning to the tokens. Here's a reasonable high-level overview of how one might go about defining a new programming language and creating the tools to work with it: https://medium.freecodecamp.org/the-programming-language-pipeline-91d3f449c919

Oh boy. "Gender and biological sex are not the same thing" is definitely not where I expected this thread to go. But here we are.

Read https://github.com/ihsoft/KIS/wiki/Troubleshooting . You don't have it installed correctly, and only having 1L volume is a symptom.

That's not a version number.

What version of the game do you have installed? What version of the making history expansion do you have installed? The title screen should show you both in the bottom right corner. Are there any likely-looking errors in your log file?

Pretty sure you weren't expecting a serious answer. But you're getting one! The Intellimouse series introduced a lot of crazy new stuff. The original Intellimouse was almost the first to include a scroll wheel. The Intellimouse Explorer was the first time anybody was able to build an optical mouse that didn't rely on a special pad, and I think it was also the first with auxiliary buttons on the side. I loved my Explorer, back in the day. Huge, chunky, heavy, and oh so smooth. Lasted a long time too. Microsoft really knew how to make hardware, once upon a time.

The API for the game is at https://www.kerbalspaceprogram.com/api/index.html . If you dig around in either the Vessel or Orbit classes you should be able to find information about current prograde and other orbital information. Looking at how the current vessel heading code works in the KSPSerialIO plugin is valuable as well. A rough overview of what you need to do: Get a vector for the direction you're interested in, say orbital prograde. Transform that vector so that it's relative to a fixed reference point - from memory the current code that does this for the active vessel heading uses the world normal. Then you need to transform that vector to a set of Euler angles. The Euler angles are what you should report to the client. There's been a couple of projects that can take the Euler angles being reported for vessel attitude and render a software navball, the code for mine is based on catmacey's project. It's applying the rotations to a 3D rendering of a navball, but should give you an idea of a client implementation for a real one too. I've had a few stabs at adding the information you're looking for, but always fell down - getting my head around the Unity-specific bits, and 3D programming in general, proved to be too much to handle on my own. But I wish you well if you want to give it a try!

And, for a bonus, I've just pushed version 1.1.5 of the Kerbal Sim Pit Arduino library. Not a lot in here, but it fixes some dumb bugs and hopefully will make the library a lot more stable for busier controllers now.

Asked and answered in the FAQ. Unless you bought it very early in the piece, basically before it was available on Steam, you won't be able to transfer:

Breaking my surprisingly long KSP hiatus for a little bit to kick things along for KSP 1.4.4. I've pushed a new release, no significant changes apart from a rebuild. Work on a 2.0 version that revamps the serial protocol is slow but... kinda steady. I do plan on spending some time this weekend tweaking the current Arduino library though, time and experience have given me a few ideas for improvement. Ahahaha, this is fantastic! Nice work. How are you doing the serial connection? Hooking in to the Pi's UART? ETA: @cjohannsen I've actually documented how the serial protocol works, at https://bitbucket.org/pjhardy/kerbalsimpit/wiki/PluginHacking.md . If there's still any gaps in how you understand it please do let me know and I'll be happy to fill you in.

Good news first, the CKAN client can indeed easily manage multiple different KSP installs. See the user guide for some direction on adding new installs. Doing this at runtime isn't really possible with the way KSP is designed right now. All of the models and addons are loaded once at startup, and there's no real way to add/remove them dynamically once it's running (there was a mod that could load/unload textures on demand, but it hasn't been maintained for some time). You may be interested in Game Data Switcher. It's an external program that lets you manage separate GameData folder sets. Requires quitting the game and running GDS to swap between folder sets for different saves, but it's another option that seems to work well.

I already rely on Alternate Resource Panel for resource fetching, which can indeed handle modded resources easily enough. The problem is how to expose that through Simpit. I'm wary of hardcoding non-stock resources, mostly because I worry it will be a never ending game of hide and seek. I don't yet know of a good, flexible, robust way to let a Simpit client request arbitrary resources though. It may come down to mapping resource IDs and channel IDs in the Simpit config file. I'll make some time to verify this today. But just to confirm, what does your hardware look like? It's intended to work with a momentary button, with a pulldown resistor, see the example on the Arduino debounce tutorial page: Pushing the button sends buttonState HIGH, and releasing it should set buttonState back to LOW. The sketch should also be turning the Arduino's built-in LED on while the button is held down.

Oh yep. catmacey posted a link to their github repo with that code, and I'm using a modified version of it to drive my navball. A Uno will let you do similar at an acceptable rate. Biggest advantage to the teensy and better controller in my setup is that I'm able to drop in a higher quality model with a bunch more vertices. Yep yep. All of the stock resource types are accessible. Working from memory, and haven't tried this code, but you want to do something like this: #include "KerbalSimpit.h" KerbalSimpit mySimpit(Serial); void setup() { // Initialise the serial connection Serial.begin(115200); pinMode(LED_BUILTIN, OUTPUT); digitalWrite(LED_BUILTIN, HIGH); while (!mySimpit.init()) { delay(100); } digitalWrite(LED_BUILTIN, LOW); // Register a message handler mySimpit.inboundHandler(messageHandler); // Request data about total available liquid fuel mySimpit.registerChannel(LF_MESSAGE); } void loop() { mySimpit.update(); } void messageHandler(byte messageType, byte msg[], byte msgSize) { switch(messageType) { case LF_MESSAGE: if (if msgSize == sizeof(resourceMessage)) { resourceMessage myLF; myLF parseResource(msg); // myLF now contains a resource message, with // total capacity and current available amounts float totalLF = myLF.total; float availableLF = myLF.available; // etc } } } There should be message types for all of the stock resources (including EVA fuel). They all are standard resourceMessages, and can be processed in the same way.

Yes, and yes. The current resource provider does hard code the resources it knows about. Somewhere on my todo list is a more generic option that will let the user specify what resource ID they want. But I haven't yet figured out a nice way to fit that in to the design. If you want to get your hands dirty writing your own KSP plugin, a new provider that interfaces with Kerbal Simpit and returns the resources you want shouldn't be too difficult.

And by "working" it's still a case of rendering the navball but none of the assorted velocity markers one expects to see on it. The teensy is useful, and can comfortably render my ball at 30fps. My earlier tests were on an Arduino Uno, with lower quality, and it seemed to cope quite well at the 12.5fps I push packets out of the game (that's sending a packet every 80ms). Mine is a larger display, but also has a much smarter display driver. I only have to send a command to "draw a line between these two points" to the driver, and it's responsible for flipping individual pixels. Doing a lot more of the rendering work in your Arduino is going to be a bit more taxing. Can't wait to hear how you go with it though! <3 What would you like to see that's missing? I'm easing back in to writing code by rejigging the serial backend, but would love to get back in to doing fun things with the KSP API too.

It's in the FAQ.

This one was, again, a very small update, rebuilding for KSP 1.4.3. Should be available shortly. In related news, the Arduino Library Manager has once again started indexing my Arduino library properly. I've started work on a fairly major update, replacing the serial protocol for something that I'm hoping will be a lot more reliable. This will also include some minor but breaking changes in how smaller packets are handled. So look for a version 2.0 of everything in the next few weeks. Please install using CKAN. I don't support manually installing the mod.

*yawn* Your entire contribution to this thread has been about how terrible it is that KSP doesn't include tools that you think are necessary, while roundly denouncing everybody pointing out that it's not only possible but not that hard to get by without them. But sure, argue semantics if you must.