Tags - Githubissues

ngld / knossos

NuKnossos a complete rewrite of the old Knossos mod manager. Nebula also lives here since it's easier to manage both projects in a single monorepo. If you're looking for the old code, go to https://github.com/ngld/old-knossos.

Apache License 2.0

24 stars 2 forks source link

Tags #4

Open ngld opened 3 years ago

ngld commented 3 years ago

It'd be great if uploaders could assign tags to their mods which users can then use to filter them. TODO:

Do we need a pre-approved list of tags? If yes, which tags do we need/want?

BMagnu commented 3 years ago

IMO there should be a set of hardcoded tags, from which every mod is expected to have exactly one:

Mod (needs FS2 retail)
TC (only needs FSO)
Resource (not visible in Home/Explore unless in developer mode)
Modpack (debatable. Same as Mod in terms of how it looks to the user, but is a mod that does not contain files, but only references to other mods. These could exist without their own directory)
Engine (if we still keep engines / custom executables as mods, these would be another tag. Like Resources, not visible to the user unless developer mode is on)

JohnAFernandez commented 3 years ago

A few pre-approved tags are good, but the user ideally should be able to make their own local tags.

BMagnu commented 3 years ago

Ah yes, I agree. I meant it as an additional set of tags, of which one is required, in addition to tags that can be set by the mod author, as well as tags locally addable.

ngld commented 3 years ago

Mod/TC/Engine already exist since they have to be handled differently by Knossos. Resource and Modpack are work the same as Mods and don't exist right now.

I think it's a good list but restricting mods to only have a single tag would limit how useful tag filters could be. This makes me rethink my previous stance on whether Resources and Modpacks should be tags... it might make more sense to show them as mod types (similar to how Mod/TC/Engine) are already handled. The user shouldn't have to know how Knossos works internally so the fact how Knossos handles the various mod types shouldn't matter.

A few pre-approved tags are good, but the user ideally should be able to make their own local tags.

I'll keep local and remote tags separate. After all, you'd probably want local tags to survive updates, etc.

For reference, here are a few tags I'd expect to see once this feature is implemented: Post Capella, BluePlanet, Multi, Alt. Universe, Satire/Shitposting

BMagnu commented 3 years ago

it might make more sense to show them as mod types

Presumably. However, there could be resources that build upon retail data, and there could be some that don't rely on retail data. To solve that, there'd need to be either a Resource / Resource-TC type difference, or Resources aren't allowed to depend on stuff at all, or Resources themselves depend on stuff, but it's then job of the first non-Resource to be of a compatible TC/Mod type.