Modding, Mission Design, and Coding > FS2 Open Tools
Knossos - Pros and Cons
Vidmaster:
I have switched from my manual managed Freespace install to Knossos about 2 years ago now, a time span long enough to start this thread. The purpose of this thread is not to credit or discredit the hard work that went into Knossos but instead have a discussion of what how launcher has affected the distribution of Freespace content. Both the good stuff and the bad stuff needs to be pointed out and I look forward to a fruitful discussion with all of you :)
PROs:
* let's get the big one out of the way first, accessibility: thanks to Knossos, accessing the work of the HLP community for the newcomer has never been easier. Buy the game on Steam or GoG, download the MediaVPs and enjoy a beautiful Freespace :nod: . The importance of this cannot be overstated :yes:
* ease-of-patching: receiving fixes for problems with content, be it a campaign, a mod or a full TC, has never been easier for the average user. Just click on the button. We actually have hard(-light :lol:) data to back this up, the number of fixes released in this community has dramatically increased since Knossos is a thing
* abstraction: while computer-stuff has become ever more complicated, the possibilites of the laymen user to interact with that technology has actually increased over the last decades (just look at the mobiles). While this comes with drawbacks, there is no denying the obvious fact that more people than ever before have access to e.g. PC games thanks to simple and abstract interfaces like Steam. Knossos is very similar in that regard, it takes away all the complexity of managing an installation, of configuring something. It boils down to "click on the logo", just like Steam or any other modern front-end, while hiding all the technical details.
CONs:
* file-amount overkill: having clean and stand-alone local copies that "just work" comes with a lot of redundancies, as Knossos has to keep seperate copies of versions, mods, VPs, packs, etc (let's call them packages in an obvious Linux comparison). Dozens of almost-the-same different versions of a package to ensure the dependencies of a particular mod in a particular state are satisfied. My Freespace folder's size regularly grows until I start weeding it out again by hand :banghead:. I have not looked at the source code, hence I do not exactly understand where this issue comes from...
An example: MjnMixael's HD mainhalls was updated today (that is at 2021-12-08) from 1.4.5 to 1.4.6 as far as I can see. Now, I got a "MjnMHs-1.4.5" and a "MjnMHs-1.4.6" in my folder but the former is empty (which is weird but okay ;), no space wasted). The Freespace Port, still on 4.5.1 and not updated does seem to make use of "MjnMHs-1.4.6" according to the manifest so everything is nice even if I fail to understand how it detected that. But on the other hand, I got a BtA-1.6.6, BtA-1.6.8 and BtA-1.6.9 packages in my folder, each more than 7GB big :hopping:. Apparently, we either have an issue with distributing some things (or we fail to communicate how to properly distribute things to the people uploading this stuff) or Knossos has a bug or I simply fail to understand the concept here. Could somebody shed some light on this?
* overwhelming amount of packages: now that we have everything in one place, we have a new issue: oversaturation :sigh:, which absurdly goes against the biggest PRO of Knossos. Much acclaimed mods like Blue Planet sit right next to things like Lafiel's HUDIcon Script or Machina Terra DUMP. From my perspective, there is no issue here but for a newcomer to this community, this is a gigantic issue: distinguishing a playable, polished experience from purely technical (aka unplayable) packages is hard to impossible without all the background knowledge. Personally, I believe we need to establish some sort of high-level categorization soon before that list grows longer or risk confusing the newcomers.
Now that this little essay is over, I would very much like to hear your thoughts on the matter :D.
mjn.mixael:
Tags, categories, and filtering were always planned. The full feature has yet to be implemented. Knossos has a base filtering option. I'm hoping new knossos will solve this, especially since some creators want to split their mods up into many individual downloadable releases.
jadeddragoon:
Pros:
* Enables a shift away from the problematic, existing status quo of "just use the latest" to actually using Known Working Versions based on dependency resolution. This can enable unmaintained mods to remain playable indefinitely. It leads to less overhead for mod maintainers who no longer need to fix problems introduced by newer builds and upstream mods. It moves this community closer to conventions that have been successfully used throughout the oss world for decades.
Cons:
* It doesn't currently work, not completely. Dependency resolution is unreliable. Settings seem to reset themselves at random. Just a litany of bugs and problems that make using knossos something of a chore. I personally believe this has done a lot to damage knossos' image in the community and has turned some people against it.
* Is affected by the systemic mindset in the community of "just use the latest". A mindset that made sense before knossos came along but significantly less so now that a package manager like knossos exists."
A couple thoughts:
--- Quote from: Vidmaster on December 08, 2021, 11:20:42 am ---* file-amount overkill: having clean and stand-alone local copies that "just work" comes with a lot of redundancies, as Knossos has to keep seperate copies of versions, mods, VPs, packs, etc (let's call them packages in an obvious Linux comparison). Dozens of almost-the-same different versions of a package to ensure the dependencies of a particular mod in a particular state are satisfied. My Freespace folder's size regularly grows until I start weeding it out again by hand :banghead:. I have not looked at the source code, hence I do not exactly understand where this issue comes from...
An example: MjnMixael's HD mainhalls was updated today (that is at 2021-12-08) from 1.4.5 to 1.4.6 as far as I can see. Now, I got a "MjnMHs-1.4.5" and a "MjnMHs-1.4.6" in my folder but the former is empty (which is weird but okay ;), no space wasted). The Freespace Port, still on 4.5.1 and not updated does seem to make use of "MjnMHs-1.4.6" according to the manifest so everything is nice even if I fail to understand how it detected that. But on the other hand, I got a BtA-1.6.6, BtA-1.6.8 and BtA-1.6.9 packages in my folder, each more than 7GB big :hopping:. Apparently, we either have an issue with distributing some things (or we fail to communicate how to properly distribute things to the people uploading this stuff) or Knossos has a bug or I simply fail to understand the concept here. Could somebody shed some light on this?
--- End quote ---
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.
--- Quote from: Vidmaster on December 08, 2021, 11:20:42 am ---* overwhelming amount of packages: now that we have everything in one place, we have a new issue: oversaturation :sigh:, which absurdly goes against the biggest PRO of Knossos. Much acclaimed mods like Blue Planet sit right next to things like Lafiel's HUDIcon Script or Machina Terra DUMP. From my perspective, there is no issue here but for a newcomer to this community, this is a gigantic issue: distinguishing a playable, polished experience from purely technical (aka unplayable) packages is hard to impossible without all the background knowledge. Personally, I believe we need to establish some sort of high-level categorization soon before that list grows longer or risk confusing the newcomers.
--- End quote ---
I'd also like to mention that nuknossos is planned to have a filter in place that hides purely technical mods like Lafiel's HUDIcon Script by default. Allowing those mods to exist on the nebula for package maintainers to use but without confusing novice users. As a maintainer of a few such mods (including the listing on nebula for Lafiel's HUDIcon Script) I actually brought this up to ngld myself months ago. It's absolutely a valid concern but hopefully the fix is already on the way. :-)
Vidmaster:
--- 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 just a simple package manager for Freespace Open and the HLP Community.
--- End quote ---
I am a software engineer myself and totally understand what you are trying to say here :lol: but this is why the BtA-example I gave in my OP is so puzzling to me. Nothing in my installation has any dependency on BtA. Updating BtA, aka selecting a new version to replace the old, which is the default behavior a user expects when updating (although your point about not necessarily using the newest version is true but Knossos does enable that too), does not replace my older version and instead places a new version besides the old one. And when those are 7GB in size, stuff gets ugly fast.
I actually also lobbied for the "automated cleanup routine" you are mentioning, which should be possible to implement quite easliy. After all, it is a acyclic graphic by its very nature and if outdated versions of something are detected which are not required by any other node in the graph, they choice whenever to eliminate them can be put to the user.
Granted, I have not been very active on HLP in the last years (bar donating a few dollars and lurking around, only posting something here and there) but I have actually not heard of nuknossos before. In short, I was not aware that Knossos had been forked or there were plans to replace it. Tell me more.
Another interesting effect of Knossos I neglected to mention in my OP is the fact that combining mods (e.g. Cockpit Mod with e.g. Derelict) is actually quite a lot harder than in a manually managed install. It is by design and not a bad thing, since the newbie user would not know how to combine this stuff by him-, her or themselves. If the modpacks combining multiple things were easier to access and filter, I even think this would not count as a problem at all.
jadeddragoon:
--- Quote from: Vidmaster on December 08, 2021, 02:34:05 pm ---
--- 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 just a simple package manager for Freespace Open and the HLP Community.
--- End quote ---
I am a software engineer myself and totally understand what you are trying to say here :lol: but this is why the BtA-example I gave in my OP is so puzzling to me. Nothing in my installation has any dependency on BtA. Updating BtA, aka selecting a new version to replace the old, which is the default behavior a user expects when updating (although your point about not necessarily using the newest version is true but Knossos does enable that too), does not replace my older version and instead places a new version besides the old one. And when those are 7GB in size, stuff gets ugly fast.
I actually also lobbied for the "automated cleanup routine" you are mentioning, which should be possible to implement quite easliy. After all, it is a acyclic graphic by its very nature and if outdated versions of something are detected which are not required by any other node in the graph, they choice whenever to eliminate them can be put to the user.
--- End quote ---
You're right, I went more general with it and then kinda meandered off on a tangent. However, I do think the problem you mentioned with (for example) BtA is a relatively small fix away. Simply identify that it's not the newest version installed and present the option to automatically uninstall it. Probably see what dependencies will be freed up for removal at the same time.
--- Quote from: Vidmaster on December 08, 2021, 02:34:05 pm ---Granted, I have not been very active on HLP in the last years (bar donating a few dollars and lurking around, only posting something here and there) but I have actually not heard of nuknossos before. In short, I was not aware that Knossos had been forked or there were plans to replace it. Tell me more.
--- End quote ---
Nuknossos is a complete re-write of knossos from the ground up using lessons learned from the original and implementing many quality of life fixes along the way. It's being worked on by the dev of the original knossos, ngld. It will also come with a revamp of the nebula servers to work with the new functionality. The general goal is to making it faster and much more reliable while addressing a number of concerns by the community. Early alpha builds are starting to show up in the discord channel.
--- Quote from: Vidmaster on December 08, 2021, 02:34:05 pm ---Another interesting effect of Knossos I neglected to mention in my OP is the fact that combining mods (e.g. Cockpit Mod with e.g. Derelict) is actually quite a lot harder than in a manually managed install. It is by design and not a bad thing, since the newbie user would not know how to combine this stuff by him-, her or themselves. If the modpacks combining multiple things were easier to access and filter, I even think this would not count as a problem at all.
--- End quote ---
While I agree that it's more complicated than simply dropping the cockpit mod files into the derelict folder or modifying a mod.ini or bat/sh file and making a few other tweaks... i think from a maintenance perspective it's easier. And I think it's less intimidating for pc novices (not that we seem to have a many of those). I have asked for a "modpack" tag both to enable filtering them out and selecting for them, but not sure what ngld's plans are yet for tags beyond "modders resource".
Navigation
[0] Message Index
[#] Next page
Go to full version