This is probably more speculation than anything, but has anybody looked at the Wandering Trader's AI vis-a-vis villager AI?
Apparently, the trader's NBT data stores a "WanderTarget", an XYZ tuple representing a spot the trader is trying to get to.
I wonder if, perhaps, the trader is "required" to go to these spots in much the same way villagers are "required" to go to job sites or home at certain times of day, and begins running faster and faster to try to get there.
In a number of cases, it's probably a nonissue since vanilla terrain is benign enough that it's likely going to pick an easily reached spot. But, if a trader spawns within a player's turf that's particularly "exotic" in design, it might be continually trying to reach places it just simply can't get to, and ends up frantic.
Can also confirm in 1.14.2 pre-4 that I can "trap" myself in a Fence Gate by closing it while moving through it, resulting in this player movement pseudo-soft-lock.
Still an issue in 1.14.2 pre-4 for me.
[edit] Beacon particles, anyway. I have not ever put on a turtle helmet so I can't speak to that.
Can I call confirmed for 1.14.2 pre-3?
I still keep getting Ominous Banners that don't stack with each other. Oddly, every time I update to a new snapshot, it seems like the existing ones that don't stack now stack and some new unstackable one happens.
This is intended behavior, or at the very least not unintended behavior. Illager patrols spawn within 200 blocks of a recognized village so long as the biome type, sky visibility, block type, and light level meet spawn conditions. The game has no built-in notion of "player property" so if a player's builds are within that range of a village areas meeting those conditions, Illager patrols can and will spawn within it.
Illagers are also innately hostile mobs and will attack the player on sight if within range. Being part of a patrol may change their movement AI, but it does not affect this hostility.
[edit] According to others on this jira, apparently illager patrols are unrelated to village proximity and will simply spawn where the conditions are valid. Apparently, this is developer intended, though I have yet to find where an actual developer says this.
Commenting to say that I opened my prior mentioned from-19w world (which has not seen an iota of aquatic life) in 1.14.1 pre1 and found squid and salmon spawning in their usual river spots.
This might have been fixed, either intentionally or incidentally (perhaps tangentially related to MC-147890?). Emphasis on "might". Correlation does not necessarily imply causation, so would be nice if Adam or Val could confirm or deny if their worlds are fixed now too.
Started up a brand new world in 1.14 release (seed: -7788141165841699715), was greeted by fish and squid and drowned.
However, in one of my actual play worlds that I started back in 19w snapshots and updated all the way, aquatic mobs no longer seem to spawn as of the last couple pre-releases and 1.14 final.
I'm not sure why aquatic mobs can spawn in worlds made in the latest snapshots or the final release, but not in worlds ported to the newer versions. (Though I only have two data points corroborating this.) If it were a format issue between versions, that shouldn't stop the spawning of new mobs. If it were a code bug or exception, they likely wouldn't be spawning at all, regardless.
TBH, I wonder if this could be reference related. Maybe aquatic mobs aren't getting removed from the game properly and so they are counting towards their mob cap without being physically present. This would explain why I'm greeted by fish in a brand new world, but finding nothing in my older one.
However, I don't have any tangible proof of that, aside from searching my play world's NBT with NBTExplorer and finding evidence of fish mobs in the NBT. Could be meaningful, but I won't insist it is.
@Void_Concept
I did not encounter the same fortuity in my research and, logically, I can't understand how you encountered it yourself.
As far as I can tell, Chunk entity information isn't selectively written. It's more of a "wipe-clean-and-rewrite" process. Meaning if villagers don't load their serialized buyB data but still save back to file, that buyB data is lost for good.
I've done a lot of fiddling with villager NBT via NBTExplorer. I've injected my own buyB tag into a trade, saved, loaded up Minecraft, quit, and re-examined the data in NBTExplorer. The tag ceases to exist. Ergo, I'm inclined to say that the common case will be irreparable loss of trade data for any loaded villager.
In regards to why you still found remnant buyB tag data in world saves, I'd guess you might have been peeking at data for villager entities that have not yet been loaded in game.
The problem isn't necessarily that they de-spawn, but that they take their pilfered loot with them. It's not unlikely for a person to die and then swap to peaceful to make getting their stuff back easier. I don't personally, but it's not something that never happens.
I have amended the report to reflect the issue more accurately.
I'm having this problem as well, though I think it may have to do with spherical distance rather than merely the y-axis: my hives are surrounded by low buildings: there's no need for them even to approach 22 blocks in height, let alone exceed it to move about, and the ones that break away tend to do so centrifugally.
Another point of interest: I've occasionally observed the ones that break away hanging around their nests with pollen but not going in, and then going in when another emerges, but flying off if they have to wait too long. Now, I have six bees and two nests, so there should be enough housing, but perhaps there's an issue with them correctly ascertaining how full their nests are?
Finally: usually, I bring back the stragglers with leads. After being released in the vicinity of their old nest, they will simply float in the air or fly back and forth a short distance–they won't wander away, but they won't go into their nests either, regardless of what the still-registered bees are doing. Quitting and reloading the world jars them back into following their scripts, however, and they'll fly in immediately, though only eventually to wander off again in two to three days.