Allow per-player world borders about spongeapi HOT 19 CLOSED

so that even entities can have their own world border

There's a point at which you must stop thinking whether you can and think about whether you should.

Seriously, this issue is summed up with Players having the ability to have their own rendered WorldBorder, since it's perfectly able to control from the server as to what the world border is per player, just no one has written an API for it, nor an implementation.

from spongeapi.

@Kobata can you detail why this is difficult to implement specificially? Maybe an example of how it has to be done?

from spongeapi.

To properly handle per-player world borders every check (I can't give you an exact list) that acts on a player (or entity that could be a player) needs to be updated to check against that specific player's border, or delegate to the world if no specific border is set up. We've generally not been very well equipped to make such invasive changes, mixins are somewhat unwieldy if you want to pull off alterations of code rather than additions, as you have to copy in the entire method to change small sections, and we should generally be very minimalistic (as completely avoiding it is somewhat unfeasible) on including any mojang code directly.

Per-world is relatively easy, because, other than saving them and weirdness with WorldProviderNether, it's already a per-world system, just with change listeners set up on the master world to update each subworld by default.

from spongeapi.

Hmm. I'm actually in support of making world borders per-player, I think it's a reasonably useful for plugins and its being blocked by the way our current implementation handles changes. I'd like to know if maybe there's an easier/better way. @Mumfrey has been working a lot with our code injection, any input?

from spongeapi.

this might be easier on implementation if we move some of the hooks out to forge

from spongeapi.

That sounds about right.

from spongeapi.

I think it's time to revisit this issue.

Mixins have changed significantly since I first brought this up. With injection support, it's much more feasible to accomplish this in the Forge implementation.

from spongeapi.

This feature is related to the following issue: http://issues.spongepowered.org/youtrack/issue/SPONGE-54

from spongeapi.

@Kobata: Any thoughts on this?

from spongeapi.

Insert rant about overuse of injections

(We should be being as non-invasive as possible for update reasons)

from spongeapi.

I'll update the Mixins you worry about good api.

from spongeapi.

That's true, but the official implementation is only one of several. As much as possible, we shouldn't let the specific challenges for one particular implementation influence API design (assuming the idea is technically feasible protocol or client wise).

from spongeapi.

@Kobata

There is a strong difference between injections and overwrites. Were we just overwriting everything I'd understand your rant.

from spongeapi.

@Zidane From the perspective of just updating MC, I'd put the order of 'ease of updating' source patch [forge/cauldron] -> overwrite -> injection. The first two are very easy to see exactly what changed on both sides, and not amazingly hard to update, if rather much grunt work. Injections on the other hand, while nice for other reasons, are very likely to break in strange ways and require more detailed knowledge on the part of the person updating them.

from spongeapi.

@Kobata

Injections are necessary to not break other mods. Your perspective is noted but we've come to terms a while back of the checks and balances of overwriting everything.

In your own words you mentioned about being non-invasive. I'd argue that overwrites are moreso as the MixinTransformer gets "final say" above all other transformers and if a mod messes with a method we overwrite, suddenly their code blows up and we become incompatible with them.

from spongeapi.

After looking at the World Border code, I understand why Kobata is against this. I feel this would be extremely difficult to implement and cause a decrease in performance due to the checks that will be constantly performed.

from spongeapi.

Would it be possible to just send the effect to the client, and leave plugins to re-implement the actual cancelling of move events / damage events?

This would additionally give them more control.

from spongeapi.

Should the world border be for different permission groups or scoreboard teams, so that even entities can have their own world border? The border may be stored in the permission or the scoreboard.

from spongeapi.

How about the API be something like this (note that this hypothetical API would allow both per-player AND per-world borders):

• Player/Entity and maybe World/Extent inheriting from a supposed Borderable interface which contains some methods like getBorder() returning an Optional<WorldBorder> and setBorder(WorldBorder), or a single method called border() returning some sort of BorderData, both cases would allow both getting and setting the border.
• If not the above, maybe a getWorldBorder() in Player/Entity which returns either a WorldBorder or an Optional<WorldBorder> (there is already a getWorldBorder() method in World which could be moved to Extent, if possible).
• ChangeBorderEvent to allow plugins to track the change of the world border. It would contain a getPreviousBorder() for the border that is in use (and is being replaced) and getNewBorder() for the border that is going to be used. It could have Player/Entity and World/Extent sub-events, which are fired depending on which border was changed.

from spongeapi.