old-mate-jim
- old-mate-jim
- JIRAUSER763273
- Europe/Stockholm
- Yes
- No
1 issues
Key
Summary
Status
Reporter
Assignee
Created
BDS-18725
Added Attachments:
Example_Script_Addon.mcaddon
Removed Attachments:
Changed Description:
Version is 1.20.30 - Not available to select
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.
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.
Added Affects Versions: 1.20.30
Removed Affects Versions: 1.20.15 Hotfix
Added Attachments:
Had the same problem.
The minecarts need to be within ticking distance to move. A workaround is adding the rail system as a ticking area using the tickingarea command:
Commands/tickingarea – Minecraft Wiki (fandom.com)
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
Any progress?
I haven't tested on any other platforms so I don't know. Doesn't seem like something that would be platform specific.
Ok. Can you stop marking it as resolved then? It's not resolved.
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:
Here is the code that checks the operator status using the Minecraft Script API specifically, this part: minecraft/server.Player Class
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
Any progress on this?
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.
This is still a valid issue because you can't add behavior packs to bedrock dedicated server without loading the world in Minecraft Bedrock Edition and applying the pack there. Then have to export again back to the server.
This is extremely clunky and I highly doubt it's how it was intended to work considering that the official documentation doesn't say this.
It should only be a matter of adding the behavior pack to the behaviour_packs directory and updating the world_behaviour_packs.json. However this does not work. The behaviour pack won't be applied to a world that is generated by the BDS even if everything was done correctly per the documentation.
If this is in fact how it was intended, then your documentation needs to be updated accordingly.