Skript: is op is not working correctly

[GrimEpp]

The condition is op is not working correctly.
When i do /checkop wich code is
command /checkop: trigger: loop all players: loop-player is op broadcast "%loop-player% is op" just returns the name of the person even tho there is other people on that are op

[GrimEpp]

Tested with 1.12.2 dev 32c

[TheBentoBox]

Can anyone reproduce this?

[28andrew]

I remember @TonyMaster21 having the same issue. I just reproduced it on 1.12.2.

[bensku]

What permission plugin, if any, do you use?

[GrimEpp]

None
Just vanilla minecraft

[jaylawl]

is op condition doesn't work for me either using paper spigot 1.12.1, skript dev32d and luck permissions as perm plugin. permission conditions working fine however

[Nicofisi]

Is it still relevant? I'm not able to reproduce it with head on 462601b on latest Spigot version git-Spigot-4bd94dc-fb414fe (MC: 1.12.2) (Implementing API version 1.12.2-R0.1-SNAPSHOT):

>op Nicofisi
[13:56:49 INFO]: Opped Nicofisi
[13:56:57 INFO]: Nicofisi issued server command: /broadcastop
[13:56:57 INFO]: Nicofisi [6cf7857f-2d7d-3cbd-8c22-511f4f93c8d1]: /broadcastop
[13:56:57 INFO]: Starting
[13:56:57 INFO]: Nicofisi is op
[13:56:57 INFO]: Done
[13:57:04 INFO]: Nicofisi issued server command: /deop Nicofisi
[13:57:04 INFO]: [Nicofisi: De-opped Nicofisi]
[13:57:08 INFO]: Nicofisi issued server command: /broadcastop
[13:57:08 INFO]: Nicofisi [6cf7857f-2d7d-3cbd-8c22-511f4f93c8d1]: /broadcastop
[13:57:08 INFO]: Starting
[13:57:08 INFO]: Done
[13:57:25 INFO]: Nicofisi issued server command: /broadcastisop
[13:57:25 INFO]: Nicofisi [6cf7857f-2d7d-3cbd-8c22-511f4f93c8d1]: /broadcastisop
[13:57:25 INFO]: not op

command /broadcastisop:
        trigger:
                if player is op:
                        broadcast "%player% is op"
                else:
                        broadcast "not op"

command /broadcastop:
        trigger:
                broadcast "Starting"
                loop all players:
                        loop-player is op
                        broadcast "%loop-player% is op"
                broadcast "Done"

Any special steps to reproduce?

[28andrew]

On Wed, Feb 21, 2018 at 7:11 AM Nicofisi [e-mail] wrote:

Is it still relevant? I'm not able to reproduce it with head on 462601b
https://github.com/bensku/Skript/commit/462601b48427a872968ec6e9604e87b6feb133d9
on latest Spigot version git-Spigot-4bd94dc-fb414fe (MC: 1.12.2)
(Implementing API version 1.12.2-R0.1-SNAPSHOT):

op Nicofisi
[13:56:49 INFO]: Opped Nicofisi
[13:56:57 INFO]: Nicofisi issued server command: /broadcastop
[13:56:57 INFO]: Nicofisi [6cf7857f-2d7d-3cbd-8c22-511f4f93c8d1]: /broadcastop
[13:56:57 INFO]: Starting
[13:56:57 INFO]: Nicofisi is op
[13:56:57 INFO]: Done
[13:57:04 INFO]: Nicofisi issued server command: /deop Nicofisi
[13:57:04 INFO]: [Nicofisi: De-opped Nicofisi]
[13:57:08 INFO]: Nicofisi issued server command: /broadcastop
[13:57:08 INFO]: Nicofisi [6cf7857f-2d7d-3cbd-8c22-511f4f93c8d1]: /broadcastop
[13:57:08 INFO]: Starting
[13:57:08 INFO]: Done
[13:57:25 INFO]: Nicofisi issued server command: /broadcastisop
[13:57:25 INFO]: Nicofisi [6cf7857f-2d7d-3cbd-8c22-511f4f93c8d1]: /broadcastisop
[13:57:25 INFO]: not op

