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

add mount/dismount vehicles/animals flags #426

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

chestnutcase
Copy link

This PR aims to address inconsistencies and unexpected surprises with the current ride region flag, while maintaining backward compatibility.

Prevents players from dismounting both vehicles and animals in protected regions where ride is denied

Previously, in regions with the ride flag set to deny, players would be prevented from dismounting their animals inside because they cannot get back on. However, this does not apply to vehicles (e.g. minecarts), despite the documentation stating the ride flag applies to both vehicles and animals. This can lead to other problems such as abandoned minecarts in rail systems clogging up the system because they cannot get back on after they exit.

More granular flags for dismounting/mounting vehicles/animals

My proposed solution is to separate the animals and vehicles flags entirely, as well as decouple mounting and dismounting permissions. Examples of use:

  • A metro system would have two global regions: one for tunnels, and one for station platforms. Tunnels would set dismount-vehicles to DENY to prevent players from exiting while the cart is in transit between stations, while the platforms will have mount-vehicles and dismount-vehicles set to ALLOW.

  • A adventure map / pvp arena that requires players to remain mounted in their horses at all times while within the region would set dismount-animals to DENY within the arena grounds, while setting a separate staging area (the entrance) to allow them to mount and dismount freely before entering the grounds.

Don't let interact determine mounting/dismounting permissions

Currently, if the interact flag (meant for buttons and doors) is set to ALLOW, users will still be able to mount/dismount from minecarts. Since we already have ride (and with my PR, more granular permissions targeting vehicles specifically), I suggest removing the interact flag from the permissions query for vehicle entry and exit.

Backward compatibility with the existing ride flag

If this granular permissions is favourable to you, I suggest deprecating the ride flag. For backwards compatibility, my implementation lets the existing ride flag override my new flags:

  • If dismount-vehicles is set to DENY but ride is set to ALLOW, allow dismount;
  • If mount-vehicles is set to DENY but ride is set to ALLOW, allow mounting.

This gives server admins time to revise their region flags without their players suddenly being unable to mount or dismount vehicles or animals after upgrading.

Copy link
Collaborator

@wizjany wizjany left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before getting into the semantics: please maintain syntactical social distancing with your braces. there's lots of missing spaces.

So, to address each major point:

  1. No problems here. Obviously even the docs thought ride should apply to vehicles.

  2. This seems generally ok though I struggle to see why you'd want separate mount/dismount flags. Even in your use-case it seems a bit shaky - if you can't dismount your minecart in the tunnel, why should you need to mount one? Unless you somehow get knocked out I guess? On one hand, extra granularity isn't bad, but on the other it can lead to bloat not just for the code but for people trying to mentally manage a large amount of flags. I think this is probably ok here, I just always try to evaluate whether the benefit of adding flags is as a whole more useful than not.

  3. Agree with this. It's technically a behavioral breaking change but there precedent: d37f015 (I explain some motives there with chest-access).

  4. This one is a bit weird. Generally I'd prefer it if "more specific" overrides "more general" but at the same time, it's a hard rule that deny overrides allow. This dichotomy also manifests in the use/interact flags. Additionally, if nothing breaks, admins won't revise their flags, meaning this isn't just some temporary backstop but will define the behavior until WG gets a major rewrite (lol). Not really sure how to handle this best in the end. This is the kind of thing I'd rather have feedback on from people who actually use these flags.

@@ -414,7 +415,15 @@ public void onUseEntity(UseEntityEvent event) {
}
/* Ridden on use */
} else if (Entities.isRiddenOnUse(entity)) {
canUse = query.testBuild(BukkitAdapter.adapt(target), associable, combine(event, Flags.RIDE, Flags.INTERACT));
StateFlag flagToCheck;
if (entity instanceof Tameable){
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pigs can be ridden but aren't tameable, what happens here? maybe check the Animal interface?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch - I admit I was only thinking of horses while working on this. I'll check the Animal interface instead.

Player player = (Player) exited;
LocalPlayer localPlayer = WorldGuardPlugin.inst().wrapPlayer(player);
StateFlag flagToCheck;
if (vehicle instanceof Tameable){
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as above

@ryantheleach
Copy link

I was interested in seeing dismount and mount flags separated.

My usecase is minecart departure / arrival zones being separate, and attempting to dissuade people from riding the system backwards just to screw over the system / redstone.

Once someone hops in the minecart, they are trapped behind a glass barrier currently, and getting out will cause them to get trapped, and probably flood the subway with empty carts.

The glass barrier is there to stop them from being able to push the cart down the subway, without spamming excess carts (costing them iron).

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