This mod applies a series of optimizations to Ice and Fire.

The 1.20.1 version targets the official release, while the 1.21.1 version targets the community edition.

When neither is installed, the mod stays silent and throws no errors.

Optimizations shared between 1.20.1 Forge (official edition) and 1.21.1 NeoForge (community edition):

Change target	Stock behaviour	Change	Result
Dragon Forge · input block `lureDragons`	Every tick, an entity query over a 100×100×100 box, plus one world raycast per dragon found	Cooldown between scans, default one scan per 20 ticks (1 s); set to 1 for the stock every-tick scan	Scan cost cut to 1/20; a dragon is flagged at most 1 s later, and what happens after it is found is unchanged
Dragon Forge · `assembled()`	`tick` calls it 4 times per tick; each call walks the whole multiblock (~26 block reads), about 104 reads/tick per forge on both sides	The first answer is cached for the rest of the tick	~104 → ~26 reads/tick (-75%); the structure cannot change within a tick, so the result is strictly equivalent
Dragon breath · mob-griefing lookup	A scorching dragon makes up to ~100 `destroyAreaBreath` calls per tick, each allocating a `MobGriefingEvent` and posting it on the Forge bus	Cached once per (tick, dragon ID); covers `destroyAreaBreath`, `destroyAreaCharge` and `causeExplosion`	Event posts drop from ~100/tick to 1/tick; destruction is unchanged, but a mod listening to that event sees fewer invocations
Dragon breath · destruction cap (off by default)	Unbounded streaming of 27/125/343 block boxes per tick, with a per-block random roll and an AABB entity-damage query	Optional switch: only the first N boxes per dragon per tick (default 6, range 1–100); aim, particles and sound untouched	Destruction becomes bounded and tunnels form more slowly; off by default, so stock behaviour is preserved out of the box
Dragon flight · `DragonUtils.getBlockInView` / `getWaterBlockInView`	Called every tick per flying dragon; each is a ten-iteration search allocating a `BlockPos` + `Vec3` per iteration, sampling the heightmap and raycasting	Cached per (dragon ID, method), default 4 ticks	Calls cut to 1/4; a dragon moves well under a block per tick, so heading is visually identical; fewer internal random draws, so the downstream world random sequence shifts
Dragon mating · `DragonAIMate.getNearbyMate`	Run from `canUse` every tick; entity query over an AABB inflated by 180 blocks	Cached, default 8 ticks	Queries cut to 1/8; mating reaction delayed by at most 0.4 s
Hippogryph mating · `HippogryphAIMate.getNearbyMate`	Every tick; AABB inflated by 8 blocks	Cached, 8 ticks	Queries cut to 1/8
Death Worm · `DeathWormAIFindSandTarget`	Every tick, a triple loop of up to 51×51×51 = 132,651 block reads	Cached, default 8 ticks	~16,581 reads/tick on average (-87.5%); sand target refreshed at most 0.4 s late
Siren · `SirenAIFindWaterTarget`	Every tick, a triple loop of 11×11×11 = 1,331 block reads	Cached, default 8 ticks	~166 reads/tick on average (-87.5%)
Cockatrice · `getFriendsCount`	While staring down a player, one entity query per tick	Recomputes only every 8th call, returning the previous value otherwise	Queries cut to 1/8; the count lags by at most 8 calls
Multipart entity · `EntityMutlipartPart.collideWithNearbyEntities`	Every tick per part, allocating an AABB, an entity query and a stream pipeline with two lambdas; dragon parts are overridden to nothing, so only the sea serpent’s 2 parts and the death worm’s 1 part pay it	Pushed once every 4 ticks	Cost cut to 1/4; an entity may overlap a segment for up to 3 extra ticks (~0.15 s) before being nudged out

1.20.1 Forge (official edition) only:

Change target	Stock behaviour	Change	Result
Pathfinding pool · `Pathfinding.getExecutor`	Built as `ThreadPoolExecutor(1, N, 10 s, unbounded queue)`; an unbounded queue never fills, so the pool has always run on exactly one thread and `dragonPathfindingThreads` never had any effect	Pool built with the configured thread count (core = max = N); `-1` defers to Ice and Fire’s own setting, clamped to 1–64, queue still unbounded	The config option now works and multiple dragons can pathfind in parallel; no job is rejected or dropped
Myrmex foraging · `MyrmexAIForage.getEdibleBlocks`	Walks 33×17×33 = 18,513 positions per call and is called 3 times per tick (`canUse` once + `tick` twice), about 55,539 position visits per tick per worker	Result cached for 4 ticks and returned as a copy, so callers still sort and pick as before	~4,628 visits/tick on average (-92%); a change in nearby food is noticed at most 0.2 s late
Myrmex storage · `MyrmexAIStoreItems.getNearbyCocoon`	Walks 31×15×31 = 14,415 positions per call, twice per tick, about 28,830 visits/tick	Cached for 4 ticks, keyed by the passed-in position	~3,604 visits/tick on average (-87.5%)
Myrmex guard · `MyrmexAIFindGaurdingEntity.canUse`	Every tick, a class + predicate entity scan followed by a list sort	Cached for 8 ticks; on a cache hit the `targetEntity` field is restored as well	Scans cut to 1/8, with the goal left in exactly the state a fresh scan would have produced
Myrmex hiding · `MyrmexAIFindHidingSpot.getTargetPosition`	Two heightmap samples per tick	Cached for 8 ticks, keyed by the radius argument	Sampling cut to 1/8

Notably, the AI of mobs created by Alex is almost entirely unaffected by other general-purpose mob AI optimizations.

Ice and Fire — Ultimate Optimization

介绍

常见问题

Ice and Fire — Ultimate Optimization 支持哪些 Minecraft 版本？

Ice and Fire — Ultimate Optimization 怎么安装？

评论

anderlyer 的其他作品

Ars Nouveau Performance Optimization