command /broadcastisop:
trigger:
if player is op:
broadcast "%player% is op"
else:
broadcast "not op"

command /broadcastop:
trigger:
broadcast "Starting"
loop all players:
loop-player is op
broadcast "%loop-player% is op"
broadcast "Done"

Any special steps to reproduce?

—

Try multiple players, also try both online and offline mode.

>

You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bensku/Skript/issues/1037#issuecomment-367321189, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJNoAoKqgks86W23QjiIQAiLUeTlIIQgks5tXBYYgaJpZM4RPrIS
.

[TheLimeGlass]

I think this is user error. When a Spigot server is in offlinemode and it is of a Bungeecord network they should have the bungeecord option enabled and have ip_forward enabled in the Bungeecord configurations. This allows Bungeecord to accurately setup UUID's based off Mojang. If it's not setup correctly Spigot thinks it's a cracked server and thus Spigot will generate all the UUID's. UUID's are related to the Operator data which is why I feel this condition would be failing. A suggestion to fix this could be using offlineplayers within the syntax or just ignore it since Bukkit's isOp() method would be invalid regardless when it's offline.

[GrimEpp]

This error was produced on online mode

[28andrew]

Also even if offline-mode did change the UUIDs to the non-correct ones (due to improper setup), it would still map 1 to 1 with players properly as long as they didn't change their name.

[bensku]

I'm puzzled. While it is certainly a real issue, if I can't reproduce it, I can't fix it. Went through all relevant code, and everything looks normal and I'm not encountering the issue.

[Snow-Pyon]

I've tested this and the only way I could reproduce it is with more than one player online in a loop.

[kahverengi001]

I looked codes to 5 minute & debugged somewhere stuff. I found what problem is it.

The problem is; is op doesn't check loop-player, just checks onPlayerCommand event's player. I'm not totally know this project codes (i mean idk for now, how to fix this) but i'm totally sure this is problem. Maybe this can help, if i found fix, i will send it as PR.

[kahverengi001]

Oh i understand something too Njol's brain is like crazy, cuz of it uses compare instance to get is op or not, not checking just player.isOp(). He controls player instance comparing... :/

Also the Spigot's Player#isOp is working great. Not buggy.

The is op need to be redesigned. (Like a real condition class)

(One more thing, i say this method PlayerData#match :
@Override protected boolean match(final Player p) { return op == 0 || p.isOp() == (op == 1); }

[SiebeDW]

I think this should be closed. (referred to a merged PR and commits.)

[Nicofisi]

Good point @SiebeDW, thanks!

Edit: well not really, as @Blueyescat noticed on Discord, the PR was not merged at all, since @Snow-Pyon considered it only a workaround to the larger issue. Sorry for not double-checking 👌

[ShaneBeee]

Fiddling around with this a little more, I came to a realization. The is op is being used incorrectly. The users here are using it as if it were a condition, where rather its comparing the player to operator entity class, therefor it should be used like "is an op"

when testing, if I use a simple command:

command /test:
    trigger:
        loop all players:
            send "Player: %loop-player% - UUID: %uuid of loop-player%"
                if loop-player is op:
                    send "&aOP"
                else:
                    send "&cNOT OP"

If I run in game, it says I'm op, if I run from console, it says I'm not op.
If I change the line if loop-player is op to if loop-player is an op it works in both console and in game.

saying if player is op is the equivalent of saying if entity is skeleton where we should be doing if entity is a skeleton

The same thing happens with this case:

command /test:
    trigger:
        loop all entities:
            if loop-entity is villager:
                send "&aVILLAGER"

(run from console) using is villager returns no villagers, if I use is a villager it returns 2 villagers

That said, I'm not sure if I could classify this as a bug. I would say maybe we should add an if %player% is op condition, which would check if the player has operator status vs checking if the player is an op entity.