Modding, Mission Design, and Coding > FS2 Open Tools

Knossos - Pros and Cons

<< < (2/3) > >>

mjn.mixael:
Tags should include all the common stuff by default.

-Model/Asset
-Mod Dump
-Campaign
-Single Mission
-Script
-Total Conversion
-Freespace Mod
-Not Freespace Mod

In addition, probably things like timeline eras because that's also a very, very common ask by new players.

-Pre FS1
-Great War
-Reconstruction
-Second Incursion
-Post FS2

Also genres

-Classic Freespace
-Arcade
-Action
-Mystery
-Parody/Comedy
-Whatever else

Probably also a way to add custom tags because you never know what people are going to come up with next. Tags should also not be mutually exclusive.

Cyborg17:
Love the categories.  Is

-Total Conversion

distinct from

-Not Freespace Mod ?

mjn.mixael:

--- Quote from: Cyborg17 on December 08, 2021, 06:17:51 pm ---Love the categories.  Is

-Total Conversion

distinct from

-Not Freespace Mod ?

--- End quote ---

I mean, I guess in practice it is. But in theory Total Conversions do not have to be non freespace. It just means it doesn't require FS2 installed to run.

Nightmare:

--- Quote from: Cyborg17 on December 08, 2021, 06:17:51 pm ---Love the categories.  Is

-Total Conversion

distinct from

-Not Freespace Mod ?

--- End quote ---

Well you can take a mod featuring non FS2 ships and run them in FSO. I think there're a number of modpacks (ships + weapons) that are running but not as standalone. Most are from canceled TCs which got functional to a degree but none of them have actually "playable" content (in the sense of you get a fun campagin)

Mongoose:

--- Quote from: jadeddragoon on December 08, 2021, 02:23:04 pm ---I'd like to point out that this is not really an issue with knossos so much as an issue with the very concept of software dependencies. Knossos, ultimately, is a simple package manager for Freespace Open and the HLP Community. And this same issue shows up in every package manager for every linux distro out there. Check carefully and you will find numerous packages with multiple versions installed in any linux distro. And there are literally thousands of library files on every modern linux system that the average user has no idea why it's there except that "something else needed it". The old solution to this, prior to knossos was to tell new users "just use the latest"... which often didn't work correctly and led to bugs. There was no real alternative because no one had a list on hand of what versions of what mods worked with what versions of other mods. Knossos has that list. It's the foundation of it's dependency resolution system. But knossos, due to "just use the latest" being a systemic mindset after decades of it being the norm, doesn't really take advantage of it's own abilities here. When building packages dependencies default to "latest" and build requirement default to "X.X.x or newer". Then to make matters worse, knossos' current implementation is prone to errors in it's dependency resolution attempts. This has been a plague for my modpacks which have the most complicated dependency structure i'm aware of on knossos.

Now imagine the inconsistent dependency resolution is fixed, as it's expected to be in nuknossos. Imagine nuknossos takes better advantage of the ability to pin mods to Known Working Versions of their dependencies, as I've lobbied for in nuknossos. And then imagine an automated cleanup routine that uses this improved dependency resolution to accurately identify what versions of which mods you don't need and allow you to have all the unneeded version removed at the press of a button. In my own tests, I was able to remove 6 versions of FSU MediaVPs leaving only 4 behind. That lets me continue playing mods old and new without all the extra wasted space. With a working dependency resolution system automating such cleanup should be rather simple I would think. And automatically removing all but the latest version of campaign mods shouldn't be too much beyond that.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page