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

Suggestion | Vane Regions: several suggestions #200

Open
knniDE opened this issue Jun 29, 2023 · 2 comments
Open

Suggestion | Vane Regions: several suggestions #200

knniDE opened this issue Jun 29, 2023 · 2 comments

Comments

@knniDE
Copy link

knniDE commented Jun 29, 2023

1. auto Y min to max

I would very much like the regions players create to go from -64 to 383 (? max build height) automatically. Gladly configurable for all.
For players like my friends and I, then there wouldn't be the hassle of having to dig to point Y so you can have everything secured under one base for future projects.

2. merging regions

If a region already exists and the player wants to extend his region (because he needs more space, for example), it is cumbersome to determine the edges of the current region. I would be in favor that one can be created e.g. another region and if both are called the same and/or overlap, merge.
If necessary, extend the existing region.

3. worldguard flags (special)

I know someone already suggested this 1.5 years ago (#61). It was said then that there was a bridge plugin. Unfortunately I have not found it (?). Would it be possible to provide an integration or similar? I have RealisticSeasons on my server and I would like to enable the players to turn off the snow in winter for their region via Worldguard. If a direct communication with RealisticSeasons would work, it would be even better. :D

thanks for everything oddlama <3

@oddlama
Copy link
Owner

oddlama commented Jul 1, 2023

Thanks for the suggestions!

  1. auto Y min to max

Agree, that's probably a nice feature for some and it's relatively easy to implement.

  1. merging regions

That's why there are region groups, so you can add new regions with the same settings at any time. But you are right, I believe overlaps would still be rejected, so you'd have to know where the current region ends. It's not entirely trivial to merge them (they need to be cuboids) and allowing overlaps could theoretically lead to weird problems when two overlapping regions have different settings (players will not notice and wonder why settings are ineffective). But allowing overlaps as a config option for those who want it with a disclaimer would be possible.

worldguard flags (special)

This one is a little tricky. The comment in #61 wasn't saying that there is a bridge plugin, just that someone could make such a bridge without requiring vane to do it. Of course a first-class integration would be best, but I personally don't want to do it for several reasons.

WorldGuard requires integrations to create "WorldGuard Regions" to manage anything, they can't re-use the regions defined by vane. This duplication will inevitably lead to problems down the line. It's easy to get a mismatch in regions when the user disables one plugin, or changes the world in use (vane stores information in the world, worldguard just stores it globally).

I think you just want to have a worldguard region for each vane region (so you can disable your season stuff), but #61 for example wanted an entirely different feature which would require us to create worldguard specific flags for every single thing vane introduces, which would be madness.

I'm not opposed to having such an integration (with disclaimers), but it would be an unreasonably huge amount much work and probably not even function correctly the way users would expect it to. So it's unlikely that I'll ever do it if nobody else takes this up. The truth is that vane's regions were never designed for complex integrations with other plugins, but instead as a simple batteries-included region system.

I'll probably implement something for 1 and 2 at some time, but I just don't know currently when I will have enough time to push the development of those.

@knniDE
Copy link
Author

knniDE commented Jul 2, 2023

No problem, master!

Ah I understand everything. Yes, I was already aware that 3. is a bit more complex. thank you for explaining it so extensively that it is comprehensible for me.

regarding 2. I had the idea to make this chunk based. That the users select the respective chunks that should be a region. This would definitely make it possible to work and act more presciently, and would (probably) be easier to implement. But would probably also be a lot of work to restructure this.

I'm already sorry that I cause you effort. Take your time if you have it <3
Thank you all times for your work.

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

No branches or pull requests

2 participants