Feature request: Meta data related to category.

[xobes]

While tags do exist and are worthwhile, if we had a category we could group in the in-game plugin-manager.

This idea came about with my efforts to bring Language packs to the game.

[MCOfficer]

I can think of several ways this could be achieved, but all of them alter either the design/purpose of the index, or how the game in general deals with plugins. Which feels like a discussion that requires more publicity than an issue on this repo can offer, possibly an RFC.

@Hecter94 for visibility

[Hecter94]

The unofficial plugin repo has something like that, every plugin is given a category, and they're displayed under their category in the readme
For example, the "Outfits" page is here

I manually categorized the first few hundred, and then we added it to the template when submitting a plugin so that authors can categorize it themselves.
It's far from perfect; there are a lot of questionable decisions about why the categories are set up the way they are, but in general, it's definitely beneficial.

I don't think it would be a problem for the official repo to implement something similar, especially if we allow authors to choose their own category and make it clear to users that it may not always be accurate.
We would probably want to have some dialogue with plugin authors first to establish the categories, and give them a set amount of time, say 90 days, to categorize their own plugin if they wish, before we categorize it for them.

[xobes]

how the game in general deals with plugins.

Is exactly what the PR I submitted does. It formally uses your json manifest.

[MCOfficer]

Oh, I wasn't aware of that. Ref endless-sky/endless-sky#12083 (that's so cool btw)

Still, I'm a bit confused as to the purpose of this issue.

Is this a request to implement them? In that case I'd strongly recommend discussing it over on the PR, or in an RFC. I can't see any mention of categories there.

