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 player visibility stuff #1302

Merged
merged 14 commits into from
Jul 17, 2018
Merged

Add player visibility stuff #1302

merged 14 commits into from
Jul 17, 2018

Conversation

Blueyescat
Copy link
Contributor

@Blueyescat Blueyescat commented Jun 10, 2018

Target Minecraft versions: Any
Requirements: No
Related issues: #1291

Description:
Adds effects to hide/reveal players for players, condition to check if a player can see another player and expression to get hidden players of a player.

Also updated Skript's PaperSpigot to 1.12.2 from 1.12.1 because i used the new hide/showPlayer(Plugin, Player) method that comes with 1.12.2 if it exists.

Thanks to @Snow-Pyon for some help on the code.

hide %players% (from|for) %players%
reveal %players% (to|for|from) %players%
#no show effect because conflicts with open inv effect

[(all [[of] the]|the)] hidden players (of|for|from) %players%
[(all [[of] the]|the)] players hidden (from|for|by) %players%

%players% (is|are) [(1¦in)]visible for %players%
%players% can see %players%
%players% (is|are)(n't| not) [(1¦in)]visible for %players%
%players% can('t| not) see %players%

Copy link

@Snow-Pyon Snow-Pyon left a comment

Choose a reason for hiding this comment

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

Looks good overall.

static {
Skript.registerCondition(CondCanSee.class,
"%players% (is|are) [(1¦in)]visible [for %players%]",
"[%players%] can see %players%",

Choose a reason for hiding this comment

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

I don't think the following:

if can see player:

makes sense, just make it mandatory.

Choose a reason for hiding this comment

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

And you can use a single parser mark here

import org.bukkit.Bukkit;

@Name("Can See")
@Description("Checks whether or not a player can see another player.")

Choose a reason for hiding this comment

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

or not is redundant. And I'd rather use the given players.


@Override
public boolean init(Expression<?>[] exprs, int matchedPattern, Kleenean isDelayed, SkriptParser.ParseResult parseResult) {
setNegated(((matchedPattern == 2 || matchedPattern == 3) && parseResult.mark != 2) || parseResult.mark == 1);

Choose a reason for hiding this comment

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

just check if matchedPattern > 1 ^ parseResult.mark == 1 to negate it.

public boolean init(Expression<?>[] exprs, int matchedPattern, Kleenean isDelayed, SkriptParser.ParseResult parseResult) {
reveal = matchedPattern > 0;
players = (Expression<Player>) exprs[0];
if (reveal && players instanceof ExprHiddenPlayers) {

Choose a reason for hiding this comment

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

Skript's code style doesn't use braces on this kind of cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Which line?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think you mean conditions, ok..

import org.bukkit.event.Event;

@Name("Player Visibility")
@Description({"Change visibility of a player for the given players. If a player was hidden and relogs, it will be visible again.",

Choose a reason for hiding this comment

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

You said the same twice here.

@Blueyescat
Copy link
Contributor Author

Blueyescat commented Jun 10, 2018

Wat, blame GitHub Desktop for the latest commit :O But at least it didn't break anything..

reveal = matchedPattern > 0;
players = (Expression<Player>) exprs[0];
if (reveal && players instanceof ExprHiddenPlayers)
targetPlayers = (exprs.length > 1 && !exprs[1].isDefault()) ? (Expression<Player>) exprs[1] : ((ExprHiddenPlayers) players).getPlayers();
Copy link
Member

Choose a reason for hiding this comment

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

what is the deal with this exprhiddenplayers thing?

Choose a reason for hiding this comment

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

He wanted the following:

reveal hidden players for {_player}

to work this way:

reveal hidden players for {_player} to {_player}

And it makes sense imo.

Copy link
Member

Choose a reason for hiding this comment

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

@Blueyescat should comment it a bit then, the code is confusing

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Already noted in the effect description.

Copy link
Member

Choose a reason for hiding this comment

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

no reason it can't be in both places


static {
Skript.registerEffect(EffPlayerVisibility.class,
"hide %players% [(from|for) %players%]",
Copy link
Member

Choose a reason for hiding this comment

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

I really don't think event value assumption works well in these syntaxes, take this code:

on click:
  hide player

you would think that hides the player from everyone but in reality it hides the player from themselves which isn't a thing

Copy link
Contributor Author

@Blueyescat Blueyescat Jun 11, 2018

Choose a reason for hiding this comment

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

Actually i can check if the expression is not the event player, but still confusing. I will remove defaulting to event player and i will make it defaulting to all players (this only valid for the effect).


static {
Skript.registerCondition(CondCanSee.class,
"%players% (is|are) [(1¦in)]visible [for %players%]",
Copy link
Member

Choose a reason for hiding this comment

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

these syntaxes have the same issue with event value assumption


static {
Skript.registerCondition(CondCanSee.class,
"%players% (is|are) [(1¦in)]visible [for %players%]",
Copy link
Member

Choose a reason for hiding this comment

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

why not make the visible/invisible separate syntaxes? like you said it's better for documentation

reveal = matchedPattern > 0;
players = (Expression<Player>) exprs[0];
if (reveal && players instanceof ExprHiddenPlayers)
targetPlayers = (exprs.length > 1 && !exprs[1].isDefault()) ? (Expression<Player>) exprs[1] : ((ExprHiddenPlayers) players).getPlayers();
Copy link
Member

Choose a reason for hiding this comment

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

@Blueyescat should comment it a bit then, the code is confusing

Skript.registerExpression(ExprHiddenPlayers.class, Player.class, ExpressionType.PROPERTY,
"[(all [[of] the]|the)] hidden players [(of|for) %players%]",
"[(all [[of] the]|the)] players hidden [(from|for) %players%]",
"%players%'[s] [all] hidden players");
Copy link
Member

Choose a reason for hiding this comment

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

player's all hidden players isn't grammatically correct, and i think that even player's hidden players sounds awkward so maybe don't have this at all?

Copy link
Contributor Author

@Blueyescat Blueyescat Jun 11, 2018

Choose a reason for hiding this comment

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

Yeah probably. I will remove it and add "by" to the 2nd pattern:

[(all [[of] the]|the)] players hidden (from|for|by) %players%

}

@Override
public BlockState getState(boolean bool) {
Copy link
Member

Choose a reason for hiding this comment

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

how come you changed these methods? this won't work on normal spigot (the method you call does not exist there). Also, you should name the parameter useSnapshot instead of bool if this is kept

Copy link
Contributor Author

@Blueyescat Blueyescat Jun 11, 2018

Choose a reason for hiding this comment

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

Actually i were using Spigot 1.8.8 while testing this PR, i tried again and there is no any error in the console. hmm... Also i don't know how to prevent calling them if they doesn't exist.

You are right about the variable name.

Copy link
Member

Choose a reason for hiding this comment

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

maybe it was removed on newer versions? it isn't in the spigot javadocs, only papers

Copy link
Member

Choose a reason for hiding this comment

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

but that doesn't explain why this change is in this pr anyways

Copy link
Contributor Author

@Blueyescat Blueyescat Jun 11, 2018

Choose a reason for hiding this comment

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

Well they are added in PaperSpigot 1.12.2 but doesn't give error on Spigot 1.8.8 i don't know.

Oh yeah i forgot to explain that, because i used the new hide/showPlayer(Plugin, Player) method that comes with 1.12.2 if it exists 🤷‍♀️

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah they don't call a new method just creates.

@Nicofisi
Copy link
Member

Nicofisi commented Jun 16, 2018

Same here, you need to keep it 2017 for now

import ch.njol.skript.doc.Description;
import ch.njol.skript.doc.Examples;
import ch.njol.skript.doc.Name;
import ch.njol.skript.doc.Since;

Choose a reason for hiding this comment

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

import order

import org.eclipse.jdt.annotation.Nullable;
import ch.njol.skript.Skript;
import ch.njol.skript.doc.Description;
import ch.njol.skript.doc.Examples;

Choose a reason for hiding this comment

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

import order

import ch.njol.skript.doc.Since;
import ch.njol.skript.lang.util.SimpleExpression;
import ch.njol.skript.lang.SkriptParser;
import ch.njol.skript.lang.Expression;

Choose a reason for hiding this comment

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

and again, import order.

@Blueyescat
Copy link
Contributor Author

Blueyescat commented Jul 17, 2018

Ops i forgot to change the import orders, should be fine now.

@Nicofisi
Copy link
Member

Whoever merges it, please squash 🙏

@Blueyescat
Copy link
Contributor Author

no no easier to revert

@Snow-Pyon Snow-Pyon merged commit 60279c0 into SkriptLang:master Jul 17, 2018
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.

4 participants