-
Notifications
You must be signed in to change notification settings - Fork 5
Documentation (sort of)
Should be mostly self-explanatory. Start by adding games, with or without playthroughs. Click games in the respective tables to open the game editor with additional information on the game, as well as the option to add/edit/remove
The icon is stored in the assets folder, if you want to use a custom one simply add a volume - your_assets_dir:/files/assets using your docker compose file and put your custom icon as Slaanesh.png in there. It will automatically be used both as favicon and header logo.
The sample config file has all possible options set. Just take a look there for the syntax. Except for the IGDB client id and secret, you can delete any entries/sections, Slaanesh will then go with its defaults (which are the ones in the sample config file).
IGDB client ID and secret are mandatory.
In order to not hammer the API, a lock-out after an API update is set. Within that time, a game will not update from the API, even if you click the update button. Defaults to 1 hour.
You can set custom platforms and status categories. The first entry in a section is used as default value when approriate (e.g. pre-filling selection boxes etc.).
The default platform list is very small, but you can add any platforms you want to distinguish in this section.
The respective game status sections work the same way, althoug the defaults should be reasonably comprehensive here. You can add additional categories or rename the default ones if you prefer. Since categories are fully customisable, you can set them up any way you want. The defaults assume:
- Playing
- playing - currently playing
- on hold - started playing, but paused until further notice, still plan to complete eventually
- re-playing - already has a playthrough logged, playing it again
- Played
- completed - finished a playthrough, seen the credits
- discarded - didn't like, stopped playing, don't plan to pick it up again
- mastered - more than just seen the credits, e.g. played a lot of multiplayer, did 100% of all achievements etc.
- re-playing - see above
- re-play - see below
- Backlog
- backlog - owned and ready to play
- waiting - owned but not ready to play because waiting for a pre-condition (e.g. game is part 2 of a series, want to play part 1 first)
- re-play - already has a playthrough logged, want to play it again eventually
- Wishlist
- wishlist - not owned, but plan on playing once I get my hands on it (might not even be released yet - release status is determined automatically based on IGDB API data)
As you can see in the sample config, you can have the same status in two groups, e.g. "re-play" status in both played and backlog, resulting in the game showing up in your played table as well as in your backlog since you want to play it again. Or "playing again" in playing and played, making it show up both in your active playing tab as well as your played list, for games you are currently re-playing. Arbitrary combinations are possible.
Be aware: If you remove entries, make sure to not leave an empty section. That will lead to empty tables and some menu defaults not working. Delete the full section in order to use the Slaanesh defaults (or simply leave the default config file as-is).
Be more aware: If you already have data in Slaanesh, removing an entry that is in use will lead to an inconsistent database. Either edit entries in Slaanesh manually so that an entry is not in use before removing it, or export your data as csv, bulk-edit your status/platform entries there, clear the database, and re-import the list from your updated csv.
Many aspects of the UI are configurable. Names should be largely self-explanatory. Widths and height change the respective sizes, color coding makes it easier to distinguish between completed and discarded games. For the tab display, you can chose between cards and table layouts.
There is very little error handling around the import, which means the csv format has to be pretty much exactly right for it to work. If you are starting fresh and want to import your current spreadsheet-based list, best add a couple random games with the UI first, export them and use that format to populate your import csv with your own data.
The import csv needs and reads all columns, both for the game list as well as the playthrough list. The playthrough list is fully used and relevant, but many columns of the game list will be overwritten anyway when doing an API data update. Which means you can fill those with random values that match the required format (so that the import still works) and do an API update to get them all populated properly automatically. The only columns that won't be overwritten with API data are: IGDB ID, Platform, Status, Comment.
You need the IGDB ID for imports to work - for every game you want to import, a single missing ID will fail the import. In case you have a huge list of games you want to import, mapping it manually is quite annoying. That's why there is a nice helper textbox in the settings menu. You can paste a list of game names and you'll receive a csv export of these names with their IGDB IDs in the export directory. Names are matched exactly, no fuzzy search, so unless you use the exact IGDB name, you will probably still have to manually add a few IDs. But it should still make importing a large number of games a whole lot easier.
The API data update doesn't happen automatically after an import, you have to click it in the settings menu.
There is a thread running in the background, checking for game IDs that need API metadata. In order to not overwhelm the API, it only calls in chunks and only every few seconds, which is why updating a large number of games can take a while.
Searching a game by name will fire off an API call for this one game to get its ID. In theory, if a background API update happens to be active at the same time (e.g. when having pressed the update API utility function shortly beforehand), a collision and an API refusal due to too frequent requests is possible. Chances of this happening should be extremely low, though. If in doubt, don't add a game by name while any other API updates are still running in the background. But even if such a collision happens, it won't break anything, if some games don't update properly the API update can simply be re-started or they can be updated manually from within the game editor.
You can close all other dialogs by simply clicking besides them or pressing esc. Not so with the game editor. The reason being that the game editor is called by clicking an entry in a table, and the table is refreshable. Which means the object that calls the editor is destroyed when refreshing the ui, meaning refreshing the ui closes the editor. I haven't found an easy fix for that, and obviously I want the editor to stay open while making edits to the game. But I also want it to update with these edits while making them. The “solution” is to just update the game editor, not the whole ui. But for the tables to show the correct entries after the editor closes, they have to be updated. Which happens when clicking the close button. Which also means that I had to disable all other ways of closing the game editor, so that the tables really get updated.
Removing the last playthrough of a game will automatically change its status to the first entry in the backlog category. Similarly, the first entry of a status category is usually used as default in edit boxes - e.g. when adding a playthrough, the first entry of the played category is pre-filled in the selection box. Same for the platform when adding a game. You can order the categories in the config file so that your most used entries are at the top, saving you some clicks on selection boxes.