Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Per Modpack import configuration #213

Open
fosspill opened this issue Sep 15, 2020 · 7 comments
Open

[FEATURE] Per Modpack import configuration #213

fosspill opened this issue Sep 15, 2020 · 7 comments
Labels
on hold Issue is on hold, but you can always work on it yourself. PRs always welcome!

Comments

@fosspill
Copy link
Owner

Yes, I also agree that the Dry Run options could be an excellent solution, combined with your idea above of separate configs per-modpack. Big full-wizard modpacks like the Hair Defined would be so much more manageable that way.

Originally posted by @taylor85345 in #212 (comment)

@fosspill
Copy link
Owner Author

fosspill commented Sep 15, 2020

Intro

The config file contains:

  • The name of the modpack!
  • The SHA sum of the modpack, so we can sanity check.
  • The chosen method (Wizard / All). Doing All would override the next point.
  • The Enabled and Disabled mods.

json may be the logical choice, but I do like the way our global config file is parsed so maybe that would be a cleaner choice.

For huge modpacks this will still be a bit clunky, but it feels like a good balance between usability and flexibility.

Config generation

ffmt import mymodpack.ttmp2 --generate-config (or something alike)

This would result in a configuration file being generated after completing normal "import procedures"

Config use

ffmt import mymodpack.ttmp2 mymodpack2.ttmp2 --configuration-file mymodpack.ttmp2.config could work and would let people decide which modspacks to override.
We could also just load the config when it is in the same folder and give the user an option to use the config.

a --use-configurationfiles type flag to override --all is also a nice option

Scratchpad for command ideas:

Name based, not positional:
ffmt import mymodpack.ttmp2 mymodpack2.ttmp2 --configuration-file mymodpack.ttmp2.config

ffmt import mymodpack.ttmp2 mymodpack2.ttmp2 mymodpack.ttmp2.config

@fosspill
Copy link
Owner Author

dry-run is done, next up is saving the information somewhere instead of doing absolutely nothing

@zeparu
Copy link

zeparu commented May 22, 2021

any updates on this btw? or any other method of not needing to reinstall all mods with all options manually? i think in most guides for textools, they just tell you to combine all installed modpacks into one giant modpack which you can then install again

@fosspill
Copy link
Owner Author

fosspill commented May 22, 2021

Thanks for nagging a bit! Truth be told, I recently became a parent and am therefore a bit behind on many things I'd like to do - this is one of them. The other main contributor - @shinnova - is the other parent, so in general FFMT will move at a pretty slow pace when it comes to large changes.

With all that said, I've looked a bit at the framework and I wonder if we could throw together a relatively simple "make modpack" command which takes everything you have enabled and makes it a valid modpack for you to later import again, like you mentioned.
It wouldn't cover all the needs, but it seems to me like that'll be fast enough that we can knock it out before the next large game patch!

@shinnova, you are much better versed in the framework than I am, what do you think? Could we throw together a barebones command to make a modpack out of all your imported mods?

@shinnova
Copy link
Collaborator

@shinnova, you are much better versed in the framework than I am, what do you think? Could we throw together a barebones command to make a modpack out of all your imported mods?

It looks really easy to implement a simple version of modpack creation. I'll make a quick version which will make a modpack out of your currently enabled mods.

@fosspill
Copy link
Owner Author

Modpack creation is currently being worked on in #8
The modpack configuration files, however, aren't. It honestly may be too much work for a nice-to-have feature when modpack creation is in place.

If something like this issue is still needed I'd rather cache the previous selection and ask if the user would like to re-use that during wizard import (and with a flag).

@fosspill
Copy link
Owner Author

This is now partially resolved with the in https://github.com/fosspill/FFXIV_Modding_Tool/releases/tag/v0.9.10

@fosspill fosspill added the on hold Issue is on hold, but you can always work on it yourself. PRs always welcome! label Dec 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
on hold Issue is on hold, but you can always work on it yourself. PRs always welcome!
Projects
None yet
Development

No branches or pull requests

3 participants