knirch

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.

(( For clarification: I have no ill will or malice towards anyone, and if my comment comes off as confrontational or passive aggressive, that is not intentional. It's difficult to convey tone in text, and I ask many, slightly modified questions, which could be misconstrued as an attack or angry rant. It's not. Intention is to ask questions that when answered makes things better. Thanks))

Interesting, that user seems to experience the same bad behavior. Instead of simply closing the ticket as WAI, could there be some reasoning attached to it? Something like "developer feedback: enchantment mechanics are tightly coupled to items, which does not yet support dynamic loading" or similar, preferably with reference to related developer resources?

I've been over the guidelines, community support, the two discords, (larger communities; the wiki, mcc discord); Where is it stated that this mechanic is experimental? It made it from the snapshots to the pre release, it sure isn't advertised as experimental (right?), but rather the opposite in https://www.minecraft.net/en-us/article/minecraft-snapshot-24w18a

• All Features from the experimental 1.21 pack have been moved to vanilla

Trying to wrap my head around this, I'm wondering; What is it that is working as intended?

• That it's experimental

  • Will it be reverted before release, or will it transition to a non experimental state?

  • Is the public changelog incorrect?

• • • If so, where can one for future reference find out, to reduce the amount of WAI/DUPLICATE ticket noise?

  • Is minecraft.wiki (not Mojang AB or MS, I know) lacking in information about what features are considered experimental? Asking as it seems it's the authoritative source together with misodes mcmeta repositories on what's what.

  • or, am I and/or others mixing concepts? Worlds get tagged with "Experimental" on the loading screen if a custom dimension has been created, but a world with a data pack that contains "enchantment" is not. Are these not the "Experiments"; bundle, trade_rebalance ?

  • is no confusion; Is the lack of tag on my test world a bug? Or is the lack of warning when loading a world with custom enchanted items that no longer has the datapack enabled a bug? is this experimental not the same as outlined Am I confusing "Experimental Settings" with "Experimental" tag on world loading screen?

    • wiki states the Experimental tag comes from Experiments.

• User/Developer experience:

  • /datapack disable: A data pack will remain in some registries but removed from others

  • /datapack enable: A data pack will not report on parsing errors in json files during load for some features, but will prevent world from loading later.

  • /datapack enable: A data pack with experimental settings should not warn the admin/user when enabling it in a running world.

  • /datapack enable | disable: Is this not something that developers / users / server admins should rely on?

  • "Random" parts of data packs are not subject to /datapack enable | disable or /reload; data pack developers should know which parts require reloading the world.

    • Average user who wants to play with a friend downloads a datapack, adds it to the world they're playing, but it doesn't work.

• That a broken data pack can be enabled, partially work without any errors, but next time the world refuses to load

It's a nice maze;

• Guidelines state that I should comment for extra visibility if I think my ticket was incorrectly resolved.

• Boiler plate in resolution response states I should not comment on original bug report.

This ticket is a duplicate, that's just a matter of a fact, now what?

• Guidelines suggest reddit to take it further

• sliced_lime has stated " we no longer feel that Reddit is an appropriate place to post official content or refer our players to ".

Right, but /r/mojira. ...

• feedback.minecraft.net is for game play features ("make horses steal apples dropped on ground" etc).

You know what, I'll post this here anyway. Hopefully the questions matter, and not being misread as "entitled person on the internet want <XYZ> in minecraft".

Thank you.

Killing self with bow/arrow does NOT crash in 18w02
Killing self with TNT does NOT crash in 18w02

Arrows still crash 18w01a