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

Profile system #163

Open
Ruin0x11 opened this issue Mar 2, 2021 · 0 comments
Open

Profile system #163

Ruin0x11 opened this issue Mar 2, 2021 · 0 comments
Labels
design Concerns the architecture of the engine enhancement New feature or request modding Concerns new modding features beyond the scope of porting vanilla's codebase. refactoring This requires refactoring existing code

Comments

@Ruin0x11
Copy link
Owner

Ruin0x11 commented Mar 2, 2021

This is inevitable, because upgrading mods isn't a well-supported use case, and everyone else does it in their own modding scenes anyway.

Right now, there is no path redirection for things like require("mod.my_mod.api.Whatever"). There is an assumption that you will only ever have one version of a mod "installed" at a time, which right now means "it exists in the mod folder."

The profile system would enable you to have more than one version of a mod installed. "Installed" in this case would now mean "there is a version X.Y.Z of this mod available for profiles to use." There would be some saved metadata that points to the profile to use, and each profile would get its own folder and some kind of active_mods list that contains the mod paths to load. Per profile, only one copy of a mod would be active at a time, the same as it is now. mod would now contain folders like evolution-0.1.0 and evolution-0.2.1 beside one another, but otherwise their contents would remain exactly the same as before.

Then the runtime would do some require path hackery in env to redirect paths under mod.<...> to point to the currently active mod. The list of mods to load would be separate from config, as it needs to be loaded very early in the startup cycle.

As a user, you would be able to create and switch profiles from the title screen, but the changes would only get applied on the next startup. There would be one "default" profile with only the base mods (base, elona) that gets generated on first run, and the rest you can add in whatever else you want.

Save files (and their backups, from #158) would be partitioned per profile.

Eventually we might consider adding a "locking/unlocking" mechanism like npm's lockfiles so you can upgrade mods, but because upgrading mods is a very complex feature I'd rather put it off until the need becomes pressing. For now, if you have at least one save inside a profile and you want to change its mod configuration in an incompatible way (anything besides adding a new mod that doesn't cause a dependent version incompatibility) then you'd have to duplicate the profile first, along with its saves.

@Ruin0x11 Ruin0x11 added enhancement New feature or request design Concerns the architecture of the engine refactoring This requires refactoring existing code modding Concerns new modding features beyond the scope of porting vanilla's codebase. and removed design Concerns the architecture of the engine labels Mar 2, 2021
@Ruin0x11 Ruin0x11 added this to To do in Playable state via automation Apr 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Concerns the architecture of the engine enhancement New feature or request modding Concerns new modding features beyond the scope of porting vanilla's codebase. refactoring This requires refactoring existing code
Projects
Playable state
  
To do
Development

No branches or pull requests

1 participant