Snap Doomy
- snaplingdd
- snaplingdd
- Europe/Stockholm
- Yes
- No
Normal
MC-251299MC-252374MC-260731MC-261017
Woodland Mansion spawns inside the ground destroying some blocks around it
Seed: 3729081246867277244
Cords: 7840 72 2058
I used the /locate command and teleported straight to this mansion, so that might've caused it? I'm not sure how it works anyway.
Woodland Mansion spawns inside the ground destroying some blocks around it
Seed: 3729081246867277244
Cords: 7840 72 2058
I used the /locate command and teleported straight to this mansion, so that might've caused it? I'm not sure how it works anyway.
If you summon an Area Effect Cloud, it waits 6 ticks before applying your effect even if WaitTime is 0.
Example command:
{Id:8b,Amplifier:12b,Duration:80,ShowParticles:0b}
~{{/summon area_effect_cloud ~ ~ ~ {Radius:4f,Duration:1,WaitTime:0,Effects:[]}}}~
But if you change your Duration to 6:
~{{/summon area_effect_cloud ~ ~ ~ {Radius:4f,Duration:1,WaitTime:0,Effects:[
{Id:8b,Amplifier:12b,Duration:80,ShowParticles:0b}]}}}~
Then it works just fine.
If you summon an Area Effect Cloud, it waits 6 ticks before applying your effect even if WaitTime is 0.
Example command:
summon area_effect_cloud ~ ~ ~ {Radius:4f,Duration:1,WaitTime:0,Effects:[
{Id:8b,Amplifier:12b,Duration:80,ShowParticles:0b}]}}}~
But if you change your Duration to 6:
~{{/summon area_effect_cloud ~ ~ ~ {Radius:4f,Duration:1,WaitTime:0,Effects:[
{Id:8b,Amplifier:12b,Duration:80,ShowParticles:0b}]}}}~
Then it works just fine.
If you summon an Area Effect Cloud, it waits 6 ticks before applying your effect even if WaitTime is 0.
Example command:
summon area_effect_cloud ~ ~ ~ {Radius:4f,Duration:1,WaitTime:0,Effects:[
{Id:8b,Amplifier:12b,Duration:80,ShowParticles:0b}]}}}~
But if you change your Duration to 6:
{Id:8b,Amplifier:12b,Duration:80,ShowParticles:0b}
~{{/summon area_effect_cloud ~ ~ ~ {Radius:4f,Duration:1,WaitTime:0,Effects:[]}}}~
Then it works just fine.
If you summon an Area Effect Cloud, it waits 6 ticks before applying your effect even if WaitTime is 0.
Example command:
/summon area_effect_cloud ~ ~ ~ {Radius:4f,Duration:1,WaitTime:0,Effects:[
{Id:8b,Amplifier:12b,Duration:80,ShowParticles:0b}
But if you change your Duration to 6:
/summon area_effect_cloud ~ ~ ~ {Radius:4f,Duration:1,WaitTime:0,Effects:[
{Id:8b,Amplifier:12b,Duration:80,ShowParticles:0b}
Then it works just fine.
The Bug:
The entity_hurt_player advancement trigger does not trigger when a Warden damages a player using its Sonic Boom attack.
Steps to Reproduce:
Add an entity_hurt_player advancement trigger, and have it reward a function. In the function, run any command. A say command works just to test that it works. Add it to your world, and have a Warden damage you using its SonicBoom attack.Observed Behavior:
The entity_hurt_player advancement trigger does not trigger when the Warden damages players using the Sonic Boom attack.
Expected Behavior:
The entity_hurt_player advancement trigger should trigger when the Warden damages a player using the Sonic Boom attack.
The Bug:
The entity_hurt_player advancement trigger does not trigger when a Warden damages a player using its Sonic Boom attack.
Steps to Reproduce:
1) Add the attached datapack to your world.
2) Go in survival mode (recommend to use resistance effect for this and clearing the darkness effect with a repeating command block)
3) Summon a warden
4) Have it attack you with a melee attack.
Watch as the say command in chat works perfectly fine, because melee attacks register correctly towards the entity_hurt_player trigger. The advancement is revoked after the say command, so the say command will work for every single melee attack.
5) Pillar up a few blocks so the warden can't reach you with a melee attack and is forced to attack you with a sonic boom.
Watch as the say command in chat does not work at all - because the entity_hurt_player trigger doesn't trigger from sonic boom anymore after 22w17a.
Observed Behavior:
The entity_hurt_player advancement trigger does not trigger when the Warden damages players using the Sonic Boom attack.
Expected Behavior:
The entity_hurt_player advancement trigger should trigger when the Warden damages a player using the Sonic Boom attack.
Wardensgo insane and lose agro temporarily if their movement speed attribute is changedWardens are forced to roar at their suspect again when you change their data
find_entity1.mcfunction
I made a custom enchantment for a datapack that would change the mob's movement speed attribute to 0 and store it back later depending on what it was, and while I was testing this on the warden I found some interesting results. While the warden does keep the anger in nbt under anger.suspects, it sometimes also switches to a different target in the array if the movement attribute is set to 0.
Observed Behavior:
The wardenloses interest or switches target, choosing from the anger.suspects arrayExpected Behavior:
The warden will keep anger at the player until it is free to move again.Demonstration:
EDIT: Read comment for reproduction steps
The issue:
Holding a weapon with knockback and using the /damage command and specifying the source player inflicts knockback, but not the knockback from your enchantment.
Reproduction Steps:
1) Summon an example entity: /summon creeper ~ ~ ~ {Tags:["test"]}
2) Give yourself a sword with high knockback to ensure this behavior: /give @s iron_sword{Enchantments:[
{id:"minecraft:knockback",lvl:10s}]}
3) Use the damage command on the creeper: /execute as @e[type=creeper,tag=test] run damage @s 1 generic by @p
4) Take note as the creeper takes small amount of
damage, as if it was attacked without an item enchanted by knockbackWhat is happening:
The creeper takes small knockback as if it was attacked with an item that does not have the knockback enchantment.
What should be happening:
The creeper would take the correct amount of knockback corresponding to that of the knockback enchantment level on the item the player is holding.
The issue:
Holding a weapon with knockback and using the /damage command and specifying the source player inflicts knockback, but not the knockback from your enchantment.
Reproduction Steps:
1) Summon an example entity: /summon creeper ~ ~ ~
{Tags:["test"]}2) Give yourself a sword with high knockback to ensure this behavior: /give @s iron_sword{Enchantments:[
{id:"minecraft:knockback",lvl:10s}]}
3) Use the damage command on the creeper: /execute as @e[type=creeper,tag=test] run damage @s 1 generic by @p
4) Take note as the creeper takes small amount of knockback, as if it was attacked without an item enchanted by knockback
What is happening:
The creeper takes small knockback as if it was attacked with an item that does not have the knockback enchantment.
What should be happening:
The creeper would take the correct amount of knockback corresponding to that of the knockback enchantment level on the item the player is holding.
Have you found Evokers in survival? (in raids, that is)
Because I went through multiple waves with a bad omen level of 10(which would require 10 patrol leaders to kill in survival to obtain, I think. I just used the /effect command.) and all I could find witches, pillagers, vindicators and beasts, but not a single Evoker.
I don't know if this is intentional, but this has been a thing since as far as I can remember (atleast since 1.3.2) and I'd like to have it kept. xD
it also works with glowstone!
Just tested it a few times more, and it does actually seem like an evoker will spawn in the last wave. guess you can close this, thanks!!
Affects 1.18
Affects 22w18a
It works perfectly fine for me on 22w15a & 22w16a but doesn't work on 22w17a and 22w18a. I haven't changed anything, I'm not sure why it's not working, melee attacks from the warden trigger it just fine but after 22w17a it just doesn't trigger from the sonic boom.
Alright, I put this concept into one datapack so it's easier and lighter.
I'm replying with quite a delay, but I know now what is the cause: It's actually using data modify on a warden while it has suspects of anger that causes this behavior to go crazy, not the fact that its attribute is changing. I know this because I messed around with some things and it is 100% the data modify command that causes this.
So proper title would be modifying the data of a warden causes it to lose agro temporarily and force a roar at the target again.
I will attach the datapack in to this report using attach files, and here are the repro steps:
How to reproduce:
1) Go in survival mode (I recommend giving yourself high resistance and have a repeating command block that clears darkness so this is easier)
2) Summon a warden
3) Attack the warden
4) Watch as it forces itself to roar again after being mad at you.
Added a datapack and will edit the bug now to add repro steps
In 22w19a
In 22w19a
Fixed in 22w19a
In 22w19a
In 1.19 pre release 1
In 1.19 pre release 2
thx for letting me know
In 1.19 pre release 2
this is unfortunately not fixed and still occurs in 23w06a
this also occurs in 23w07a
this sadly still happens in the latest 1.19 pre 4 release
oh, when I teleport to the far coordinates the armor stand does show up, but it seems like it only renders once the chunks are loaded, which I guess makes sense.
Seems like using this method but with a fire aspect weapon does not trigger the fire aspect either.
hey [~[Mojang] Moesh]
I added the steps and a pack as you asked, sorry this took a whole year to call back, but I figured this was still relevant since it is not fixed