LRTNZ

One option, albeit slightly janky, would be to use a couple of cheap Arduino Megas. Just have your debug stuff be spit out of Serial1 on your controller Mega, and read into Serial1 on the debug message repeater. Then just send the stuff read in from serial1 on the message repeater out of the normal serial connection to a serial monitor on your computer.

@TygurDuck The big issue is that you are running blocking code - this is where you prevent the processor from doing anything else, as it is stuck in a delay. @Mofates your demo code using the boolean operators and the timer code is how I would recommend to do it. There is one really big issue though - that is, you have about 65 seconds of useful time to use it, before you will probably encounter some really weird timing bugs, when lastBlink rolls over back to zero. An unsigned int on an arduino has a maximum value of 65,535. As you are storing milliseconds, that comes to just over a minute, until it rolls over. You need to be using an unsigned long, which can hold a maximum value of 4,294,967,295 - if you manage to exceed that, you really need to stop playing

@madradhu What do you mean by simply references in the log? Could you provide a copy of the log file somewhere for us to look over to see what the issue may be? Have you checked the serial port the Arduino is connected to is not in use by another program? Is the serial port the Arduino is using defined as the serial port in the config file for Kerbal simpit?

I don't know when the last time any dev work on this was done? I submitted a pull request a while back and am not sure if that has been pulled in yet. I may have a look at this in a week or two when I have some spare time, and see about getting the mod updated.

@YuppeeMusings have you tried testing the joysticks on their own, without ksp? I would advise looking at directly printing the value of each of the axis, one at a time to the ide terminal and seeing how the values behave. That way, we can eliminate all the other potential variables that ksp introduces, and only work with the bare minimum of variables.

I forgot to add a few details in regards to the behaviour of the serial port attaching and detaching while the game is running. When the serial port is detached completely from the game on KSPs side of things, for it to reattach you need to leave and reenter the flight scene when you reconnect it. You can reconnect the serial port in the flight scene before you leave it, or once you have left it but before returning to it. The requirement though is at some point after reconnecting the serial port, for it to have its controls applied, you must have refreshed the flight scene. From memory, I think this is due to when the computer side of the code checks what gamescene/view the player is currently in when it goes to attach the commands, nothing to do with the arduino's code. Also, it could possibly be partially due to how I have the code terminating the running workers when the serial port is disconnected, with one of those potentially responsible for passing the users control panel input to KSP. I will look into this some more, and see if there is a way to reconnect the command passing from the add on to ksp, without the need to refresh the flight game view. However, I will look at this, after I get the ports automatically connecting upon startup. I may look into how the config files are read, because maybe it should be a config option for the user to choose whether or not they want the port automatically connecting upon startup? For the automatic reconnection, I suspect I just need to change the code so there is a one time call when the game starts to the serial command to try start the connection. I will most likely keep the serial command responsible for the creation of the KSPit instance, as it does mean the commands I have implemented are in control of the serial ports, and it does not run the risk of having 2 instances of the KSPit class trying to talk to the serial port/s. Although, if anybody with more experience in these matters has a better idea/s, I am all ears, and game to implement it if it will result in a better outcome. I have not tried the subscribing and unsubscribing on the arduino yet, however I do not see why my changes would have affected that in any way. I must say, of the arduino code I have used, the arduino library has all been wonderful, with the only issues having been computer side from the visual studio arduino plugin taking over the serial ports, even when it had never been told to connect.... So that plugin is disabled, and I am just using the arduino ide. On a side note, my mate @meh? does have some free time to do more German translating, if you would like him to do it for the verbose terminal outputs you have in the code? Would only take me about half an hour to find them all, and add them to the English localisation file, which can then be translated. Is this effort worthwhile, or do you think it may be to futile to worry about?

@stibbons Well, I do have the commands working now. They are still in their early stages of development, but the framework is now all there. I did submit a pull request for review the other day, so that you and others can take a look at the code, and offer suggestions on what may need to be adjusted for it to be added to the main branch. I am planning to start more development on my actual simpit, so I will probally shift towards the hardware/Arduino side of things for the next little while. However, if there are issues with my code/you would like me to change and work on some things I am more than happy to do so ( Will give me something to do while waiting for my 3D printer to print out prototyping parts for my simpit). Also, if I find any issues with my terminal command code while developing my simpit, I will be sure to submit a pull request for a bugfix. Depending on the reception by the users of your addon to the addition of the commands, and if people do find them useful, I may potentially end up developing an in game GUI button/panel for those who would rather not use the debug console. Something else that is worth noting with the serial stopping and starting: When you have disconnected the serial port from the game, the Arduino IDE can then claim it and program the device. However, once the Arduino IDE has programmed the device, you need to press the reset button on the device that has just been programmed, so that it's serial port is properly released from the IDE, before trying to reconnect it to KSP. Also, if you disconnect the serial port from KSP while in a flight, you cannot reconnect the device and have it take over the flight controls without having left and re-entered the flight view. I assume this is due to when KSP attaches the controls to a vessel, and I am yet to look into the code enough to see if there is a possible fix.