Or is this you asking for your take on the matter? In my opinion categories and tags fulfill mostly the same purpose, and having both would make the UI pretty cramped. (And I'd still recommend opening a discussion in a more public place, i.e. PR or RFC).

[xobes]

Once category.
Many tags.

Forgive me for not understanding, but the JSON manifest lives in this repository, until this moment (above PR) the game had nothing to do with it.

I'm here, having modified the game, desiring to modify the game some more, to request that the manifest controlled in this repo be updated. The language packs are driving this, they are a work in progress and categories would be added later, after the plugin manager PR is likely added, as a delta.

You want an RFC? For a JSON file you control?
@Hecter94, do you have a separate listing entirely? You've determined or assigned a category already...

My take on this:

1. Add categories.
2. Pick something for all known plugins
3. Be very accepting of authors recategorizing their works.

Now, here's where I need to stop myself: my motivation is biased. I wanted categories specifically so I could put language packs at the top. This makes them more visible and accessible to users needing to change the language.

There are other possible approaches, all requiring game modifications. I was aiming to add collapsible carrier sections to the current (new) plugin library, and to avoid duplicating the interface for languages ... Since the languages are just plugins anyway.

My main goals:

1. Make languages as accessible to the non-English player as possible
2. Don't repeat the download interface just for language packs

Biased conclusion: make categories (collapsible sections), put languages at the top (easy to find, easy to collapse and hide)

Alternatives might be to ... I'm having trouble seeing this work, but, allow for selection of tags to filter the display set. Problem is how to select tags, how to make it accessible (obvious that there are languages available).

Anyway, categories would be easy.

You (this repository) control the JSON format. No?

Also, I love your review of the new interface!

[Hecter94]

@Hecter94, do you have a separate listing entirely? You've determined or assigned a category already...

Yes, as I mentioned, there's an unofficial plugin archive alongside this official one.
https://github.com/Hecter94/EndlessSky-PluginArchive
The unofficial one already includes categories like what you're suggesting here.

You want an RFC? For a JSON file you control?

It doesn't need to be an RFC, but if we're going to implement categories in an official, public-facing manner, I would want to see evidence that there has been some discussion with plugin authors first to ensure their needs are being met. An RFC is one option to do that, a PR would be another, but feel free to use whatever option makes the most sense to you.
I simply don't want to see plugin authors constrained to a specific set of categories without first ensuring they've had an opportunity to weigh in on what those categories should be, or if they even want categories.

My take on this:
Add categories.
Pick something for all known plugins
Be very accepting of authors recategorizing their works.

Agreed, this is largely how I did it for the unofficial repo.

[xobes]

I guess the real question is: where is the format defined (presently)?

After #12083 is accepted into the game (if it is) then that in-game code will rely upon that format and the game itself will govern what keys are (required/able) to be used by the in-game plugin manager.

As I've written it, the in-game plugin manager can source from many libraries at once, and should one wish to add their library to the list they would have to follow that format.

[MCOfficer]

Forgive me for the infodump, but I think I need to establish some background.

This repo is an implementation of the RFC for a plugin index. The intention was to establish a stable index ahead of time, so launchers and eventually the game can use it.
(Sidenote: Hecter's unofficial index does not follow this format. In part because it's older, and in part because it started as an unofficial attempt to rescue as many obsolote/abandoned plugins as possible ^{[citation needed]}).

Note that it pre-dates the plugins.txt, which is why some information that feels like it should be available is missing. (#1932)

(Short History Lesson)

It also was stagnant for a while... I created it 6 years ago, and nothing major has changed since. Well, one thing has changed: I pretty much left ES and gave up my reponsibilities where possible. And while I kept the index itself uptodate, i really have been out of touch with how the game developed during that time. Hence why it was never properly adapted for plugins.txt.

Last year I brought aboard Hecter to at least have someone with knowledge about current ES development. However, this is still in early stages. The index could do with somebody from the dev team taking over and bringing it into the fold of "dev-team owned" projects, but we're not there yet.

---

That's why we are hesitant to change things on the fly: Because we try to adhere to the format laid out by RFC. Effectively, we have a defined API ^[1] and we already have users (ESLauncher2, the website) consuming it.

The RFC's format isn't set in stone, but changes should be made carefuly, after community review, and trying to preserve backwards compatibility. (For a minimal example, see endless-sky/rfcs#6, which added a new field to the manifests).

---

^[1] Except...

if you read the RFC carefully, you'll notice that it only defines how to store the data (the manifests), and how they are being updated. What I just called an API - the json file - is really just this section:

The generated files should be updated by a CI service upon every change to the Manifest. They may take the following forms (or others):

• A JSON-file, containing all Plugins
  [...]

And the RFC deliberately leaves open the exact format of such generated files. As of now the index only implements the most basic generated files, by simply converting the manifest to various formats. That's how the JSON file is produced.

In theory, JSON files containing any information available to the CI - such as filesizes, which it could look up while generating - could be created. Heck, we could generate fancy PNG banners for each plugin if we so choose.

That being said, while a lot could be done by enriching the generated files with additional data, there comes a point where this neat escape hatch becomes fertile ground for dirty hacks. We could probably implement a list of categories in this repo (in a separate file, so the manifests remain untouched), and generate files based on that.
And if you bribe me enough, I might just do that for your launcher or your third party program. But I feel that an official implementation, to be merged into the game, really should try to find a more official way.

Hope that clears things up.

[xobes]

Forgiven. That is exactly the sort of stuff that I needed to know.

Now, with respect to the .json file format, I understand that it is in use by other consumers already.

ADDING fields is a non breaking change, so I implore that some consideration be given to the thought.

I want to clarify that I'm not asking for a static list of categories to be developed but rather for a field called category to be added to the JSON file.

I am not asking for a limit on the values that may be presented. I.e. I'm not trying to define a list of categories -- I'm trying to indicate that the manifest file should allow for a plugin to be assigned a category.

[xobes]

I see the problem now.

The fields are defined in this RFC:

https://github.com/endless-sky/rfcs/blob/main/rfcs%2F0001-plugin-index.md

I will propose a change over there and link it here. I know you guys were saying that in generic terms, but it was not clear to me that the RFC in question already existed AND governed the supportted fields.

[TheGiraffe3]

endless-sky/rfcs#12
endless-sky/rfcs#11
endless-sky/rfcs#10
endless-sky/rfcs#9
endless-sky/rfcs#8