kOS Volume API

[crafty-geek]

As a future enhancement, would it be feasible to allow a modded part to include a Volume, potentially with preloaded kerboscript files? This would allow modders who like kOS to build an API for their part(s) which allows for smoother interaction than meddling with partmodules (most likely by encapsulating the partmodule meddling within their API scripts). One use-case below, as described to and considered interesting by @Dunbaratu in his Twitch stream this morning.

"I'm working on a simple mod to make it a bit easier to mine science from the KSC, and was pondering how to make it integrate nicely with kOS. The way I'm designing the mod, it would make realism sense for it to have a low-capacity [read-only] kOS volume on it, with a couple pre-loaded scripts [essentially a set of waypoints describing the different microbiomes of the KSC, and some firmware to pathfind around those waypoints]. So, some questions: 1) Is there a way to make one's modded part(s) register itself as a kOS volume when kOS is installed? 2) Do the potential security/maliciousness concerns mean that mods are disallowed from preloading scripts? (You don't want, eg, a mod billing itself as a kOS-compliant sciencealert to maliciously delete all files in the archive when its script is run, of course)"

[crafty-geek]

Potential solution to the security concern of (2): code run off of the modded volume could disallow write privileges on any other volume - so eg SWITCH TO ARCHIVE would raise an error message. There could also be something akin to a manifest file on the modded volume which could contain a request for I/O privileges, acceptable or deniable by a blurb once the ship loads - think User Account Control blurbs on Windows - and maybe globally ignorable in a kOS config.

[hvacengi]

If I understand you correctly, the idea would be that a mod would include a kerboscript interface to some how interact with their module? Is the idea that this script would still interact with the existing part module interface, or that the mod would then have to expose extended features to the kerboscript language? That sounds like something of a hybrid solution, part C# and part kerboscript. If I have that wrong, the rest of what follows will be a bit of babbling nonsense.

The concept of hard discs has already been somewhat proposed in issue #573. There is nothing that precludes the ability to make a module which is purely a hard disk. In fact I've given the concept additional though on more than one occasion and have a couple of architecture ideas. The current issue is that all volumes are tied directly to their processor. But we would be able to modify that without too much issue (either a 2nd module to handle just stand alone disks, or outright moving the disk function to a new module). To some degree, it may make our pipe-dream idea of a file manger in the VAB/SPH possible (since it means instantiating the disk object in the editor, instead of on the first time loading for flight as we currently do).

Honestly though, I see this becoming less of an issue due to two things: the coming support for sub-directories (issue #1364 and PR #1567) and an external addons api (issue #103). Both of these will be integrated soon-ish.

Using sub-directories, other mods will be able to package script files to be placed in the Scripts folder (for example Scripts/DMagic). CKAN would even support installing directly to that folder.

The external api is a really big issue. It will be very important that other mods keep the interface similar to how "stock" kOS operates to minimize confusion and prevent collisions. It doesn't really improve the security concerns though, as the file system is probably more at risk in the raw C#. Though the risk isn't any higher than when installing the mod originally. One of the components that we are most proud of is the kOS documentation, and it will be nearly impossible to get developers to adhere to that standard. Name collisions and error handling are the two things that worry me the most. It would be easy for 2 mods to create a function of the same name.

But once we get the external api working and documented, it will provide the best solution for mod developers to enable kOS functionality. It will have better performance than attempting the interface in kerboscript. It doesn't make the scripts themselves susceptible to failure if we make a modification to the kerboscript language (though the addon support is susceptible to failure when we change the internal C# implementation).

With either option, the issue remains trying to get other developers to buy in. It won't do any good for us to offer the 3rd party option if it is the kOS developers who need to create and maintain the integration.

At this point... I've typed an awful lot in response, most of it rambling. So I guess I'll summarize: Between two planned features I think we may have a solution for you, but at least one of those issues will be pretty complicated to get working. I still like the idea of making hard drive parts available, but I'm not sure they'll really be that much easier to implement due to the need for C# backing of any new kerboscript feature.

I am marking as duplicate, but not closing because it isn't quite truly a duplicate.

[crafty-geek]

I envision essentially the ability for a modded part to wrap its own partmodule:doevent(...) (,doaction,set/getfield) calls in smoother functions, and ideally the ability to expose extra functionality to kOS that don't exist in the rightclick menu through 'hidden' partmodules (if such a thing is feasible in KSP's modding API, haven't tried to implement yet). And given the ability to ship this wrapper code with the part, being able to ship extra logic would be cool. (eg if my KSC-roving mod example exposes distances to the microbiome waypoints and booleans indicating whether there are buildings in the way of a direct path, I can ship a targetClosestAccessibleMicrobiome() function so the caller isn't stuck rewriting such a function.)

For name collisions, perhaps there could be some scoping trickery? Like what @gisikw has demo'd in some of his recent Kerbal Space Programming videos, where non-global functions are declared, and their delegates are shoved into a single global lexicon?

[gisikw]

For reference, this is the type of code @crafty-geek is referring to:

{
  function toString {}
  function add {}

  global myLibrary is lex(
    "toString", toString@,
    "add", add@
  ).
}

As to what you're looking to do, I'd advise looking at building an interface on top of the partmodule, rather than trying to bake more into the core language. So you'd have something like:

{
  function createRoverFn {
    parameter ship.

    // Alias things that otherwise are available via suffixes
    function name { return ship:name. }

    // Fancy part API
    function doCustomThing {}

    return lex(
      "name", name@,
      "doCustomThing", doCustomThing@
    ).
  }

  global createRover is createRoverFn@.
}

set rover to createRover(ship).
print rover["name"]().
rover["doCustomThing"]().

...though reading back now, I think your concern is more about having the ability to ship the code directly with the mod, rather than concerns over object:nativeSuffix and object["customStuff"]() distinctions. So maybe ignore me >.<

[crafty-geek]

Yup, no concerns about syntax, I just want to be able to ship kOS code with the mod, runnable in an intuitive way for the client (chiefly as a way of diminishing the unintuitiveness of partmodule manipulation, so as to make my mod's functions kOS-usable to even kOS newbies).

[hvacengi]

For the time being, how do you feel about using the existing addons system? If you just want to expose your mod, we can easily add a new section for your mod.

I'm envisioning moving all the current addons into a separate solution/repository (KOS-Addons maybe) to which anyone contribute. That repository would then serve as an example for modders who would rather package their own integration separately.

[crafty-geek]

It's my first mod ever, so once I get it to a serviceable non-kOS version I'll check out the kOS addons system. Might take me a couple kOS update cycles for me to get it ready - doing this just as a hobbyist right now.

Thanks for entertaining my idea.

[hvacengi]

Pretty sure we're all hobbyists at this point :wink:

Well, maybe by the time you're ready I'll have the external api stuff finished. The nicest thing about the api will be that you don't need to use reflection to reference the two sets of assemblies. Right now kOS would need to reference every mod it has an addon for, if we weren't doing this magic. But that same magic makes it very hard for some one to understand if they don't know what we're doing.