The Road to 1.0

[derrod]

While it will still take a while to get there, 1.0 is something of a milestone that I want to reach eventually. While it will not contain some of the originally planned features (mainly a GUI) it will contain several major changes to how legendary works internally and its APIs.

This post is to lay out some of the planned changes and why they're done.

API Changes

• Remove anything that exposes GameAsset directly (e.g. LegendaryCore.get_asset())

• The asset class is only relevant internally, the main reason it was used outside of the core was for legacy code reasons. It doesn't really make sense to use it instead of Game in most cases

• Changing parameter mess into configuration objects (e.g. dataclass)

• This is mainly for the downloader and launch parts, which currently have a ton of parameters. Instead of that there will be a LaunchConfiguration class that contains all the options, this will also make it easier to pass the configuration around and modify it, e.g. in a dedicated piece of code for handling game workarounds

• General cleanup/renaming of methods

Downloader changes

The downloader requires a general rewrite with a lot of cleanup, the basic plan looks like follows:

The downloader will be broken into two:

• asnycio based
• multiprocessing based

The reasoning for this is mostly to reduce overhead by default (with asyncio) while still retaining an option that can reach and exceed the current downloader's speeds (via multiprocessing). An asyncio based approach has shown to be slower in local tests, mainly due to the fact that zlib decompression will still be limited to one CPU thread (thanks GIL). But a multiprocessing approach is messy and annoying to manage. The newer MP based downloader would also only use a few workers that themselves use asyncio or python threads to run multiple concurrent downloads, but still maintain higher speed due to real mutli-threaded decompression.

Additionally the parts currently part of the "manager" such as the analyzer will be moved into their own package as well to make them more easily reusable and testable.

In-place patching for files that only have smaller changes that would not require a complete rewrite. This would not be resumable but can be much much faster than the current approach, especially with games like Fortnite that have large PAKs that only need to be partially overwritten with some updates.

Of course issues such as #17 should also be addressed while we're at it.

Model changes

TBD, but probably some changes to Game and GameAsset.

CLI changes

The CLI interface shall remain mostly the same to the outside, with changes mainly being internal.

• Add progress bars (Download Progress Bar #23)
• Support for selective downnloading (through prompts)
• More business logic should be moved to the core (where possible/sensible)
• Cleaner argparse setup would be desireable

Other internal changes

Reading and writing JSON files isn't great. Loading them all on startup also isn't. For the future I want to investigate a deferred approach (game metadata files are only read when needed) or maybe switch to a "real" database (e.g. SQLite) entirely.

The LegendaryCore class is too large/bloated, that much is obvious. For that purpose I might want to move certain pats (e.g. EGL Sync) into their own file and split that up. But I'm not sure whether that's practical or not.

Anything that currently does web requests in the core or to epic's APIs also does not have any form of error handling. That isn't a huge issues since legendary is not meant to stay alive for long so a failure will simply result in a user restarting the process. But that's still annoying and there should be basic retry logic and some error handling that can fail more gracefully.

The WINE configuration should be used more extensively and also saved to some extent. For instance for addressing #41 it would make sense to have legendary keep track of the last wine prefix used to launch a given application.

Longer term goals

• Better support for savegames (legendary keeps running until game closes, then automatically syncs)

• Also needs better EGL support

• Extra launch options need to be supported for VR games etc.