feat: add details to mod pack downloading
feat: add logging rule sloading form `ligging.ini at data path root
feat: add `launcher.task` `launcher.task.net` and `launcher.task.net.[down|up]load` logging categories
fix: add new subtask progress to the end of the lay out not the beginning (cuts down on flickering)
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
Oh boy this is big.
> TaskStepProgress struct is now QMetaObject compatabile and can be sent through signals
> Task now has a method to propogates sub task progress it must be signal bound by each task containing a task wishing to report progress of it's children.
> Downloads report speed
> Tasks now have UUIDS to track them
- use when reporting
- use when logging
- use when storeing them or objects related to them
Signed-off-by: Rachel Powers <508861+Ryex@users.noreply.github.com>
This turns issues like creating two shared ptrs from a single raw ptr
from popping up at runtime, instead making them a compile error.
Signed-off-by: flow <flowlnlnln@gmail.com>
This allows us to pass to the creation instances their actual pack ID
and version ID, that in Flame's case, are only available before starting
to create an instance.
Signed-off-by: flow <flowlnlnln@gmail.com>
It will never be there anyways, and saves a **bunch** of time when the
overrides folder is big and we traverse all the tree when searching for
the MMC 'instance.cfg' file.
Signed-off-by: flow <flowlnlnln@gmail.com>
While working on pack updating, instance naming always gets in the way,
since we need both way of respecting the user's name choice, and a
standarized way of getting the original pack name / version.
This tries to circunvent such problems by abstracting away the naming
schema into it's own struct, holding both the original name / version,
and the user-defined name, so that everyone can be happy and world peace
can be achieved! (at least that's what i'd hope :c).
Signed-off-by: flow <flowlnlnln@gmail.com>
* Use the bulk endpoint on mod resolution for faster download
* Search on modrinth for api blocked mods
* Display a dialog for manually downloading blocked mods
Flame modpacks use "manifest.json" as their only characteristic for
identification. Some modpacks might have other files called
"manifest.json", which is why we should prefer modpack formats that have
a stricter structure.
This disables the optional mods by default and tell the user about it.
Pretty hackish, but a better solution would involve the modrinth
metadata to have the mod names...
Also sorry for the diffs, my clangd went rogue x.x
