Zizzy zizzy

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.

This has been fixed in 1.16.200. Thank you!

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.

/give @s mech:lasergun

Alternatively,

/tag @s add jumpfire

and then just jump to fire the gun.

Two things:

1. BDS structure is different from single player
   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.

2. As someone else already stated, the query.get_equipped_item_name was broken
   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.

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.

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 is now fixed in the 1.16.20.03 hotfix.

Thank you!

It was the semicolon!? That's the last character I would have guessed. Nice find!

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:

server-name=§k§c§kYEPAAAAH§r§c§l§o§r§l§o§a§l§o- §r§2§l§oHACHIKEROS ;3§r

Duplicate of MCPE-61318

Can 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.

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.

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.

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:

freeport=$(comm -23 <(seq 1025 19130 | sort) <(ss -Huan | awk '{print $4}' | cut -d':' -f2 | sort -u) | shuf | head -n 1)

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.

@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!"

[2020-03-26 23:03:56 INFO] IPv4 supported, port: 19134
[2020-03-26 23:03:56 INFO] IPv6 not supported
[2020-03-26 23:03:56 INFO] IPv4 supported, port: 35122
[2020-03-26 23:03:56 INFO] IPv6 not supported
[2020-03-26 23:03:57 INFO] Server started.
stop
Quit correctly

# grep port server.properties
server-port=19134
server-portv6=99999

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.

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.

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

Furthermore, /gamerule commandBlockOutput false does NOT suppress the errors in the console.