-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
Per World Configuration #24
Comments
Yeah, I don't see a need for inheritance either; if I were to do that I'd use a model similar to WorldGuard. Being that I haven't worked too much with configs I don't know how quickly I can get this done - I'll see how config options are used right now and see what I can do from there... hopefully config nodes are called in methods, not in class instantiation... That being said I'm also willing to accept PRs for this as well. |
This would be really great to have at least on a crude, per-feature level, as if building underneath yourself is set to true, players won't be able to reach the end cities by building towards them and disabling EHM for the end isn't an option due to the then disabled features makes the end not worth fighting in. If creating different configs for worlds isn't feasible, extending the |
Yea, not sure where I want to go with this although my time is much more limited this summer than I expected (as you can observe on my profile, nothing much going on for quite a few weeks). Seems the previous author left enough stuff that it seems it could be feasible to re-add such - but I'd also have to go about testing (as well as infrastructure for the separate config files), which I don't have time to do right now. Would greatly appreciate PRs though! |
EHM used to allow creating child configs so that each enabled world could have different options applied, and that functionality is still referenced on the Bukkit and Spigot pages for EHM. I would like to see per-world configs returned as EHM contains some features appropriate for most kinds of worlds and several features only appropriate for worlds committed to "hardcore".
It is worth noting that in the past, the per-world config included inheritance, which made things complicated. I don't think it's needed to support inheritance, just the ability to create one alternate config per world that completely determines what features are enabled for the special world.
Something like this...
config.yml
- applies to any world without its own configconfig_[worldname].yml
(orconfig_[other-selector].yml
) - For the relevant world, EHM only applies the custom config, nothing from the default config.yml.The text was updated successfully, but these errors were encountered: