TickMender

1.4.2 - 2026-10-17

Two new switches: yigdHiddenAccessorySlots and revengeAlertNullAttacker. TickMender now has 43 switches. The 41 of 1.4.1 are unchanged.

You're in Grave Danger (yigdHiddenAccessorySlots)

• yigdHiddenAccessorySlots: You're in Grave Danger 2.4.18 saves the hidden, empty accessory slots of a grave without an item id, and every one of them made the game log Tried to load invalid item: 'No key id in MapLike[...]' when the grave was loaded (about 455 lines per server start). These slots are now read as the empty stack they always became, without asking the game to parse an item from them. No item is lost or changed; only the log lines are gone. It applies to 2.4.18 only; with another version the switch is idle. The log filter's pattern for these lines stays for those versions and for a switch that is off.

Minecraft (revengeAlertNullAttacker)

• revengeAlertNullAttacker: a safety net for a crash that other mods can cause. When a mob's attacker is cleared between the start of its revenge goal and the goal's call to mobs of the same kind, RevengeGoal.callSameTypeForRevenge failed with a NullPointerException in Entity.isTeammate. Without an attacker the call is now skipped; with one, nothing changes.

Updating from 1.4.1

Replace the jar. The new switches are added to an existing config/tickmender.json with their default (true); everything already in the file is kept. Whoever wants the old behaviour sets "yigdHiddenAccessorySlots": false or "revengeAlertNullAttacker": false.

1.4.1 - 2026-10-17

No new switch. TickMender has 41 switches, as in 1.4.0.

JVM arguments hint (jvmArgumentsHint): no -XX:+AlwaysPreTouch on a heap too close to the memory

• Why. A server in a 13 476 MB container logged heap 12288 MB and was offered the server line with -XX:+AlwaysPreTouch. Its owner set -Xms10G -Xmx10G with that line, and the server vanished 12 seconds into its start, without a crash report or an hs_err file: that is the system's out-of-memory killer. With -XX:+AlwaysPreTouch the whole heap is in memory before the game starts, and what Java needs besides the heap (classes, compiled code, threads, buffers: several GB with a large pack) then grows past the limit.
• What changes. When the largest heap leaves less than a quarter of the memory the JVM may use (the PC's memory, or a container's limit), but at least 4096 MB and at most 8192 MB, -XX:+AlwaysPreTouch is left out of the line. This applies to clients and servers, and to every preset, including a pack's own table in config/. With enough memory left, the line is exactly as in 1.4.0. A JVM that cannot say how much memory there is is treated as before.
• One WARN in the log says that the heap is too close to the memory and how much it leaves, and suggests an -Xmx that leaves enough: TickMender: JVM arguments hint: the heap (-Xmx, 12288 MB) is too close to the memory this JVM may use (13476 MB, ...): it leaves 1188 MB ... -XX:+AlwaysPreTouch is left out of the recommended line. Suggested: -Xmx9G or less. It adds a sentence when the JVM was started with -XX:+AlwaysPreTouch (remove it or lower -Xmx), and another when -Xms equals -Xmx. The WARN is also logged when every flag is already set, so a server that already runs with the old line is told. On a client it is in the log only; the screen is unchanged.
• tickmender-jvm-arguments.txt says the same. On a server the paragraph comes before the line, and the advice to make -Xms equal to -Xmx is left out. On a client it is the last sentence. English and German.
• The server presets g1-server and g1-server-large are now revision 2, because the line they give on such a machine changed. A server remembers nothing, so this only shows in the log. The client preset g1-pack stays at revision 1. A player who closed it with "Done" is not shown it again: on a machine with enough memory its line has not changed, and on a tight one the line only lost a flag.

Updating from 1.4.0

Replace the jar. Nothing in config/ changes. On a server with a tight heap, remove -XX:+AlwaysPreTouch from the start command, or lower -Xmx to the suggested value.