Allow to use slug instead of id in game directory name
jerry1333 opened this issue · 9 comments
As title says using just id for game directory stinks and it's very hard to find game you are looking for.
Please allow to use just slug (or if you are worried about slug not being uniqe slug-id combination).
Thanks for the feedback. I was investigating this when implementing the grpc storage.
The overhead is greater than it seems because of the repair command which basically reconstructs an internal representation of the manifest from the storage (to compare it with the actual manifest and generate actions with the discrepancies that it finds) and you need the game ids for that, but I haven't given up on it.
It will just require that the game id gets mapped to each game directory in a separate structure in the storage for ease of reconstruction (but currently the tool doesn't do that so it will necessitate an adaptation).
Otherwise, separately from that effort, I'm also working one having a nice gui to view and download your games from your storage which might alleviate some of the problems.
EDIT: I remembered something else too. Sometimes, they change the slugs, but they never change the game ids. That also increases the complexity of using slugs for storage (where you either fixate the storage path to the initial slug and store the mapping or constantly update the storage path whenever the slug changes). Again, not an insurmountable obstacle, it just makes the problem less trivial than it seems.
I understand why it not here from the beginning.
From my point of view using $slug-$id would be good compromise (I have slug in directory name, app have id to work with and ignores slug if directory with this id exists).
Also this maybe an option to turn on for those who want it.
Another approach is to create header file inside game directory witch contains all information for app to work (.id file or something like that)?
For now I extracted id-slug pairs from json and renaming directories semi-automated way.
Thank You for looking into this!
I think optionally including the slug in the folder path in addition to a mandatory id would be a good starting compromise that is faster to implement.
An extra complication with allowing just the slug is the following: Sometimes, they'll release a remake of a given game and give the remake the exact same title as the original game (in which case they'll rename the original by including something like "classic" in the title).
A good example is Master of Orion where the original has the slug "master_of_orion_classic" (was probably "master_of_orion" before the remake) and the newer remake has the slug "master_of_orion" (essentially taking over the slug of the original game).
When that happens, there is a slug name clash that occurs and the ordering of operations is very sensitive (the directory of the original game should be renamed before the remake is added). Admittedly, it is an edge case, but it might happen to someone and I don't like bugs.
Obviously, the solution to avoid the edge case would be to add a new category of actions just to rename directories and always execute those actions first so it is doable, it is just more overhead than it initially seems.
EDIT: Something that just occurred to me that is simpler and far less error-prone (thought a bit less satisfying for the end user): Never rename game directory with slug changes and if there is a directory conflict with a new game entry, add some array notation suffix (ex: [2]) to the directory name of the new game that is conflicting.
A good example is Master of Orion where the original has the slug "master_of_orion_classic" (was probably "master_of_orion" before the remake) and the newer remake has the slug "master_of_orion" (essentially taking over the slug of the original game).
Maybe for this situation add confirmation dialog? In case someone wants to use tool in automated way you can add switch behavior (like force download changed names / ignore and download anyway / etc).
For me it's not an issue to download whole library again (~500GB) and probably will do it some day again since i have few new games.
A good example is Master of Orion where the original has the slug "master_of_orion_classic" (was probably "master_of_orion" before the remake) and the newer remake has the slug "master_of_orion" (essentially taking over the slug of the original game).
Maybe for this situation add confirmation dialog? In case someone wants to use tool in automated way you can add switch behavior (like force download changed names / ignore and download anyway / etc).
For me it's not an issue to download whole library again (~500GB) and probably will do it some day again since i have few new games.
In terms of implementation, while not as use friendly, I very much like the idea of fixating the directory name and never changing it (I don't think slugs change that often), appending a number when there is a conflict. The complexity to manage that would be well bounded.
Honestly, I'm unsure at this point if I'll implement the above feature as a direct part of the tool or whether I'll implement it as standalone grpc storage plugin (once I've finalized the grpc storage). I'll see once I'm there what makes the most sense.
In terms of timeline, there are some features I'll implement first because these are things I want for myself in the tool:
- Downloading all the metadata (description, screenshots, etc) and have a nice dashboard to visualize and download your games
- Support for error-resilient storages (mostly cloud, although a distributed local minio could fit that bill as well) and minimisation of downloads (for file integrity checks) on those storages when uploading file (mostly to minimise egress network costs on cloud solutions)
- Depending on the work required, I might also look at leveraging the Galaxy api, because I find the api the browser uses increasingly flaky
After the above, in terms of priority, it will be a toss between this and having a cross-platform gui complementary tool to run the commands seamlessly from a user interface (not things I desperately need for myself, but interesting technical challenges and a good final layer of polish for the tool).
I've just been looking through the source for the argument that would enable saving by slug because I was surprised it wasn't in the usage examples and would not have believed for a second that only the ID was available. Please do add this. The inability to save by slug (or $slug-$id or basically any combination other than $id alone) is actually a blocker and I'll need to look for a different tool for now.
The whole purpose of a tool like this is to download your library to give you easy offline access to it. Needing to know that 42353456426234523 means Quake 3 or whatever is not what I'd call "easy access".
While waiting for new version of gogcli I've created this tool:
https://github.com/jerry1333/gogcli-renamer
This is not a solution to this issue/enchantment as renaming library will make it unusable with gogcli in future but it's something :)
There are a couple of things I really want to add to the tool (and limited time to do so, so it won't be immediate):
- A built-in dashboard (similar experience to the GOG library combined with game details) to view and access your games
- A plugable grpc storage engine
- A user-interface for a more high-level experience managing backups
I would probably implement this as a storage engine in 2. However, my most immediate priority when I have time to work on gogcli is 1 (this is something I really want for myself) and I am guessing it might solve the usability use-case of trying to access game directories by id for a lot of people.
There's no rush, I found a workaround so you can proceed as planned.
Thanks for a brilliant tool!