This post is getting big, it's late, and if it touches off the kind of response the first one did there's no way I'm going to keep up with that already. There's more I could and still intend to reply to, and I've already split off a couple paragraphs as seed for the next post once I started fading, but I think there's value to trying to take things a few at a time rather than tackle everything at once; I find the sentence by sentence quote wars exhausting. So if it seems I've ignored an important point you made, please give me a chance to come back to it in the future.
Alright, so first off the technical angle. I spoke to ngld about the mod count issue in the past and as I understand it there are ways around it, ones that Knossos isn’t using right now but could. But beyond that, if there’s a problem like that in the way of this idea, then I do not consider that a flaw with the concept but rather an unfortunate and almost certainly correctable flaw with reality. If nobody else is interested in correcting it, I’ve submitted code to the engine before and I intend to do so again for a number of things already.
On the practical issues of converting a mod like BtA or Solaris: Yes, absolutely, it’s totally impractical to get out the knives and carve up 200+ ships and parcel them all out manually, simply due to sheer tedium. But, I really don’t think setting up a component mod for a ship as you make or add the ships, spread out over the course of development, is that big of a deal. The Knossos interface definitely isn't made for a mod like that right now, either in explore or in installing and launching a mod, and a mod with 200-300 component mods would definitely make a mess of things, but these are again solvable problems. I think some of my own modding biases come into play here, as I am used to doing incremental releases of things as assets get finished rather than holding out till a campaign is all done and unleashing a glorious wave of new ships all at once.
Now, the issue of asset modification. I admit, the landscape of mods as has been expressed to me by community veterans in the couple days since i posted this is somewhat different than I had thought it leading up to that, and if tweaking textures and pofs is as common as has been expressed to me then yes the space and time savings are reduced. But this isn't an all or nothing thing. I would still expect that while a mod will frequently tweak one or more of the big files in a ship, it'd be rare for them to tweak all, especially in the PBR era. A practical example:
The SD Vritra in Warmachine is a ravana with recolored glows. What we do now, putting our new glow textures in the mod and loading the MVPs, is highly equivalent to how I would handle this in my proposed model if you just replace the MVPs with a Nyxvana component mod. The new textures go in a package in the main mod, or if they grow into a big enough thing(say for example recolored glows for all shivan ships, that would qualify in my book) then they might get pared into a component mod. In either case, the glows for the Ravana add up to about 63 MB, with the remaining texture layers and pof coming to ~525MB if I didn't miss any files. So by loading the MVPs rather than putting a Nyxvana in our files directly that's 90% of the download size of the ship removed for anyone who has played any other mod with the same mvps version, despite us doing the thing that supposedly kills this. And no, we don't modify the pof to modify the textures, because tabled texture replacement works.
And yes, 500MB is chump change, but 500MB times dozens of ships times every update of a mod over its lifetime adds up, both in drive space and in time. I can't tell you how many times I've started Knossos, started an update for a mod(because if I don't do it then I'll not remember to do it later), and then got distracted doing something else by the time it finished downloading, and I know there are users out there with worse connections than mine. Knossos improvements can help here yes, but I do not believe it'll be able to get the same results unless Knossos takes truly heroic measures or a modder divides things up into packages as deeply as I'm suggesting.
The other question raised is what to do if the asset is entirely changed, or comes close enough to obviate any advantages of loading the original. In that case I don't at all think it's a bad thing to have two variants of the ship uploaded to knossos as components, so long as things are clearly labeled. Coming into the community as a new modder, I had no idea how easy it was to swap around turrets between different models, and I think most people coming in with any experience with other mod communities would not realize right away how done a thing it is here to have repainted and returreted ships in your mod that were made for a different mod. Having a library of ships that include variants of ships side by side with each other would be a strong message about what can be done and how things are done here in general. I do think there's a lot that could be done on the knossos interface side to make this smoother, many of those things are nice-to-haves, not need-to-haves.
But to step away from the nitty gritty point by point, there's two threads or themes in the discussion that frustrate me, and I want to give a little voice to it before I pack it in for the night. And this is perhaps more addressed at people on discord who had a nice lively discussion about it mostly at times when I couldn't keep up with it, so apologies if it's kind of general.
First is the idea that if the thing doesn't work perfectly and deliver 100% of it's potential maximum benefits then it isn't worth doing at all. This comes up in the asset modification stuff mostly, and it really baffles me. I'll just point back to my Ravana example there. Some points have been made that take a little of the shine off my original dream, but far from totally tarnished it. Partial benefit is still benefit.
Second is pointing to how modding as it is presently doesn't need or perfectly mesh with the proposed process, or how people don't do the things the proposed process would enable so it's pointless. To me that's circular logic, modding developed in a situation without any automated package management or distribution infrastructure so of course it is adapted well to not taking full advantage of one, and patterns of behavior that require one to function don't exist for the same reason. That doesn't mean those patterns have no value.
That's not to say it's not possible for the benefits to be too small to be worth the trouble, but it's felt to me that for some people these fuel a black-and-white dismissal of the thing that isn't warranted.