mojira.dev

ekul6547

Assigned

No issues.

Reported

MC-189670 Custom Worlds type 'multi_noise' only uses one biome in array Invalid MC-189661 Cannot open GUI with very high levitation effects Duplicate MC-189414 Smithing table doesn't calculate amount of output items correctly Fixed MC-182452 Pistons powered by redstone on slabs is incorrect Confirmed MC-169536 Cannot use entity UUID in /scoreboard command Duplicate MC-156968 Item entity Motion displays incorrectly Duplicate MC-153351 Loot mine command ignores pickaxe level. Duplicate MC-142192 Pistons can conduct redstone signal while retracting Fixed MC-12878 redstone look weird Invalid

Comments

Can confirm still happens in 1.16.4.

It is wrong by a factor of 10; so 200 Duration will display as 0:01, but gives the effect for 10 seconds (0:10).

Can confirm this is still a bug in 1.16.4 pre-release 2. It has the same behaviour with the /data modify command too

Do you mean the parameters in the "biomes":[] array, in the "biome_source"?
If so, I have changed those parameters to other things, and it still doesn't generate more than one biome.

However, I was mistaken when I stated "first biome in array". But after more testing, I have discovered it will generate 1 where the parameters are above 0, and 1 biome where the parameters are below zero. It seems to be the biomes "closest to zero" that are chosen.

I have uploaded two new datapacks to show this off. One will only spawn plains and deserts, and one will spawn jungles and frozen oceans. But for both of them, all four of those biomes are in the "biomes" array, and no parameters are the same.

I believe your problem could be the "Minecraft:" part, as capital letters often don't work for me when I make my datapacks. I would suggest trying with a lowercase M, so "minecraft:". This is because [a-z0-9_.-] doesn't have A-Z specified

I've investigated more into my report in MC-182452 and it turns out it depends on which side of 0,0 the pistons are on. I've made a little video showcasing this on the 4 different corners from 0,0: https://youtu.be/TE1hoDIewVo

I have edited to add a video showcasing the bug. This video shows the piston behaviour on each side of 0,0, in all 4 quarters of the world. Here: https://youtu.be/TE1hoDIewVo 

This is actually bad though, and not resolved. For example, if you constantly add 1 to the armor_stand's Head[0] rotation, you'll have to make sure to always offset it by a very small amount. This means constantly scaling up and down again using execute store.
The broken part about this is that you cannot set a single value of the Pose arrays without ensuring all values in the array are set first, the execute store no longer works if the data is deleted because all values are equal to 0.0f.
Try repeating these 2 commands (create dummy scoreboard called rotation, and set it to -10 first):

scoreboard players add @e[type=minecraft:armor_stand,sort=nearest,limit=1] rotation 1
execute as @e[type=minecraft:armor_stand,sort=nearest,limit=1] store result entity @s Pose.Head[0] float 0.1 run scoreboard players get @s rotation
This will work until rotation = 0, where it will stop because the entire Pose array is now deleted, because all values equal 0.0f.

no soz
thats a client side mod
been using it for a while and never seen this before
wondering why