@stibbons Just a brief update: I am taking a tad longer than I expected to get the code in a state that I consider good enough state to be considered for implementing into a releasable version. Mainly due to that fact that as I am learning c# while programming the commands, I have ended up finding better ways to do most things, and have then gone and reworked chunks of code. I also may have implemented localisation to my code, and the commands. That actually was not to bad to do, once I worked out the way I think is best in our case to store the tags for the localizer. It also meant that I had to rework some of the code for processing the commands, which actually resulted in it being more reliable, cleaner, and more flexible to running without being dependent on the values for commands being hardcoded in, as to be localised they need to be in the localisation file. Anyway, all my code that puts anything into the terminal has an English localisation , and my mate @meh? has just translated it into German, which I will test tomorrow. I have gotten the serial port code extracted from the start method, into its own method, and have it being called by a command. The testing of that code is a job for tomorrow. Fingers crossed it all goes well, and that I have the code in a state to be pulled in, so everyone can begin trialling the commands.

@stibbons Well, I seem to be picking it up okay. The general consensus of once you have done programming with a common OOP language, working with another will not be to hard seems to be holding true. Not to mention learning it is handy for me, as I will need it in my final year of secondary education next year, then probally at uni as well. Sweet, because I am hopefully going to get these commands going soon, and hopefully my code opens up new doorways to simplify future development for everyone. I found this example on the usage of the terminal commands, and have spent the past day and a bit just converting that code over to something that will work for this plugin. The terminal commands are surprisingly easy to add ( Well, having never worked with KSP addons before, I am going off experience with other programming), as long as you remember to add their ".cs" files to the serial ".csproj" file so they get compiled into the dll… . Yeah, that took me a bit longer than I care to admit to work out. Okay, okay , I think it may have been an hour … or two before I facepalmed. Currently, I have help commands running, in the form "/sim help <command>" I have settled on "sim" as the "identifier"(? or whatever the correct term is for it) for the commands that I am developing, although it is easy enough to change it if so required. I am going to start attacking the serial start/stop commands tomorrow ( Well, more like later today ), and if all goes well I may have a very WIP version submitted in the next couple of days. I actually did not find it to bad to get going. After having tried Visual Studio by itself to no avail, I then tried VS Code. I gave up on that, as trying to program without having the ability to "go to definition" was going to make things a nightmare. Anyway, went back to Visual Studio, and it just worked with importing the existing code as a project. However, the second time I tried it, I had pulled the repo down again, having deleted it locally, so that is probally what did it. To compile, I am just running the makefile using "GNU make" running on a Debian Linux Shell( Purely personal preference, as it is the distro that I regularly use if I am not on Windows 10), with the install option to have the DLLs automatically get moved to the games install location. Thank you for including that [ the install argument ], it has greatly simplified the building and testing process. To those who want to develop this code in an IDE, I recommend going the route that was recommended here. For Win 10 users: I enabled the Windows Linux Feature, installed the Debian GNU/Linux shell from the windows store, and then installed the recommended packages. I then setup symlinks from the required sections in the KSP install to the main project file at the same level as the makefile. Following this, I then edited the makefile to use the local symlinks in the project folder, instead of having them recurse from the top of the install drive, to the game files. NB: BEFORE attempting to install the packages, you need to edit the "sources.list" file, to have the source links be "trusty main restricted". I am not sure on the reasoning, I just know that without that it will REFUSE to install the packages. I think it was more to do with the shell running on windows than anything, from what I briefly read. @stibbons Would it be worth looking into a documentation tool like doxygen for this project? This may make it easier for multiple people to keep track of the code structure, as well as making it easier for other people to come onboard and work with the code in the future? I have never worked with a documentation tool like that before, but to my understanding doxygen is one of the more commonly used ones for generating documentation for projects? Sweet! This should definitely make it easier for all of us to keep track of what is going on/needs fixing!

@stibbons Having looked around some more, I think I may have found a simpler solution for the serial stream: To just add a command to the in game debug terminal. Now, my C# programming experience is next to none, only having used it for some very basic things in a unity project I was tinkering with. However, as I am currently have a few months of holiday I am quite happy to have a go at getting the terminal command going ( Just will have to learn C# to do it, something I have been meaning to do anyway) If I do get the command functioning would you be happy to take the code and change it to match your preferred syntax/stylising and add it to your main code? This is just so I know whether to approach it as "Its just me using it, I can deal with it being bodged and hacky" ,vs "Ok, got to get it right, other people are potentially using it". On a side note, is it possible to enable an issue tracker on the repository itself, to keep track of issues and suggestions in the same location as the code?

Okay, I have just had some time to look over the code, to see about adding in a way to terminate and reopen a serial connection, without restarting the game/mod. @stibbons is it possible to break out the code currently in the start method that is responsible for calling the various commands and functions to create and initialise the serial port, into its own function? This function could then be used to initialise the various data structures to be in the required state to create a new serial connection, and then start the connection. Something similar could also be used for the termination of the port? These methods could then possibly be linked to a simple toggle button in game, that can be used to toggle the connection status.

@codapop I second the simple on/off button. I am currently planning my own control panel now and hope to get started within the next few days. From previous experience with arduino, being able to have a disconnection/reconnection option available without restarting programs is a godsend. Going from prior experience in python, implementing a disconnect/reconnect feature is just a matter of reworking the initial start connection and end connection code. I may have a look at the code in more detail tomorrow, and see if I can work out at least some psuedocode for potential implementation.