knirch

can confirm, neither rmb or jab is affected

Are you referring to piglin_safe, respawn_anchor_works similar? They were renamed in 25w42a, not removed.

this also prevents spectating entities by clicking on them

Yes, still present. A beehive with bee, pig and cow where bee and pig are listed as beehive_inhabitors will spawn the bee, delete (but play spawn sound) the pig, and keep the cow locked up.

Yes. Still present in 1.21.6

as it’s not explicitly mentioned already; This is true for advancements with rewards.function which causes the locator bar to be very unreliable if you have datapacks that trigger on events.

@haykam … that’s embarrassing. Yes.

mod/helper; close as invalid please

MC-272566I suspect there are more, as reeling in a boat with a fishing rod has the same “if player controlling” then act like a stone type of behavior.

Isn’t this working as intended? https://minecraft.wiki/w/Iron_Golem states “Hostile (when the player has -15 village popularity or below, and/or -100 villager reputation or below)”

As reasons are rare and I noticed on discord this ticket had been mentioned, apparently this tag was mentioned in https://www.minecraft.net/en-us/article/trails-tales-update-out-today-java and explicitly marked with “This tag only represents the internal state of the game, changing this tag does not make blocks replaceable”.

So the tag was indeed knowingly limited in its implementation. Fair enough.

In case it’s useful for anyone since this was WAI’d.

predicates are not affected by invalid positions, where execute is. execute if|unless block has three states, true|false|exception, location_check predicates have true|false.

Blocks replacing blocks that aren’t marked as replaceable isn’t a bug? Ok, moved bug report to a feature request on discord;

Minecraft Feedback Discord: Java-Datapacks > Falling blocks should adhere to `#minecraft:replaceable`

The implemented fix made potion_contents.custom_color correctly update the color.

Summoning with or setting Particle.color does not affect the particle colors as of 1.21.5

Default particle color changed from white to black as of 1.21.5

@B4dAtMC: How did you test? Any fire placed with /setblock or /fill is forever here in the snapshots.

/setblock ~ ~ ~2 fire
/tick sprint 1d

fire is still there.

Burning arrows get Fire updated to -1s and updates visually now in rain.

Note that the edit to my report states that burning arrows are extinguished while flying through rain; This was not stated in my report. I did have the comment about Fire ticking while in flight, and as a control set it to 2 to see if a ticked to 0 arrow stopped being on fire while in motion which it properly did.

It's related, but might be reported elsewhere. ie that Fire does not tick when inGround:1b. Meaning, a landed arrow will burn for 1200 ticks (life) regardless of how many Fire ticks remained. (unless it's raining 🙂)

Simple way of showing it is to add a scoreboard with minecraft.custom:minecraft.swim_one_cm and observe that it stops ticking if you punch a mob while swimming.

Interestingly enough, if you via a datapack (

) give the player blindness and clear it roughly 2 ticks later, it will force the client and server to start agreeing again. Shame it seems only blindness fixes it, so not the most subtle workaround.

I'm assuming my report was not clear, sorry if I explain something that was perfectly clear, or if I'm too verbose.

The expiry of the token in the logs always happens 24 hours after initial login. In none of my rotated logfiles were a refresh that happened after the launcher had gone past the initial login / authentication / assets loading.

The expiry is most likely working just fine, the token most likely has a 24 hour window on it. The bug is that the launcher does not refresh the token / requests a new token.

Meaning that if the launcher is open for more than 24 hours (which I constantly have, as I monitor the log output when working on data packs), online play will become unavailable. Only fix is to close minecraft and launcher in order for the launcher to exit, start the launcher again for it to refresh the token, start minecraft.

If there was something unclear about the logfiles, please let me know.

All the rotated files show the same information, expiry occurs after 24 hours. If you have the ability to alter the token expiry with internal QA tooling, set it really low, join a world, wait for the "Token in STS has expired" log from Auth.cpp, try to join a new world. If that's not possible, you could try, (but I don't know if the expiry is system time based or a windows equivalent for monotonic clock)

start launcher

move system clock forward one day

wait for log message

try to join a world without restarting the launcher

The rotated and main log file has no refresh of token outside the inital authentication handshake/setup, always an expiry 24 hours in.