Improvements for standalone usage

[Nihlus]

As some of you are probably already aware (we've talked a bit about this already on Discord), I'm currently developing a custom headless server for NeosVR that runs on a modern .NET runtime.

One of the features I'd like to offer out of the box is NML integration so that users won't have to download NML separately. Additionally, having NML shipped with the server would open up the possibility for many more integration features (such as mod queries and configuration via the server's REST API).

Today, NML works with the server in essentially the same way as it does with the stock headless client. I have bumped into a couple of things that would make integration a lot easier, however, and this issue is meant as a first collection of these so we can discuss which, if any, are something that can be changed or fixed on NML's side of things.

1. NML assumes the working directory is the NeosVR installation directory

This isn't a blocker per se, but it would be very useful to allow this value to be fed in or configured at runtime. Typically, server daemons run in restricted or atypical working directories for a variety of reasons, and right now the working directory must be forced to NeosVR's installation directory for NML to work.

2. NML assumes nml_mods and nml_libs can be created in the working directory

Same as above, really. Having the ability to configure these paths separately would also be a very good thing - I've seen users work around this by having symlinks to other locations in the filesystem, but that is not always a supported configuration (especially in a security-hardened context). For example, the server runs with strict restrictions on which paths can be written to as well as which paths executable code can be loaded from - if a user tries to symlink out into another location, that location may not fulfil the requirements by nml_mods and nml_libs from a hardening standpoint.

Allowing these paths to be configured or overridden would enable smarter integration with these types of configuration.

3. NML can only be loaded as a plugin

This one is a bit trickier, but being able to load NML explicitly and at a controlled point in the code instead of having to pass it as a LoadAssembly plugin would help a lot. Preferably, NML would support some kind of initialization routine that the plugin portion simply calls, and which could be used by the server application as well.

4. NML is only distributed via Github

Provided NML can be modified to support library-style initialization as described above, taking a dependency on NML as a library would be miles and miles easier if NML was distributed on something like nuget. This is obviously very much in the "nice to have" territory, and I fully understand if it's not in the cards. Using NML as a library is a niche use case at best, and setting up a nuget package for what is ostensibly one guy's mad idea would be a hard sell at the best of times :P

That said, publishing NML as a nuget package would be pretty easy and brings other benefits over time - dependency handling would be simplified for downstream consumers, for example.

---

Thanks for taking the time to read through this! Any comments, ideas, or questions are welcome.