spore-community / modbrowser Goto Github PK

Currently it still shows the current datetime (from debug). Need to get the datetime from the github download, and display it there instead

Need to change how the menu displays, and adjust the ModListing component to reflow for narrower screens

The buttons may be better hidden behind a dropdown or something. especially as most mobile users won't likely be downloading mods (but some people may still need the option, i.e. if they have no wifi and want to use their phone to download mods)

All other pages should be fine as-is

The mod installation instruction page still says that there are issues running mods on Steam Spore, in spite of the fix for Steam Spore that was released recently for the Spore ModAPI Launcher Kit.

Currently the only sort option is number of downloads

Add a system for pulling images from the github repo, to provide a preview

This image could be displayed to the left of the buttons, and just wrap the description narrower (this would probably be cleanest, since not all mods will have images)

Github API allows download counts for releases to be retrieved. Display this in the UI, and add it as an option for the user to sort search results (Most Popular)

dotnet/aspnetcore#19796

Need to make sure when committing the published app to gh-pages branch, that the .gitattributes file is present. Only occurs when pushing from Windows. If everything can be done in Actions then this should not be an issue

Pages that display details on a specific mod, pulling from the readme.md file in the github repo

The github api has a feature (accept header) to return formatted HTML for the readme, we can just toss this onto the page

In case someone decides to put a malicious/stolen/broken mod on github, since we can't remove it from github, we need to filter these mods out of the mod browser

A blacklist file can be present in one the branches, can be as simple as one line per entry, like this:

owner/repo1 This mod has been blacklisted as it is known to damage other mods.
owner/repo2
owner/repo3 This mod belongs to another person. Only the original creator may upload their mod.

In this example I show an optional description, can be displayed in a "troubleshooting" page, where modders can go to check why their mod isn't appearing on the mod browser.
If SMM has a feature to download/update mods, it should probably respect this blacklist by default (potentially, let the user turn this feature off, after warning them), and maybe show the description so the user knows why this mod can't be installed/updated.

The app(s) (or rather the library) should download this blacklist on startup, parse it into a dictionary, and filter out any search results that match the listed repos

Some way to creates lists of featured mods

Questions: who should pick features? Do we want to have one featured list, chosen by a committee? Should different discords or individuals be able to curate their own lists? Should there be a UI for any user to make their own mod lists?

If any user can create a list, possibly have a feature where a list could be marked as a "modpack", and all mods on the list can be downloaded in one click

Need to retrieve download links from github releases

Just need the latest (non prerelease) .sporemod file

Maybe support .package too, depending on what modders ask for (i.e. if they say making a sporemod is too hard, and we can't find an easier way to make them in the near future, then we should have the option for them to use package files instead)

When user downloads a mod that requires galaxy reset, provide them with a link to a page that explains how to do this

This tool is using client-side unauthenticated requests to the GitHub API, which have a rate limit of 60 requests per hour per IP address. CGNAT shares an IP address with thousands of users doing who knows what, so chances are the rate limit will be exhausted very quickly every time it resets, rendering this tool essentially unusable.

The only solution is, unfortunately, to move the API requests to the server side and use GitHub's OAuth2 flow to obtain a token which can be sent in requests to the API. You'll likely also need to implement some sort of server-side caching to avoid hitting the authenticated rate limit. Re-reading the documentation, I think you can allow the user to "sign in" with their GitHub account, and grant the application an OAuth2 token unique to them which can be held in local storage. This way, the requests can remain client-side and are tied to each user rather than the whole server.

Here's a link to the relevant documentation: https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting