They are minor issues at best but it would be nice to address them:

• Since the TACLS settings file is under the PluginData folder it is impossible to patch it with MM. I remember that there was a request for that some time ago but it never materialized. It would simplify RO patching without the requirement of overwriting the original config file.
• CRP includes the resources that TACLS uses so that the "TacResources" file is not needed anymore. If installing via CKAN then CRP can easily be added as a dependency (and RO already requires it anyway).

Split settings into two lots. The default consumption type numbers and the user settings.
User settings (that change frequently) now go into the Persistent file nodes.
The base consumption numbers move out of the PluginData folder so MM cfgs can get to them.
This does mean an MM cache reset when they change, but usually this is only when the player starts a new game.

Awesome!

TACLS is dropping separate (and rendundant) resource configs, now includes CRP as a bundled dependency. So half the issue is resolved. For the other half, pulling TACLS setting out to MM land, that will have to wait.

Can we use TACLS without CRP? I would be hesitant to include the files directly in this branch as that means we need to keep the files in sync.

Three issues to possibly deal with:

1. TACLS before 0.12.0 had its own resource definitions redundant with CRP, creating potential conflicts with CRP installs. This is a important for Realism Overhaul, since RO requires CRP already, not to mention the vast majority of mods with similar resource requirements already use CRP. We could go back to this.
2. If we require CRP but don't bundle it, this creates support headaches for me. I'm managing the release OP on the forums, and this will create a host of issues for manual installers who fail to read the OP.
3. If we require CRP and bundle it, we occasionally have to update the bundled CRP, and any lag in the update creates potential issues for other mods (e.g. user overwrites newer CRP with an older one bundled). This is easy enough to catch, as CRP uses AVC and will let me know when an update is available.

I prefer door number three.

I would suggest we do option 4) Git submodule pulling CRP from the shared location. We can ship with it, but we don't check it in.

My $0.02 is that regardless of what decision is made, CRP should absolutely not be bundled into TACLS as installed from CKAN as that violates pretty much the core purpose of CKAN. I was therefore going to suggest that we absolutely should not bundle CRP with TACLS, but then I realized that you can trivially exclude parts of a package's zip file (for example the bundled CRP) from being installed on CKAN, so that doesn't really matter one way or another.

Agreed, and it isn't bundled via CKAN. The NetKAN file is very specific about only including the /GameData/ThunderAerospace folder, and it properly includes CRP as a dependency.

Re: submodules, that's acceptable.

While either of you could do this for me easily, I'm not yet comfortable with submodules, so I need to do more research to educate myself, or I need @james3838 to walk me through setting it up.

Here's the long-winded reason why: I couldn't figure out how to get the TacLib submodule to point to an updated fork instead of Taranis's original, so I flattened it to get around the problem. Before this project, I never worked with any VCS or even C# for that matter (just solo C/C++ projects and some physics-ish things in Matlab and Mathematica). As long as I'm the point man on this, I'm responsible to users for what goes in it (in the literal sense that I'm the one responding to them), which means I need to understand the bits and pieces going on.

Edit: we're moving away from PhineasFreak's original issue, which we should use this space for addressing.

RO modifies it at least one time after a fresh installation and it is not touched ever again (probably only after a new release).

I would prefer to have default settings MMable, but custom user settings kept in PluginData. That lets RO not have to include a TACLS file in itself, instead merely an MM patch, while still keeping custom data outside caching.

Ok So:-
Split TACLS settings cfg file into user settings and global/mod/RO related settings. Move global/mod related settings back to TACLS folder that MM can access and leave the user settings in PluginData folder.

Yeah, the question is whether consumption settings should be ingame player configurable or not. If not, then that metric works fine; if they should be, then instead of global and user settings there should be default settings and user settings, with each new savegame starting TACLS with the defaults.

The latter is probably simpler; right now the defaults are just hardcoded and you could instead load them from a node.

I think some investigation into the internal usage of the settings is required and perhaps a re-design.
So, there should be settings that are default... these settings are probably the ones you want RO to modfiy for RO games. But - some we may want to allow the user to tweak or change during gameplay. The answer here would be to have the two settings and internally TACLS applies the default and then the delta user settings. I'll look into how hard this change would be.

<3

Regarding CRP, it is bundled in the most recent git releases. For the non-CKAN installation, I bundled TACLS's requirements into the download. It is the CKAN listing which grabs CRP separately (requiring it instead of bundling).

I'll defer to you on the re-design for the settings and their accessibility to MM.

From what I gather there are two things here.

1. global Settings file for TACLS is in PluginData folder. This is a good thing if you don't want MM to re-build it's cache every time the file changes. but it's a bad thing if you want to MM modify the file because MM won't touch it. So the question is, how often do users change these settings vs being able MM the file. My thought is, Usually these settings are changed ONCE? maybe TWICE, (at the start of a new game) or occasionally by the user. I think if there is a real need to MM the file then it should be moved out of the PluginData folder, the s effect of MM re-building it's cache when the file is changed once or twice is not something that can be addressed, but given the nature of the file only changing occasionally I think it's the right thing to do.

2. CRP - OK. So Personally I hate using CKAN and don't support it on my other mods. but I understand the need here given TACLS is trying to be bundled with RO implementation in CKAN. We also should be distributing CRP with TACLS regardless as some users won't be using RO and/or CKAN. I think @james3838 is on the right track here. A pull into TACLS from the source CRP to include in the package bundle for Git. I'll set it up for the next release.