This project attempts to construct a collection of KOS scripts to automate control of vessels in KSP.
My goal here is to enjoy the process of building an autopilot with a growing collection of capabilities, including combining them into automating entire missions.
Now, finally, in 2024, I am tinkering with RP-1 and want to
make use of kOS and my farkos code to do automation. Since
this has been “off my mind” for almost a year, I have of course
forgotten all the details of farkos and kOS in general,
so revisiting this code gives me a chance to think about what
documentation (and testing) needs to be added.
After some tinkering, I have arranged farkos so that /home
continues to hold scripts for unmodified KSP, and /rp1 contains
the scripts for RP-1 flights. The Ships-RP1 tree will from
time to time receive snapshots of my craft files.
Source files will be run from ARCHIVE as needed. This means it will be important to maintain communication with all vessels.
This reduces the pressure on local storage.
Local storage will be reserved for persisting values relating to the state of the mission, allowing the CPU to continue a mission after rebooting.
Method used to store data on the vessel is TBD, but my observation is that the built-in JSON facilities produce unacceptably large files.
I may shift to storing each variable in its own KS file locally which contains a single statement setting a lexicon value.
The current major incarnation of this package marks a shift back to packages that manifest as lexicons obtained from the package manager, allowing packages that do not modify the global namespace.
It is hoped that this will not only ease the concerns about global namespace collisions, but simplify the process of finding the implementation of a function when looking at its caller.
For reasons, I am attempting to “daily drive” Microsft VS Code, and it provides code folding to hide the contents of blocks of code. This facility will collapse blocks in curly-braces {} which is very nice for folding away details.
See doc/folding.org for more on this.
Now in 2024, I actually ended up reverting to EMACS as my daily driver, but I just popped open VS-Code with the KS extensions I set up a year ago, and I’ll try to continue using it.
Somehow I managed to set up a fair sized body of KS scripts without any apparent automated testing, so I will have to set up the tooling for regression tests as part of any effort to modify existing code.
Running tests is going to require an in-game vessel, so running the regression tests is going to require some manual steps.
I have played with {adverb} {adjective} {object} style names. These were cute and humerous but in the end the joke wore thin, and I found myself using other methods to organize my vessels so I could pick out the right one for each mission.
So now, mission names are a single letter designating what kind of mission they automate, and a number that increments when a change is made that requires new code. Following that are numbers that indicate which launch of that specific configuration.
Example: S-2 is the second major configuration for a Sounding rocket. S-2-3 indicates the third launch of the S-2 configuration.
Abbreviations currently in use:
S Sounding rockets D Downrange rockets
Planned and reserved:
A Automated Testing X Experimental: initial attempts at anything new H Hover specialized vessels O Simple orbital-specialized vessels T Tourist Vessels G Ground Vehicles C Communication Satellites
The older standard was much as above, but I forced two digit numbers for the configuration number (which was never necessary).
kOS has no formal package model – the idea is that you load up a source file and run it, and maybe it runs other files.
See doc/import.org for information about the IMPORT function,
the lack of any EXPORT facility, and the 0:STD.KS file.