Zizzy zizzy
- ZizzyZizzy
- zizzyzizzy
- Europe/Stockholm
- Yes
- No
MC-158515
Normal
MCPE-75570
BDS-6825
/execute fails for tag command withradius (r=x.x) is used/execute fails for tag command when radius (r=x.x) is used
This can be tested by placing a chest, then placing something inside that chest.
Now place another empty chest above the first.
Use the clone command to clone the first chest over the second chest.
"No blocks cloned"
Open second chest and notice the items that were in the first chest are also in the second chest.
No doubt the reason it says failed is because the blocks are identical and the block itself was not actually replaced, even though the "contents" of the block were replaced.
However, I've seen this behavior in the wild when cloning different blocks over each other (hard to reproduce), which breaks the rest of the conditional command block chain. I've resorted to ensuring the
signupdate is the LAST operation in the chain because of this unreliability.This does the same thing for signs, which makes it difficult to update signs for mini-games because the conditional command block chain halts at the clone operation, even though the sign is updated correctly with the cloned source contents.
IMHO the result should always be a success unless the clone operation is blocked by some other factor, such as placing blocks outside the valid world boundaries. (I'm sure others that have used this behavior on purpose would disagree with me.)
This can be tested by placing a chest, then placing something inside that chest.
Now place another empty chest above the first.
Use the clone command to clone the first chest over the second chest.
"No blocks cloned"
Open second chest and notice the items that were in the first chest are also in the second chest.
No doubt the reason it says failed is because the blocks are identical and the block itself was not actually replaced, even though the "contents" of the block were replaced.
However, I've seen this behavior in the wild when cloning different blocks over each other (hard to reproduce), which breaks the rest of the conditional command block chain. I've resorted to ensuring the clone update is the LAST operation in the chain because of this unreliability, or spitting out a redstone pulse to a repeater, then to redstone and finally to impulse+redstone command blocks. Ugh.
This does the same thing for signs, which makes it difficult to update signs for mini-games because the conditional command block chain halts at the clone operation, even though the sign is updated correctly with the cloned source contents.
IMHO the result should always be a success unless the clone operation is blocked by some other factor, such as placing blocks outside the valid world boundaries. (I'm sure others that have used this behavior on purpose would disagree with me.)
This code works fine in Windows 10 single-player:
{ "format_version": "1.10.0", "animation_controllers": { "controller.animation.appletest": { "initial_state": "default", "states": { "default": { "transitions": [ { "eating": "query.is_using_item && query.get_equipped_item_name('main_hand') == 'apple' && query.item_in_use_duration >= 640" } ] }, "eating": { "on_entry": [ "/say i've eaten an apple!" ], "transitions": [ { "default": "!query.is_using_item || query.item_in_use_duration < 640 || query.get_equipped_item_name('main_hand') != 'apple'" } ] } } } } }
The code is completely broken in BDS 1.16.20.03. Any custom items that require the get_equipped_item_name query
are now completely broken in BDS.
I also tried the most basic test in a custom animation controller:
{ "format_version": "1.10.0", "animation_controllers": { "controller.animation.appletest": { "initial_state": "default", "states": { "default": { "transitions": [ { "eating": "query.is_using_item && query.get_equipped_item_name('main_hand') == 'apple'" } ] }, "eating": { "on_entry": [ "/say i've eaten an apple!" ], "transitions": [ { "default": "!query.is_using_item" } ] } } } } }This doesn't work either. query.is_using_item is working only by itself. As soon as I add query.get_equipped_item_name, it
never works becauseit always returns anempty string.This code works fine in Windows 10 single-player:
{ "format_version": "1.10.0", "animation_controllers": { "controller.animation.appletest": { "initial_state": "default", "states": { "default": { "transitions": [ { "eating": "query.is_using_item && query.get_equipped_item_name('main_hand') == 'apple' && query.item_in_use_duration >= 640" } ] }, "eating": { "on_entry": [ "/say i've eaten an apple!" ], "transitions": [ { "default": "!query.is_using_item || query.item_in_use_duration < 640 || query.get_equipped_item_name('main_hand') != 'apple'" } ] } } } } }
The exact same code is completely broken in BDS 1.16.20.03. Any custom items that require the get_equipped_item_name query no longer work due to it always returning a blank string.
I also tried the most basic test in a custom animation controller:
{ "format_version": "1.10.0", "animation_controllers": { "controller.animation.appletest": { "initial_state": "default", "states": { "default": { "transitions": [ { "eating": "query.is_using_item && query.get_equipped_item_name('main_hand') == 'apple'" } ] }, "eating": { "on_entry": [ "/say i've eaten an apple!" ], "transitions": [ { "default": "!query.is_using_item" } ] } } } } }This doesn't work either. query.is_using_item is working only by itself. As soon as I add query.get_equipped_item_name, it breaks because of the empty string.
SimpleGun.mcaddon
1.16.100.04 has broken projectile spawning (visibly only.) I'm unable to select 1.16.100.04 from the "Affects Version/s" drop-down, as it does not exist in the drop-down yet.
When spawning an entity, it visibly hovers at the initial spawn point instead of becoming an actual projectile. The projectile itself is actually invisible and does indeed travel the path it's supposed to.
This happens in single player and on BDS. The code to spawn the projectile remains unchanged in over 6 months, and was working perfectly until today:
"minecraft:projectile": { "on_hit": { "remove_on_hit": { }, "particle_on_hit": { "particle_type": "smoke", "num_particles": 6, "on_entity_hit": true, "on_other_hit": true }, "impact_damage": { "damage": [ 1, 4 ], "knockback": false, "semi_random_diff_damage": false, "destroy_on_hit": true } }, "destroy_on_hurt": true, "crit_particle_on_hurt": true, "power": 2.0, "gravity": 0.001, "uncertainty_base": 0, "uncertainty_multiplier": 0, "should_bounce": false, "offset": [ 0, 0, 0 ], "reflectOnHurt": false, "catch_fire": true, "on_fire_time": 0.50, "knockback": false },
1.16.100.04 has broken projectile spawning (visibly only.)
When spawning an entity, it visibly hovers at the initial spawn point instead of becoming an actual projectile. The projectile itself is actually invisible and does indeed travel the path it's supposed to.
This happens in single player and on BDS. The code to spawn the projectile remains unchanged in over 6 months, and was working perfectly until today:
"minecraft:projectile": { "on_hit": { "remove_on_hit": { }, "particle_on_hit": { "particle_type": "smoke", "num_particles": 6, "on_entity_hit": true, "on_other_hit": true }, "impact_damage": { "damage": [ 1, 4 ], "knockback": false, "semi_random_diff_damage": false, "destroy_on_hit": true } }, "destroy_on_hurt": true, "crit_particle_on_hurt": true, "power": 2.0, "gravity": 0.001, "uncertainty_base": 0, "uncertainty_multiplier": 0, "should_bounce": false, "offset": [ 0, 0, 0 ], "reflectOnHurt": false, "catch_fire": true, "on_fire_time": 0.50, "knockback": false },
Furthermore, /gamerule commandBlockOutput false does NOT suppress the errors in the console.
No data packs.
In the end it took an x-ray mod to locate the rogue command blocks in the spawn area, which were placed by someone with op permissions. The command blocks were removed and the spamming stopped.
#Minecraft server properties
#Tue Aug 06 13:19:48 MDT 2019
allow-flight=false
allow-nether=true
broadcast-console-to-ops=true
broadcast-rcon-to-ops=true
debug=false
difficulty=peaceful
enable-command-block=false
enable-query=true
enable-rcon=false
enforce-whitelist=false
force-gamemode=true
function-permission-level=2
gamemode=survival
generate-structures=true
generator-settings=
hardcore=false
level-name=xxxxx
level-seed=
level-type=default
max-build-height=256
max-players=48
max-tick-time=60000
max-world-size=10000
motd=Mellominecraft
network-compression-threshold=256
online-mode=true
op-permission-level=4
player-idle-timeout=0
prevent-proxy-connections=false
pvp=false
query.port=25565
rcon.password=
rcon.port=25575
resource-pack-sha1=
resource-pack=
server-ip=xx.xx.xx.xx
server-name=xxxxx
server-port=25565
snooper-enabled=true
spawn-animals=true
spawn-monsters=true
spawn-npcs=true
spawn-protection=300
use-native-transport=true
view-distance=7
white-list=false
I've attached the spawn region file. Start it up on Minecraft 1.14.4 release with "enable-command-block=false" in server.properties and you'll immediately see the error in the console. Also notice that attempting to turn off command block output with the gamerule does nothing.
This bug also makes it impossible to run a second instance of Bedrock on the same host server. No matter what port is defined in server.properties, it always says the requested port is in use when it is not.
@Paul Thanks for that!
Even with ipV6 disabled, if you specify just a random ipV6 port that happens to be in use by anything, the server says "IPv6 supported", then "Network port occupied". Same if you leave it undefined, same if you remove it from server.properties completely.
Even more head-scratching: if you set the port to something completely invalid, it starts up fine. I certainly appreciate that this is unsupported and basically a "gift" from Microsoft to have it available at all, but seriously - who writes this stuff?
"Failed successfully!"
Update - the 99999 port hack stopped working randomly.
Now I have to script it so a random, unused lower port is assigned to the server-portv6 line:
That works fine now. Just make sure to remove the kernel ipv6.disable=1 line if it's active, and then reboot. I found out on a different Ubuntu server that with that kernel option enabled, there is no work-around to this frustrating issue.
The screenshot shows your version is actually "beta 1.16.0.53", running on an SM-T515 Samsung device.
The client version must match the server version or you won't be able to connect. Please close this and don't waste the developers time any further.
The same thing happens with /fill and replace:
/fill 38 218 12 38 218 12 trapped_chest 3 replace
That actually DOES replace the chest, emptying the contents (desired behavior here), but the output says "0 blocks filled", causing chained conditional command blocks to do nothing.
Very annoying and counter-intuitive to have to resort to using tags instead.
Duplicate of
MCPE-61318Can confirm this is still broken. BDS should not be changing the names of players in a scoreboard to "Player Offline".
It looks ridiculous in-game when the top 10 scoreboard leaders are all "Player Offline". If the player's Gamer Tag has changed, so what? BDS should be tracking the UUID anyway. Leave the previously stored gamer tag in the scoreboard list as it was please.
I forgot to mention that even after removing the unicode 200b chars, it is still broken. I'm not certain which character(s) BDS is puking on:
It was the semicolon!? That's the last character I would have guessed. Nice find!
This is now fixed in the 1.16.20.03 hotfix.
Thank you!
The celebration was premature.
Now:
lock_rider_rotation
rotate_rider_by
Are completely borked. Any value used causes the rider to turn left and then right by themselves (with no keyboard/mouse interaction) to the lock degree set repeatedly, and then will eventually start spinning in circles.
This has been fixed in 1.16.100.
However, this is beginning to get comical. Now any entity spawned from anything that shoots no longer moves. It just spawns and hovers with no velocity, both in single player and on BDS. I'll open yet another new bug report.
Two things:
In single player, there is a behavior_packs and resource_packs folder under each world folder.
In BDS, the folders are at the root of your server, NOT in the world folder(s). You must move the packs to their correct BDS locations or BDS will not even see them. It only scans /behavior_packs/ and /resource_packs/ for installed add-on packs.
This has been fixed as of today (1.16.100.04). However, now spawned projectiles no longer visibly function. They just hover while an invisible spawned projectile actually moves and strikes where you're looking.
I've stripped out just a single laser gun from an add-on pack (not mine) that was working before the 1.16.100.04 update.
Give yourself the gun and then right-click (use/eat) to fire.
Alternatively,
and then just jump to fire the gun.
This has been fixed in 1.16.200. Thank you!
This is still broken on Ubuntu 18 with Bedrock Server v1.16.201.3.
If IPv6 is disabled completely via GRUB, Bedrock Server crashes during startup. There doesn't appear to be a way to tell it to only use IPv4, even when the entire server has already been configured to do so.
/etc/apt/apt.conf.d/99force-ipv4:
Acquire::ForceIPv4 "true";
/etc/sysctl.conf:
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.ipv6.bindv6only=1
/etc/default.grub:
GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1"
GRUB_CMDLINE_LINUX="ipv6.disable=1"
IPv6 causes nothing but problems on every server I've ever encountered, which is why we always disable it completely. If something odd is going on with networking/DNS/etc., disabling IPv6 and rebooting usually does the trick.