Add discord link and relevant categories for Silksong

[BadMagic100]

Main changes:

• Add discord link to HK modding server
• Added new categories for utility, cosmetic, accessibility, custom tools, custom crests, boss, and expansion. Based roughly on what we had for HK. https://github.com/hk-modding/modlinks/blob/main/Schemas/ModLinks.xml#L105-L118

The only thing I'm not sure about here is whether it is safe to remove existing categories. The rationale for the 3 removed categories here are:

• Tools - this is ambiguous between developer tooling/external software and the actual game mechanic called "Tools" in Silksong. Of the 3, this one I think is actually important to be dealt with to prevent user confusion, if any additional action needs to be taken for the removal to work (where the others are more "nice to have")
• Audio - this is a subset of the broader "Cosmetics" category. We historically see many more reskins than custom audio, so it doesn't feel correct that Audio would get its own category.
• Misc - this category provides no value to users, any uncategorized package is "misc". Nobody is going to go searching for it either.

Currently draft to get more eyes from the broader community before merging.

[CLAassistant]

All committers have signed the CLA.

[SFGrenade]

i suppose some people might want a meme label, but those can be categorized differently probably

[BadMagic100]

I considered a joke/meme category but I erred on the side of leaving it out because I recently saw people getting upset about quirrelboat being labeled as a joke; not having the category means we don't have to worry about whether the joke is "tasteful" or not

[BadMagic100]

After discussing in HK modding discord we think optimization is too niche, so removed from this PR. Such mods would fall in under accessibility/utility

[anttimaki]

Looks like removal of categories via ecosystem schema is currently prohibited. I'll get back to you after I've discussed this internally with the team.

[MythicManiac]

Removal of categories is prohibited in general because a package might have it in their manifest.json already, which would retroactively make the manifest not pass validation. In essence we'd be creating a data integrity error if we allowed categories to be removed once they've been "committed" to the ecosystem, as a part of package validation is checking the categories are actually real.

So in order to make removals possible, we'd need to detach category definitions from the package validation flow. The best idea I have at the moment is to replace the categories manifest.json definition with something like tags, where the package author can place anything and there's no validation. Categories could then be managed entirely on the site / via the schema here, perhaps with auto-matching rules akin to if a package has tags X or Z, put it in this category. Perhaps we could also treat the current category property as place the mod in this category if it exists, do nothing if it doesn't, thus decoupling it from the validation stage.

In any case, as things stand right now, this PR is unmergeable because existing categories are being removed

[BadMagic100]

This is unfortunate, given that this was added to the ecosystem schema without any consultation of the HK modding community and we are now apparently locked with ambiguous/unhelpful categories that were created on our behalf. So getting a longer term fix with priority would be nice.

Perhaps we could also treat the current category property as place the mod in this category if it exists, do nothing if it doesn't, thus decoupling it from the validation stage.

This behavior seems intuitive to me as a longer term option. Of course it carries the risk of a typo meaning that an intended tag is missed, but this can be remedied with a new version.

In the short term, is it safe to re-label the categories? I have on my mind to add a (Deprecated Category) to the front of the ones slated for removal.

[MythicManiac]

While removals aren't possible, we could fairly easily add a soft-delete marker on the categories. This would make it so we can hide the soft-deleted categories from the site, but the old category IDs are still technically valid as far as validation rules go.

Relabeling is completely fine and supported, although I think mod managers might not currently use the labels and instead assume a category ID maps 1:1 to a label. Mod managers should of course use the ecosystem schema (or the on-site API) as a reference on how to map category IDs to labels, but I'm unsure how many implement that. Either way at least the website will display categories according to their labels rather than IDs, and any consumers of packages should be doing that too, I'm just not sure how many do.

[MythicManiac]

While removals aren't possible, we could fairly easily add a soft-delete marker on the categories. This would make it so we can hide the soft-deleted categories from the site, but the old category IDs are still technically valid as far as validation rules go.

Adding to this, I'd suggest you update this PR but instead of deleting the categories you want gone, add a new property under them as hidden: true. It won't immediately do anything, but that seems like a reasonable way forward so we can assume it'll eventually take effect when we get around to implementing it.