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

Mod Management #9

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Mod Management #9

wants to merge 2 commits into from

Conversation

vVqpVv
Copy link

@vVqpVv vVqpVv commented Jan 20, 2020

  • Added a few classes and interfaces for the ModManager.
  • Added activation support for mods. The mod list is now a button list and the mods can be activated or deactivated by clicking.
    -- Coloring green/gray.
    -- Excluded Framework mod from actions.
  • Changed ModLoader and more to support ModManager.
  • Changed ModBase to support Cleanup on deactivation.
  • Added de language.
  • Tested.

TODOs:

  • Maybe changing the Patcher for a better ModManger support.
  • Rewrite the ModListGameState

* Added a few classes and interfaces for the ModManager.
* Added activation support for mods. The mod list is now a button list and the mods can be activated or deactivated by clicking.
- Coloring green/gray.
- Excluded Framework mod from actions.
* Changed ModLoader and more to support ModManager.
* Changed ModBase to support Cleanup on deactivation.
* Added de language.
* Tested.

TODOs:
- Maybe changing the Patcher for a better ModManger support.
- Rewrite the ModListGameState
@solidDoWant
Copy link
Owner

Thanks for the PR. Before I merge, I have a few questions and things that need changed:

  • All files need to be cleaned up and need to match the style of the rest of the project
  • Why "fmod_titlemenu" instead of "mod_titlemenu"?
  • Change does not appear to be backwards compatible (https://github.com/solidDoWant/Planetbase-Framework/pull/9/files#diff-0ca45d8bae2e5af4c5dcebc06955a255R38)
  • Mod updating should be kept in the mod loader class
  • Whether or not a mod is active should be a property of ModBase
  • Don't use Console class to log things - Debug class only until I implement a logger (in my next update or two)
  • While the framework probably needs a class for serializing/saving/loading configuration data, I'm not sure IModConfig or SimpleFileBasedModConfig implementation are the best ways to do it. This is something I've been thinking about for awhile and the framework probably needs something maintainable and extensible, probably implemented as a JSON or XML file.
  • you mentioned above that you might want like some changes to the patcher to facilitate better manager support. What would these changes look like? Any action that needs to be taken after the framework is injected should be possible via the framework and/or Harmony.

Overall I think this is a decent idea and I've been thinking about implementing a number of the items in it, but the PR needs some work before it's ready to be merged. Additionally there are some fairly large architectural changes here and I need to give them some thought. If you can work on the items above I'll give the structure some thought.

@vVqpVv
Copy link
Author

vVqpVv commented Jan 20, 2020

Yea, im in a gtihub project ;D
I follow you're instructions, "master" ;)

The changes are just a weekend session. Many dirty flows and no concept.
I just pull the changes to see, if there is interest to develop this little gem.
So I cleanup my code and starting conceptional mode.
I'll draw some pics.

* Added legacy load functionality
* Removed unused imports
@vVqpVv
Copy link
Author

vVqpVv commented Jan 20, 2020

All files need to be cleaned up and need to match the style of the rest of the project

  • Done

Why "fmod_titlemenu" instead of "mod_titlemenu"?

  • The StringList from planetbase is without context, so the fmod prefix indicates the framework mod to avoid unwanted overrides.

Change does not appear to be backwards compatible

  • Added legacy load functionality

Mod updating should be kept in the mod loader class

  • I like jobs to be named like the job. So a ModLoader isnt a mod updater. But I dont want to discuss a single call.

Whether or not a mod is active should be a property of ModBase

  • Dont put more data in the functionality class ModBase. I think its better to create a file like mod.xml in the mod directory to store meta data (like FarmingSimulator). And the behavior to activate is handled by ModManager as the main unit of the mods.

Don't use Console class to log things - Debug class only until I implement a logger (in my next update or two)

  • yes

While the framework probably needs a class for seri[..]

  • yes, my ModConfig is just a dirty start to remember activated mods.

you mentioned above that you might want like some[..]

  • Just my thoughts, but never touch a running system, i know ;)

@NeoRider7
Copy link

NeoRider7 commented Jan 31, 2022

Added activation support for mods. The mod list is now a button list and the mods can be activated or deactivated by clicking.
-- Coloring green/gray.

Looks like I missed something important with the mods for this game! :-)
Do I understand correctly that it is possible to repeatedly enable and disable various mods during one game session?
And does this tool have a tool that highlights working and non-working mods?

Please send a screenshot of what it looks like!
Very interesting!

@solidDoWant
Copy link
Owner

solidDoWant commented Jan 31, 2022

@NeoRider7 This has not been merged and as such is not currently a part of the framework. To be completely honest this was opened around the time I stopped working on PB so I can't remember what the current state of the PR is/if it need work before merging. If I were to get back into writing mods for PB I'd have to review the codebase to see if anything needs changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants