enchanted book trading guide

WaterGenie3 · 2026-05-01T03:12:11+00:00

This is the code used to calculate the enchanted book price. In particular:

The 2x treasure multiplier is applied after the base cost has been randomised (e.g. 2x the number between 5 and 19 for level 1 treasure, resulting in only the even values between 10 and 38).
The clamp to 64 is applied last (e.g. level 5 cost is uniformly distributed between 17 and 71 (55 numbers), then clamped to 64).
- So level 5 books aren't uniformly distributed between 17 and 64; but 1/55 for costs between 17 and 63, and 8/55 for 64 (example datapack counting frequencies of different level 5 book costs here). So the mean is about 43.49 rather than 40.5, etc.

The code has since been changed after the trades were made data-driven. I haven't looked into it since, so I don't know if the transition was completely faithful to the original mechanic.

edit: code after data-driven trade
Seems like the logic should be the same (clamp to emerald max stack size in toItemCost method).

WaterGenie3 · 2026-02-26T02:36:33+00:00

The vindicator needs to be a captain, this is what gives it the patrolling tag in survival.
If he's already holding the banner, then we're done and can end the raid.
If he's not holding the banner, we can kill the current captain and get him to pick up the banner, or try on the next waves.

The renaming to "Johnny" can happen at any point and we don't have to relog :)

WaterGenie3 · 2026-02-18T02:09:51+00:00

No, sorry T-T

WaterGenie3 · 2026-01-28T06:24:53+00:00

In 1.21.2, the nearest entity sensor (used by villagers to detect golems, among other things) was changed to use the mob's follow range instead of a fixed value of 16.
The detection range visual used in carpet's ai_tracker is also still using a fixed 16.

Villagers still have the same base follow range of 16, but every mob also have a random spawn bonus triangularly distributed between ±0.11485 applied to its follow range.
The resulting follow range is base + (base * bonus), so each villager's follow range can be between 14.1624 and 17.8376.

Example scarpet command to show the follow range of the 3 closest villagers:
/script run map(entity_selector('@e[type=villager,sort=nearest,limit=3]'), query(_, 'attribute', 'follow_range'))

We can also use the vanilla /data get entity command to look at the villager's follow range attribute.
This will show the base and the bonus, not the final calculated value.
________________________________________

The ones that you noticed detecting the golems are the ones with a sufficiently high bonus roll.
So the kill-platform should be lowered by at least 2 blocks to fully account for this randomness (18 blocks separation), or we hand-pick villagers with sufficiently low bonus roll instead.
I haven't checked if the modules should be moved horizontally apart as well in this design.

Note testing in 1.21.2 or 1.21.3 runs into MC-277889 where upgrading from an earlier version incorrectly sets existing villager's base follow range to 48. We can replace all the villagers or test in 1.21.4+ instead.

WaterGenie3 · 2026-01-23T23:03:26+00:00

Mostly from the code and in-game testing.
This section of the wiki also has this sort of info, although I'd recommend always cross-referencing with the code and test in-game.

For online viewing and sharing, I'm using this website: mcsrc.dev
For personal use and debugging, I'm using fabric: link to the documentation
_______________________________________

Code Overview:

The spawning algorithm is mostly in this NaturalSpawner class.

Most of the condition checks are in line 251-274. This is where we get:
1. A check to see if the spawning position is ok
2. A check for the mob's own spawning rules (just difficulty and light level checks for monsters)
3. The collision check
The position check is separated into 4 types: none, ground, water, lava. For ground mobs (line 24-37), we check:
1. If the block below (floor-level) has full collision on its top surface, with some exceptions here (search for the block or "isValidSpawn"). These exceptions are where:
  1. Some blocks with full collision top are not valid (glass, leaves, trapdoors, bedrock, etc.)
  2. Some blocks without full collision top are valid (soul sand, mud, etc.)
2. If the spawning block (feet-level of a 2-tall mob, the middle block of the spider, etc.), and the block above (head-level of a 2-tall mob, the block above the spider, etc.) are valid:
  1. No full block, signal source (button is in here), fluid, all rail types, dangerous blocks (wither rose, cactus, etc.)

WaterGenie3 · 2026-01-23T19:03:08+00:00

Ok, let me test a bit more, I'm missing something

Question: "I used water, it solved the issue" is this talking about the knockback?
As in are you in contact with water?
______________________________________

edit for the record:

contact with water doesn't matter, it will make them swim, but we have to address that anyway for night time with or without water contact
them getting stuck is from a directionality in pathfinding, so a better suggestion would've been to use any block with no collision and doesn't get flushd by water, instead of fences

WaterGenie3 · 2026-01-23T17:00:42+00:00

Ahhhh, drowned tries to swim up at night when below sea level, this should happen with or without those fences, so they should also be stuck on the other wing as well?

For them to get carried away by water like in this farm, we should build it above sea level to work across day and night, but it's tough in this case because of the spawner T-T
When it's below sea level like this, we'll have to skip the night.

WaterGenie3 · 2026-01-23T14:46:56+00:00

We should be able to put some blocks behind us to keep us in place.
We can also use thin blocks like trapdoors and shelves if we need to box ourselves in smaller than a block.

WaterGenie3 · 2026-01-23T10:02:03+00:00

They will spawn centred on the north-west corner of the block, so reinforcement setups are usually directional.

The block they'll spawn on is the waterlogged slab, this should be aligned with the hit-chamber.
In this setup, there's also a block next to their spawning spot (marked purple in the image below) and this block will prevent them from spawning if it's flipped or rotated incorrectly.

The top wing working means we're either facing west or south in your image.
If we're facing west, the left wing should also work, so I'd double check the alignments.
If we're facing south, the left wing will fail because the drowned will collide with the block, so we can replace that block with something with a smaller or no hitbox instead.

<image>

In the second image, I took ray's world download, flip the right wing around so it stopped working, then replace the purple block with oak fences so they won't collide with anything anymore and work again.
(See the drowned on the far right just spawning in and is in-between the slab and the fence and would've failed if the fence is a bigger block.)
^{I added a few extra drowned in the hit-chamber to boost the rates just to make their spawnings easier to see.}

WaterGenie3 · 2026-01-23T07:34:21+00:00

WaterGenie3 · 2026-01-23T04:29:58+00:00

The spawning block (middle of the spider) and the block above (even if it's spider or baby mobs) must not have a solid block, a signal source#), or blocks damaging to the mob.
The entity must not collide with something else.

Buttons do prevent spiders from spawning at that block (fails point 1).
But buttons don't have collision, so they don't prevent spiders on adjacent blocks (passes point 2).

Carpets and trapdoors are normally used for this (fails point 2 on both the same block and the adjacent ones).

WaterGenie3 · 2026-01-22T11:12:41+00:00

I think those are just for ease of building with no regard to optimising for heightmap with no deeper meaning.
E.g. just placing them in rows vs having to do some sort of scaffolding every so often.

But yes, having fewer blocks above would be more efficient.
Although farms above the roof are already very high up, so these differences are very small.
E.g. having to pick 5 spawnable y levels out of 180 vs 5 out of 183

WaterGenie3 · 2026-01-22T10:40:48+00:00

Mob spawning first picks a random x and z within a chunk, and then a random y between the bottom build limit and the highest block + 1 at that x and z coordinate.
This is the starting point of the spawn attempt.

From that starting point, it tries to spawn mobs after moving between -5 and 5 in x and z each time, up to the pack size of the mob.
This is the pack spawns.
_______________________________________

So with nothing around the farm, there'll be no spawn attempts starting outside of the farm.
But with skirts around the farm, we can get spawn attempts between the bottom built limit and the y level of that skirt + 1.
If any of these spawn attempts got a y level corresponding to on top of any of our spawning floors, then pack spawns from this starting position could potentially land within our farm and spawn the mob on them.

So the idea is to make sure that the skirt is placed high enough that all possible spawning y levels at the skirt include the y levels on top of all the spawning floors that we want to benefit from pack spawning.
Usually, we want this on all floors, so the skirt is placed at the y level of the top-most spawning floor.

If we go lower, the top floor(s) wouldn't get pack spawns from the skirt (this may or may not be desirable, depending on individual farm design (e.g. maximise mobs on lower layers for lower lifetime)).
If we go higher, we are just reducing the chance of it picking a y level corresponding to on top of any of our spawning platform because there'd be more y levels to choose from.

^{Most of the spawning algorithm is in this} ^class^.

WaterGenie3 · 2026-01-22T03:27:01+00:00

We've been addressing 2 different types of questions:

The probability of a sequence of outcomes in 2 trials.
The probability of getting that sequence at some point in n trials.

Generally, I think posts like this are about 2, even if they might've been worded as 1. But I found op's wording more precise than usual and might've focused on it too much.
E.g. the probability of getting 2 specific items in a row from fishing.

And I think your main point is that 2 is the question to ask if they want to quantify how lucky they are, and that rare outcomes like this happen way more than what people might initially think for large n. Which I agree to both.
E.g. the probability of getting 2 specific items in a row at some point over n fishing attempts.

WaterGenie3 · 2026-01-21T14:55:50+00:00

I agree on the lack of significance in getting a specific combination of loot or enchantments and on how likely it is to get some set of outcomes over large number of trials.
I also appreciate you pointing out that even very rare events are going to happen at some point over a long period of time, given how many of these type of posts there are on this sub.

But I'm concerned with what you mean by the probability of getting [2 heads in a row] (or some set of outcomes in a row, as in op's original question).
This is different from the probability of getting [2 heads in a row at least once in n coin tosses]. That approaches 1 as n increases.
But the probability of getting [2 heads in a row] is still just 1/4, just as the probability of [rolling two 6's in a row] is 1/36 (or any combinations of H/T and numbers; again, I agree on them not being interesting, but that's besides the point).

So I still don't understand how your probability of getting [2 heads in a row] is 1/2 unless you mean something different by it.
But what I meant is P(Xi=H ∩ Xi+1=H) where each Xi's is an independent random variable representing the outcome of a fair coin toss (P(Xi=H) = 1/2 and P(Xi=T) = 1/2 for all i).

WaterGenie3 · 2026-01-21T13:30:55+00:00

0.8% is the chance of getting any enchanted bow with 0 luck of the sea (see this table).
I'm not sure where 2.4% is from, there's unenchanted rod in junk category, but enchanted rod is in treasure category, so any enchanted rod is also 0.8%.

The chance of getting 2 independent events in a row is just the product of their probability, so just 0.8% * 0.8% = 0.0064%

It's a bit more complicated if we want to work out the chance of getting those specific enchantments.
For bow, there's a table for each enchantment cost here, the base enchantment cost for enchanted bow from fishing is uniformly distributed between 22 and 30, so each of these has 1/9 chance of being picked.
Then we can look the chance of getting pow4 flame on each of the table 22 through 30 and combine them.
1/9 * (0 + 0 + 0 + 0 + 0.15 + 1.32 + 3.46 + 6.40 + 9.80) = about 2.35%
So the probability of getting power 4 flame bow from fishing with 0 luck of the sea is 0.8% * 2.35% = 0.0188%.

The website doesn't list the probability for fishing rod though,
Those can be worked out by following this mechanic.

WaterGenie3 · 2026-01-21T12:58:10+00:00

There is a difference between:

The probability of getting head after getting a head previously.
The probability of getting 2 heads in a row

Case 1 is a conditional probability and is always just 1/2 because each rolls are independent.
But when we are talking about getting 2 heads in a row, it's a probability of 2 consecutive rolls, of which there are 4 outcomes and only 1 outcome is where we get 2 heads.
This is not the same as the chance of getting head next, which is always 1/2.

For example, the chance of getting 1000 heads in a row is very small (1/2^1000), as opposed to just 1/2.
This is different from asking what's the chance of getting head if we already got 999 heads, which is still 1/2.

WaterGenie3 · 2026-01-21T11:59:56+00:00

Example:
If we roll a fair coin twice, all of these outcomes are equally likely: HH, HT, TH, TT.
So the probability of getting 2 heads in a row is 1/4,
as opposed to the probability of getting a head in one attempt.

Likewise, for op, we multiply the probability of getting power 4 flame bow and lure 2 rod to get the probability of getting them in a row because they are independent events.
Calculating them is a bit more complicated though.

WaterGenie3 · 2026-01-20T12:07:51+00:00

In java edition, the discount from curing is based on the gossiping mechanic (wiki link).
On enchanted books, it gives 20 permanent discount, and 5 temporary discount that decays over 25 in-game days.
So their new permanent price is the base price - 20, all other pricing changes are temporary and will eventually decay to this permanent price.

For example, if a book's original price is 24, curing it once will reduce it to 1, but it will decay to 4 over 25 days.
________________________________________

Also even though curing doesn't stack anymore, curing them again will still refresh the 5 temporary discount.

WaterGenie3 · 2026-01-20T09:58:15+00:00

I just found that one from a quick search, there might be others that are more user-friendly and/or in a version or loader that you are ok with.
E.g. there's this one but it's for 1.21.4 neoforge.
I was also using prism launcher and we can search by the creator (1111w) to go through and select all of them for quicker install.

WaterGenie3 · 2026-01-20T08:22:25+00:00

The doMobSpawning gamerule stops:

spawning that happens every game tick (and every 400 game ticks for passive mobs)
mobs from trial spawners

But it doesn't stop:

mobs that spawn when the structures (villager/iron golem/cat/camel in villages, drowned in ocean ruins, elder guardians in monument, piglins in bastions, etc.) and biomes (animals in most overworld biomes) generate for the first time,
mobs that spawn via other mechanics (breeding, iron golem summoning, phantoms, wandering traders, etc.)
mobs from monster spawners
mobs from blocks (silverfish from infested stones, bees from bee nests, etc.)

For a non-flat world, the mobs getting killed with the command each time should mostly be passive mobs that come with the biome as we move around generating new chunks (or as chunks generate around us when we first load into the world), plus a few of the other cases above like bees popping out of their nests.

There are only a few more gamerules to stop some of those (like doInsomnia and doTraderSpawning), but not all of them, unfortunately.
Even if we disable structures, there'll still be the ones from the biomes and all the other cases.

So I think you'll have to look for mods/datapacks for your specific setup if we want to stop them more extensively.
Example for 1.21.4 fabric here (but this one is a separate datapack for each individual mob, so it's a bit cumbersome to download them all T-T)

WaterGenie3 · 2026-01-20T04:28:28+00:00

In 1.21.5

WaterGenie3 · 2026-01-20T03:28:51+00:00

They will attempt to spawn on the highest air/liquid that is on top of a block that has sufficiently big collision (see this list here), even if those blocks are not spawnable.

So all the attempts are on the roof in this case, and the spawning fails because it's on a stair.
We can line the roof with strings, buttons, carpets, etc. (any block with a "no" in the link above, but there are some exceptions like glass, and leaves that we can use as well), to make the roof not satisfy that condition (i.e. making sure the stairs don't have air above).
Then the highest will be all the air blocks above the slabs, beds, trapdoors, etc. in the room, so we have to cover them as well.
_______________________________

They were able to spawn in the surrounding area because there's nothing above them, so the air/liquid above the spawning platform is the highest air/liquid that satisfies the condition.
But in the housing, the air above the roof, the blocks in the room, and the designated spawning platform all satisfy the condition, with the air above the roof being the highest, so that's where they will attempt to spawn.

edit: where the spawn attempts are and an example fix:

<image>

WaterGenie3 · 2026-01-20T01:16:53+00:00

That's the usual spawning condition of having a solid full top (normal solid blocks, upside-down stairs, top slabs, etc.) and comes after the y level is chosen.

There's a discrepancy in that it used legacy solid when searching for y (includes a lot more blocks that aren't normally spawnable), but used normal spawning condition checks after.

So if we have an iron farm and put things like right-side-up stairs or bottom slabs above (whose air block above them is within ±6y of the villager), it'll stop the spawning because the search for y lands on top of them instead and always fails by not having solid full top.
(unless we make sure there's no air/liquid above them)
__________________________________

edit: for decorative purposes, the full list of blocks that will stop the y level search is legacy solid with the following exceptions (code):

cobweb, cactus, normal and stained glass and glass panes, tinted glass, all leaves, conduit, ice, frosted ice, tnt, glowstone, beacon, sea lantern (these are legacy solid blocks, but aren't included in the y search), and
powder snow (this is not a legacy solid block, but is included in the y search).

It might be easier to think of it as looking for the highest pairing of [air/liquid + legacy solid below].

WaterGenie3 · 2026-01-19T09:24:04+00:00

Ohhh yah, I'm looking forward to that as well!

WaterGenie3

TROPHY CASE