Main menu server tab mods button

[cx384]

Fixes #8782
It is an extension of #15425

How does the PR work?

• It uses a package box icon (hopefully it looks sufficiently good, I tried)
• The button is grayed out if the server does not provide a mods list.
• On hover, it only shows the amount of mods installed.
• It opens a dialog which shows all installed mods (similar to the clients list dialog) and the gameid if available.
• (Also, I optimized the server_view_clients.png texture.)

Screenshots

Click me

To do

Ready for Review.

How to test

• Open the server tab
• Hover over the button
• Click it

[Zughy]

I wonder how much non-geek players would care. I fear that is more noisy than helpful. Why should I want to know mods before entering a server?

[appgurueu]

The plan I had in mind was that the "clients" button would be upgraded to a "more info" button, and the formspec updated to show both clients & mods (and everything else we want to add there in the future)

[cx384]

I wonder how much non-geek players would care. I fear that is more noisy than helpful. Why should I want to know mods before entering a server?

It's manly a preparation to add mod search.
I really like to filter the server list by mods.
In the past, I even wrote a python & bash script to manually search for servers which have mods I like.
In my opinion the noise is minimal, I even thought about adding more information like mapgen, protocol version, uptime, ...

The plan I had in mind was that the "clients" button would be upgraded to a "more info" button, and the formspec updated to show both clients & mods (and everything else we want to add there in the future)

Yeah, I also thought about this, but then made it separate to not create too much noise in the dialog.
At least for now, I think a separate button is better.

[siliconsniffer]

I agree, I think its okay to leave it as a button for now.
Ideally I'd like to have an issue for discussing design proposals for the info dialog (haven't opened one yet) before creating a PR. If that discussion comes to the conclusion that a separate button is too much noise we can still remove again.

Now to your PR itself:
I really like the icon and having these grayed out pictures is a nice addition.
The mods dialog is also well made but I think it would be nice to group modpacks in drop downs.

[cx384]

I think it would be nice to group modpacks in drop downs.

That's not possible, since servers don't send information about modpacks.

[siliconsniffer]

I think it would be nice to group modpacks in drop downs.

That's not possible, since servers don't send information about modpacks.

Wouldn't it be possible to sort them on the client by looking at the string of each mod?
Edit: Ah, I assumed that was unified - my bad.

[y5nw]

Wouldn't it be possible to sort them on the client by looking at the string of each mod?

In terms of looking for a (_-delimited) prefix, this will only work for many cases, but it can still generate false results: the Advtrains modpack has a serialize_lib mod (which does not have the advtrains_ prefix in its name), while a number of Advtrains-related mods (that are not part of the modpack) have the advtrains_ prefix in the technical name.

IMO it would be better to add a button (or use hypertext for the list) to perform a ContentDB search of the mod name. (That said, this is technically not guaranteed to be fully accurate either given the presence of custom mods, but IMO it should be safe to assume that most mods on servers come from CDB (or git, but whether a mod is retrieved from CDB or git should not matter for figuring out modnames) or derive from mods hosted on CDB or related sources)

[appgurueu]

I think grouping by "underscore prefix" is a nice to have feature (while definitely imperfect and not a must have). If two mods share a common prefix, they are probably related. In particular this applies to game mods like nc_* or modpacks like mesecons_*.

Ideally the server should probably send the hierarchical structure of the mods though.

[cx384]

Ok, I added a group by underscore prefix feature.

[siliconsniffer]

Looks good! I really like that you're both able to expand all and check out individual ones.

For me the "back"-button was confusing, at first sight I thought it would bring me back from the "modpack view" back to showing all mods. Maybe label it "OK" like in the clients dialog. "Exit" might be an option too.
For me the different color was enough to differentiate packs from single mods but maybe you could add some additional indicator like a ">" or something like this "▶"?

[cx384]

Rebased, now it looks like this:

[cx384]

I also replaced Back with OK and added a ▶ prefix to the group by prefix feature.

[siliconsniffer]

Nice! I've added a grayed out version for the URL icon, what do you think?

[cx384]

Resolved suggestions, and added the grayed out URL icon.

[appgurueu]

I've sent you a PR (cx384#3) which switches this to a table[] element, which I think is a bit neater here. What do you think?

[cx384]

Merged. (and rebased)
It doesn't matter much to me, I guess it's better.
I don't know it we need the "Expand all" mode, though, since it's just like the not "Group by prefix" mode.

[appgurueu]

I don't know it we need the "Expand all" mode, though, since it's just like the not "Group by prefix" mode.

Yeah, I don't know either. I thought it was a bit neater since it still preserves the grouping visually, but it's not much different. Feel free to remove it to simplify things a bit.

[cx384]

Let's keep it for now.