Mojira Archive
BDS-18725

[Scripting] isOp() returns false when players are operator

Version is 1.20.30 - Not available to select   *   *It is now available so have updated this.

isOp() from the Player class is always returning false, even if the player is operator, except if setOp(true) is called first.

This defeats the purpose of having an isOp() method if you have to manually check player IDs just to see if they should have setOp() called. 

Environment

Ubuntu Server

Linked Issues

Attachments4

level.dat

old-mate-jim

Comments16

Thank you for your report!
However, this issue has been temporarily closed as Awaiting Response

Can you please describe your issue in more detail?

To make your bug report as effective as possible, please try and include the following steps to reproduce the problem:

Steps to Reproduce:
1.
2.
3.

Observed Results:
(Briefly describe what happens)

Expected Results:
(Briefly describe what should happen)

If your ticket does not look like the example given here, then it's likely to be closed as incomplete.

 Quick Links:
📓 Bug Tracker Guidelines – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 BDS Wiki – 📖 FAQs

Really? Marking it resolved without even looking into it. I'm not sure how much clearer I could have been.

 

Steps to Reproduce:

1. Make a Bedrock Dedicated Server

2. Use the Minecraft Script API

3. Call the function Player.isOp() in the context of a Player who is operator e.g. using the PlayerBreakBlockAfterEvent

4. Observe the result with console.log()

 

Observed Results:

The function always returns a value of false even when the player is operator 

 

Expected Results:

The function returns true when the player is operator 

Hi

Does it only occur on Linux?

This ticket will automatically reopen when you reply.

I haven't tested on any other platforms so I don't know. Doesn't seem like something that would be platform specific.

Hi

I need more detailed instructions how to reproduce this issue. If possible with video as well.

This issue will automatically reopen when you reply.

Ok. Can you stop marking it as resolved then? It's not resolved.

Hi

It is resolved as awaiting response. It automatically reopens when you reply. It is still tracked and open, but we need more detailed information how to reproduce this issue.

Firstly, I am aware of how JIRA works. I am a .NET Software Engineer and use the same platform. That's very poor workflow management if you're marking them as resolved instead of one more suitable. 

FYI this is a regression. It was working fine in 1.20.15 but not in 1.20.30.

Can you tell me what you have tried so far so I can make corrections that will allow you to reproduce the issue?

I have confirmed that the issue is present on Windows also.

 

Steps to Reproduce:

  1.  Download the [Minecraft Bedrock Server Download | Minecraft|https://www.minecraft.net/en-us/download/server/bedrock] for either Windows or Linux.
  2.  Run the server and wait until console is idle and world is running then stop it (this makes sure the world is created)
  3.  Stop the server
  4.  Extract the contents of attached Example_Behavior_Pack.zip to the directory:  ./behavior_packs/Example_Behavior_Pack
  5.  Place the world_behavior_packs.json and level.dat files in the ./worlds/Bedrock level/ directory
  6.  Open Minecraft for Windows
  7.  Join the Server
  8.  You will see in the console "Player is not op"
  9.  Run the command in the console to give yourself operator permission "op <player_name_here>"
  10.  Note the command output says "Opped <player_name_here>"
  11.  Leave the server.
  12.  Rejoin the server
  13.  You will see in the console "Player is not op"
  14.  Open the menu 
  15.  You will see you do have operator permission but the server is not recognizing it.

 

Here is the code that checks the operator status using the Minecraft Script API specifically, this part: minecraft/server.Player Class

 

 

import * as server from "@minecraft/server"
server.world.afterEvents.playerSpawn.subscribe(onAfterPlayerSpawn)
/** 
 *  
 * @param {server.PlayerSpawnAfterEvent} eventData
 */
function onAfterPlayerSpawn(eventData) {    
    console.log(`Player ${eventData.player.isOp() ? "is" : "is not"} op`)
}

 

Observed Results:

The player is not being recognized as having operator status even though they do.

Expected Results:

When the player with operator status spawns, the message should say "Player is op".

Additonal Info:

Link to Video: MinecraftScriptingBug

Video Also Attached

 

isOp() working fine in local world for me. But in realms, it's not.

I'm seeing exactly the same issue as described. My mod is designed such that it adds additional restrictions to players which aren't operators. This works as expected in a single player game (as I change my account type back and forth between Operator and Member) but in the bedrock server game it always returns false, for all players.

you have to set op-permission-level in server.properties

ADO 1116005 closed as duplicate.
ADO 1074369 still open

According to this https://minecraft.wiki/w/Server.properties the op-permission-level property is for Java Edition. This issue is for the Bedrock Server.

History19

Maciej Piornik
[Bot] Arisa
Maciej Piornik
[Bot] Arisa
Maciej Piornik
[Bot] Arisa
Maciej Piornik
[Bot] Arisa
old-mate-jim

Added attachment: Example_Script_Addon.mcaddon

old-mate-jim

Removed attachment: Example_Script_Addon.mcaddon

old-mate-jim

Added attachment:

old-mate-jim

Added attachment:

Added attachment:

old-mate-jim
old-mate-jim

Added affects versions: 1.20.30

Removed affects versions: 1.20.30

old-mate-jim

Changed description:

Version is 1.20.30 - Not available to select

0

isOp() from the Player class is always returning false, even if the player is operator, except if setOp(true) is called first.

0

This defeats the purpose of having an isOp() method if you have to manually check player IDs just to see if they should have setOp() called. 

Version is 1.20.30 - Not available to select   *   *It is now available so have updated this.

00

isOp() from the Player class is always returning false, even if the player is operator, except if setOp(true) is called first.

0

This defeats the purpose of having an isOp() method if you have to manually check player IDs just to see if they should have setOp() called. 

Maciej Piornik

Confirmation Status: UnconfirmedConfirmed

[Mod] Umija5895M
Unresolved
old-mate-jim
7
7
Confirmed
1116005, 1074369
1.20.30