Modding, Mission Design, and Coding > FS2 Open Tools

Knossos - Pros and Cons

<< < (3/3)

jadeddragoon:

--- Quote from: Mongoose on December 09, 2021, 11:09:47 pm ---I know that the concept of "known working version" is the proper way to do things from a software development standpoint, and it has obvious advantages in terms of ensuring that a mod always works, but speaking strictly from an end-user standpoint there are also some substantial disadvantages to it. I think having to keep around "only 4" versions of the MediaVPs is asking a lot, especially when one or two of them may be required for only a single mod or two. That's a whole lot of disk space wasted on what are largely duplicates of the same upgraded content. More pressingly, locking players into an older version of a dependency by default means that they don't get the benefits of what can be many years' worth of improvements, whether it's new models in the MediaVPs or bugfixes and performance gains in FSO builds. I know that things are very different now than a decade-plus ago, when mods were much simpler as a rule, and the MediaVPs largely consisted of upgraded content that had the exact same filenames as the retail originals. I know that you couldn't get away with doing that in many cases now. But I also know that there are cases where you still can, where mods are still locked to very old upgrades or builds when they could get away with running on the latest releases just fine, and everyone could ditch one or two of those older MediaVP installs.

I don't really know what a good solution to this looks like. I wondered some time ago if we could recruit players to fire up finished/unmaintained mods on each new major release, to see if there were any obvious non-starters that would prevent them from using those new versions. I know that ngld talked about attempting to implement some sort of automatic compatibility checker that could at least pick up warnings and the like. (Obviously detecting things like balance regressions goes well beyond any sort of automated tool...unless someone wants to sit down and code a full FS-playing AI, which if so then by all means.) Whatever the case, I feel like there has to be a better answer than needing to keep 5 or 6 versions of Common Dependency X taking up a good 15-20 GB of drive space just because one or two old mods haven't been given a stamp of approval.

--- End quote ---

In a perfect world we would use de-duplication... in the real world that would mean extracting the .vp files, identifying which files are identical, then using symlinks (Windows has had them since Vista) or hardlinks to rewire the file table so that only one copy of each file that is a duplicate needs to be physically stored on disk. On linux this could be achieved even easier with something like btrfs which has block level deduplication. Conceivably de-duplication scripts could be written for windows and *nix to do the job. Better still would be knossos handling all of this and never even downloading duplicates.  The big problem is having to extract the files from the vps... there are some potential load order shenanigans involved in that. And knossos's file validation would need to account for the extracted files somehow. Then there's the maintenance of the web of sym/hardlinks as versions of mods are installed/removed.

I fear we are dragging the topic off course a bit though. I mainly wanted to posit What Could Be if the capabilities Knossos presents were fully utilized. The specifics of how to get from here to there (or if we even should) may not quite fit the OP's intent for the thread. I'd be glad to continue the discussion elsewhere, however.

Vidmaster:
I am happy to read all the responses here, there was no dedicated intent other than to get a discussion going and learn about people's opinions.

Navigation

[0] Message Index

[*] Previous page