Can confirm for 21w14a
If at y=95, it will think you are standing out in the light. If at y=94, it will think you are in the shade.
Setting a block above y=80 will cause the lighting to update. If you set a block below y=80 it will not update.
[media]Confirmed 21w14a
Boats seem to be sending a constant 80 packets to the server when moving at full speed. This seems ridiculously high when compared to other things.
EDIT: After taking this screenshot, it seems that even while NOT MOVING in a boat, it is still sending a constant 80 packets.
EDIT 2: Horses are a constant 60 packets.
EDIT 3: Minecart is a constant 40 packets.
EDIT 4: Elytra is 35 packets IF flying at max speed. Max speed of Spectator Mode is 20 packets.
[media]Can confirm in 1.16.4
I set Campfire Smoke to a speed of 200 on accident inside a command block on a datapack development server. It crashed everyone's client except for 1 player who had extreme lag. The server logs kept getting confused as to what particle was being emitted by the command block, which I thought was pretty strange.
[Thu, 18. Feb 2021 20:10:53 EST INFO] [@: Displaying particle minecraft:soul_fire_flame]
[Thu, 18. Feb 2021 20:10:53 EST INFO] [@: Displaying particle minecraft:elder_guardian]
...
[Thu, 18. Feb 2021 20:11:06 EST INFO] [@: Displaying particle minecraft:elder_guardian]
[Thu, 18. Feb 2021 20:11:06 EST INFO] [@: Displaying particle minecraft:angry_villager]
...
[Thu, 18. Feb 2021 20:11:33 EST INFO] [@: Displaying particle minecraft:angry_villager]
[Thu, 18. Feb 2021 20:11:33 EST INFO] [@: Displaying particle minecraft:dripping_lava]
These are a few examples of where the console thought that a different particle was running in the command block, when it was campfire smoke. It would change what particle it thought was being emitted every half minute or so.
NOTE: I experienced this on February 18th but was using Spigot, so did not report it here.
Still affects version 1.16.1
Upon trying this on another 1.16.1 server, it seems to work properly. Unsure of what happened to get it to not work.
huh i think it is patched
try to export the file and open it on a vm
weird
I am an idiot!!!
So I figured out that using tags confuses the bossbar and won't display for more than 1 player with the tag.
That said, you need to use:
@a[scores={BreakStone=1..128}]
to make it work for everyone instead of a tag.
Sorry for posting a non-issue! >.<
tag @a[scores={BreakStone=1..}] add fatigue
bossbar set gameplay:hard_stone players @a[tag=fatigue]
execute at @p[tag=fatigue] run bossbar set gameplay:hard_stone visible true
execute at @p[tag=!fatigue] run bossbar set gameplay:hard_stone visible false
execute store result bossbar gameplay:hard_stone value run scoreboard players get @p BreakStone
As a matter of fact, if you want something easier to test that works as intended and is still relevant, use this instead.
However, what STILL won't work is the fact that it won't work for multiple people on a server. Only 1 person. Does not matter what selector you use.
BreakStone scoreboard is set if Stone is mined, you gain 1 point.
If you can get it to work properly, there is not a bug and I am an idiot. You don't even have to tell me the solution, just tell me to figure it out. But chances are it's a bug.
The bossbar is still relatively new. I am playing with it in ways many people haven't in a server environment.
I just posted my commands so that you have something to replicate and validate. The commands work just fine.
I am not asking for command help. I am starting to think this is a bug since it won't display for more than 1 player regardless of any target selector I use. Commands can't have bugs?
Here is the isolated line from the function that seems to be the target of the issue:
bossbar set gameplay:hard_stone players @a[tag=fatigue]
My mistake. It was sendCommandFeedback that won't show players the private messages they send outbound. I used to be able to disable commands that ops ran from being shown in chat in 1.12.2. It would still show commands to the one executing them like listing the number of players on a team or private messages. But it would not show players if admins teleported or changed gamemode.
No crash happened.
I would have reported this alot sooner if I had known beforehand. I didn't have players in my server until 1.13 release though.
I found out what was wrong. The syntax changes for Dimension aren't well documented.
tag @p[nbt={Dimension:-1}] add inNether
tag @p[nbt={Dimension:0}] remove inNether
These were the commands I was trying to use. These work the way I intended them to.
I am having this issue in 1.12.2 as well.
I created a system for players to build Warp Relay structures in the world that uses execute/detect commands and assigns a unique ID score to a pair of armor stands to create a tp link between them. When one of them unloads from the chunk, it vanishes along with it's scoreboard value, thus breaking the Warp Relay link.
I created this system back in Vanilla 1.10 and have been scrambling to find a fix for it. Including trying to find ways to glitch a chunk load and even resorting to trying to find chunk loading plugins on Spigot... which is not helpful either, since I cannot find any that can target select entities.
A fix would be a huge relief!
May I suggest possibly adding a feature that could allow keeping an entity loaded (or at least it's data loaded) within an unloaded chunk?
I think that if you encode it as ANSI first, if you do not convert it to UTF-8 but save it as UTF-8 it still won't work proper. Converting made all the difference.
This isn't even the Nazi swastika, which has a very specific chirality (right facing). The left facing swastika is used in Buddhism.