Project / living alongside other mods

Compatibility

This mod does not add a horse. It takes the vanilla minecraft:horse and hangs everything — the genome, the coat, the body stats, the herd — off it as data attachments and a render override. That one decision is the single biggest thing determining how it gets along with other mods, and this page is about what it buys and what it costs.

The decision: attachments, not a custom entity

The source design documents this mod grew out of assumed an EntityCustomHorse extends HorseEntity, with vanilla horse spawns zeroed out by biome modifiers and replaced with the mod's own. That approach is dead and is not coming back. The codebase has never worked that way and now deliberately never will: the record, the attachments, both sync payloads, the trait resolution and the coat all attach to the vanilla Horse, and the visual override the documents cited as the reason for a subclass already works without one.

What the attachment approach buys, and why the call went this way:

• Horses in existing worlds just work. A subclass can only apply to horses spawned after it exists; every horse in every world already saved stays a vanilla horse forever, or needs a conversion pass that is its own source of bugs. With attachments a horse acquires a genome the first time it is ticked, whenever that is.
• The 1.12.2 backport stays cheap. Registering an entity type, replacing spawns and porting a renderer is version-specific work three times over; an attachment is a capability there and a data attachment here.
• Spawn replacement is the fragile part, and we skip it. Zeroing vanilla horse spawns and adding your own is exactly the mechanism that breaks when another mod does the same thing, changes biome spawn lists, or adds horses of its own.
• Nothing needs it. Nothing in the gameplay layer — stalls, carrots, whistles, the browser, the dimension — requires a new entity type.

The cost is real and worth stating: a mod that replaces the horse renderer, or that spawns horses with its own baked variant, will collide (see below). We take that trade because the alternative collides with a much larger set of things and breaks every existing save as well.

What this mod actually touches

The honest compatibility surface, so a conflict can be reasoned about rather than guessed at.

The renderer is the real conflict

Only one mod can own the renderer for EntityType.HORSE. Whichever registers last wins, and if it is not us, every horse renders as a plain white horse — the genome is still there, still inherited, still correct, and completely invisible. If it is us, the other mod's textures are ignored.

Concretely, that means we are incompatible with:

• Horse texture packs implemented as mods that swap the horse renderer or model rather than shipping resources.
• Other horse-genetics mods (Realistic Horse Genetics, SWEM's coat system, and their kin). Two mods both generating a coat from their own genome is not a conflict that can be reconciled — they are two answers to the same question. A deliberate patch is a different matter and can be very clean: see supporting another mod.
• Model-replacement mods that give the horse a new mesh. Our coat generator projects into our UV layout (HorseSkinGeometry); a different mesh means every pattern lands in the wrong place.

A resource pack that retextures horses is a different matter and is simply ignored: we never sample the vanilla horse textures. Our template is horse_white.png in this mod's own namespace. That is the intended behaviour today and the intended behaviour is meant to change — the plan is to read the pack's own white horse and paint on it, at the pack's own resolution (texture resolution, and below).

Attributes: we overwrite, and that is deliberate

A horse's speed, health, jump and scale are resolved from its genotype and written as attribute base values every time it joins the world — not only at birth. That is on purpose: it is what lets a re-tuned gene, or a change to the health config, reach horses that already exist, and it is what stops vanilla's own randomisation from surviving.

The consequence for other mods is narrow but sharp. Anything that sets a horse's base speed or health will be overwritten on the next join. Anything that applies an AttributeModifier — which is how well-behaved mods, potions, and equipment do it — composes correctly on top of ours and is unaffected. If a mod's horse buff stops working, that is the distinction to check first.

AI goals and interactions

We add goals at priorities 3 (melee), 4 (bond follow) and 6 (wild herd), and give EntityType.HORSE an ATTACK_DAMAGE attribute it does not normally have. A mod adding its own horse goals at those priorities will interleave unpredictably rather than crash; a mod that clears the goal selector will silently disable herding and bond-following.

Interaction handlers are first-come. We cancel the event on both sides for the items we claim, so a mod that also wants to do something with shears or a bucket on a horse will find that only one of us runs. There is no priority negotiation here and adding one is not planned.

Spawning stacks

Our biome modifiers are purely additive — we add herd spawns to 37 biomes and loner spawns across the overworld, and we remove nothing. So installing this alongside another mod that also adds horse spawns gives you the sum of both, which is usually more horses than either author intended. If a world feels overrun, that is the first thing to check, and the fix is a datapack overriding add_horse_herds / add_horse_loners.

Third-party genes are supported, and are the right seam

The intended way for another mod (or a pack author) to extend this one is not to touch our classes. It is to add a gene:

• a gene file dropped in .minecraft/phc/genes/, or shipped on the classpath in a mod's own horsegenetics/genes/index.json — no Java, no rebuild;
• or, for something the file format cannot express, a Java Gene registered from a mod constructor.

Both interleave into the registry by priority, so a third-party natural gene lands in the right place in the paint order without anyone editing a list. Register from the mod constructor: every registration lengthens the genotype code by a segment, so a gene registered after something has parsed a code invalidates it.

A gene added or removed changes the code string, and this mod keeps no back-compatibility for that — adding or removing a gene means existing horses regenerate their coats, and a saved code with a different segment count will not parse. Adding a gene mod mid-world is therefore a fresh-world operation for now.

Supporting another mod deliberately

Everything above is about accidents — what happens when this mod and another are installed together and neither knows about the other. This section is the other question: what would it take to make a specific mod work with this one on purpose? The answer is different for each, but it decomposes the same way every time, into four seams.

Seam 2 is the interesting one, because we already cover more than a patch author would expect. What this mod brings that almost no horse mod has is the part between a genome and a pixel: a Mendelian model over Genes.codeOrder() loci with inherited per-allele epigenetics, a three-phase paint pipeline, a body-space projection so every pattern is a function of anatomy rather than of texture coordinates, and a data-driven gene format that lets a pattern be written without Java. What it does not bring, and what most of the mods below have, is tack, carts, animation, riding feel, storage, and detailed models. Those are almost perfectly complementary. The conflicts are nearly all seam 3, and seam 3 is negotiable.

User-written model remaps

HorseSkinGeometry is a table: for each part, a pivot, a box, a rest-pose pitch, and a 64-space texOffs. From those it derives every part’s bounding box in body space and every face’s UV rectangle, and from those it answers the only question the paint engine ever asks — given texel (px, py), what point on the horse’s body does it shade?

Nothing in that table is Minecraft-specific and nothing in it is hard-coded per gene. It is a Java constant today only because there has only ever been one mesh to describe. Lift it into a file and a pack author could describe someone else’s horse:

{
  "id": "betterhorses:adult",
  "sheet": 128,
  "texels_per_unit": 2,
  "parts": {
    "body":      { "pivot": [0, 11, 5], "box": [-5, -8, -17, 10, 10, 22], "tex": [0, 32] },
    "left_front_leg": { "pivot": [4, 14, -10], "box": [-3, -1, -1.9, 4, 11, 4], "tex": [26, 16] }
  }
}

That is close to a transcription of what a model’s addBox / texOffs calls already say, which is the point: a remap is readable off the other mod’s model class, or off an OptiFine/EMF .jem file, by someone who cannot write Java. Given one, the entire existing paint engine works unchanged — every gene, every spec file, both editors — because no gene has ever known what mesh it was painting.

What a remap format would have to settle, none of which is decided:

• Non-box geometry. The projection assumes axis-aligned boxes; rotated parts already use their rest-pose AABB as an approximation. A mesh with real curved geometry, or with parts that are not boxes at all, cannot be described this way without a genuine UV-unwrap importer — a much larger project.
• Part naming. HorseSkinGeometry.Part is a closed enum, and a good deal of gene code names members of it directly (mane, tail, the four legs, the two ears). A mesh that splits a leg into three segments needs those to map onto one logical LEFT_FRONT_LEG, which means the remap file needs a many-to-one grouping layer as well as a geometry table.
• Who resolves the conflict. A remap says how to paint another mod’s mesh; it does not say who gets to register the renderer. That is still seam 3 and still needs one side to yield.
• Validation. A wrong remap produces a horse with patterns in the wrong places and no error. The four-band colour probe is the existing tool for exactly this and would have to be exposed to pack authors.

Gaits, for models with real legs

A related and separable idea. Vanilla’s horse has four box legs and one animation; several mods below ship articulated legs and distinct gaits — SWEM has walk, trot, canter and gallop as separate animations. This mod currently has nothing to say about movement: it resolves speed, jump and health onto attributes and stops there.

That is a gap worth filling on its own terms, and it is the one place where a mod with a better model would let this mod express something it genuinely cannot today. The genome already carries the inputs — MSTN, LCORL, HMGA2, the body-size locus and the resolved speed stat all describe how a horse is built and how it moves — and gait is a real, heritable, breed-defining trait in horses that the mod currently throws away. A Standardbred that paces rather than trots is a genetic fact (DMRT3), and it is exactly the kind of thing this project exists to model.

Sketch, unbuilt and not on the roadmap yet:

• A GaitContribution interface alongside the existing coat and eye contributions, so a gene declares a gait rather than the renderer inferring one.
• Resolution in common/ to a plain named result — walk / trot / pace / canter / gallop plus a tempo scalar — with no animation concepts in it at all, so the backport and the browser tools keep working.
• A thin NeoForge translation that maps that result onto whatever the active model offers: vanilla’s single animation ignores it, an articulated model selects its matching clip.
• Which means the patch for a detailed-leg mod is small — a table from our gait names to their animation ids — and the gene work is shared across every such mod rather than written per-mod.

SWEM and SWEM Lite

The Star Worm Equestrian Mod is the largest equestrian mod there is, and it is the most interesting case on this page because the overlap is almost exactly one subsystem.

SWEM adds its own horse entity with its own GeckoLib model, its own animations including separate gaits, and a large hand-drawn coat catalogue — well over a hundred coats, selected by tags. Its own documentation is candid that the breeding is not genetics: each coat carries one or more colour tags, a foal picks a tag from a parent, and the result can be biologically nonsense (their example: a white foal growing into a leopard appaloosa, because both carry the white tag). That was explicitly a placeholder until a real genetics system was possible.

So the patch writes itself in principle: this mod supplies the genetics and the coat, SWEM keeps everything else. Their tack, stable blocks, tools, animations, jumps, horse care and the rest are untouched; we replace the tag-based coat selection with a genome and a generated texture.

What that would actually require, in the order it bites:

1. A geometry table for the SWEM mesh (seam 2). Their model is not vanilla’s and is not box-only, so this is the hard part and may be the blocking one — a GeckoLib model with curved or non-axis-aligned geometry cannot be described by the current projection without a real unwrap importer.
2. Attachments on their entity (seam 1). Viable if their horse extends AbstractHorse; a full port of the attachment layer if not.
3. Suppressing their coat selection — their texture resolution step has to be overridden to ask us instead. Whether that is possible without mixins depends on how their renderer is structured.
4. Deciding the stat boundary (seam 4). SWEM has its own progression and its own per-horse stats; ours are resolved from the genotype. Two answers to one question again, and the honest resolution is that one of them wins outright and the other is disabled — not an average.
5. Mapping their hundred-plus coats onto genotypes, if the patch wants to preserve existing horses. That is a content project, not a code one, and probably should not be attempted: a fresh world is the cheaper answer and matches this mod’s no-back-compatibility rule.

Icy’s Better Horses

A horse-overhaul mod that works the way this one does — it enhances the vanilla horse rather than replacing it — which makes it simultaneously the most compatible in architecture and the most directly overlapping in features.

It adds ownership and a 0–100 bond stat that grants speed and jump bonuses at thresholds; fifteen named real-world breeds with breed-specific coats, gendered breeding, biome-locked wild spawning and stat inheritance; upgraded saddles with gear slots, horse chests and ender chests; stabilizers, medkits and hitchposts; auto-ride, free-look, two-rider support and a command wheel.

Read that list against horse care, breeds and breeding and the problem is obvious: we both implement bond, breeds, gendered breeding, stat inheritance and biome spawning, and we do all five differently. Their bond is a flat percentage buff; ours is four behaviour tiers. Their breeds are fifteen named presets; ours are JSON founder distributions over a genome. Their foals inherit stats plus a random bonus; ours resolve stats from a genotype and never roll.

A patch would be a division of territory, and a fairly clean one:

• They keep the equipment layer entirely — saddles, slots, chests, medkits, hitchposts, stabilizers — and the riding-feel changes. Nothing in this mod touches any of it.
• We keep coat, genome, breeding and inherited stats, because that is the whole of what this mod is and their version is explicitly the simpler one.
• Bond has to be picked, not merged. Two bond numbers on one horse is a bug generator. Either their percentage buff reads our bond value, or ours is disabled and our tier behaviours read theirs. The first is less work and keeps both mods’ UIs honest.
• Their breeds become a breed file each. Fifteen named breeds is exactly what the breed format is for; expressing Thoroughbred or Friesian as a founder distribution is authoring work, not engineering, and the result is strictly better because the horses then actually carry the genes.
• Spawning must be de-duplicated — both mods add biome spawns, so installed together you get both.

Mechanically it is the most tractable patch on this page: both mods hang data off the vanilla horse, so seams 1 and 2 are free and only seam 3 (their renderer, if they replace it for breed coats — unconfirmed) and seam 4 need work. Note also they require GeckoLib and Modonomicon, and they ship for Fabric 26.2, NeoForge 1.21.1 and Forge 1.20.1 — again, no shared version with this mod today.

Horseman

A quality-of-life riding mod: hitching a mounted horse to a fence, a copper horn that summons bound horses, horses that swim when you press jump, horses that fit in boats, better camera handling, step-up increases, reduced mining penalty while mounted, horse/player inventory switching, dismount direction fixes.

This should work out of the box, and it is the best-matched mod on the page. It touches controls, movement and interaction; it does not touch the horse’s model, renderer, textures, attributes or coat, so all four seams are clear. It also targets 1.21.10 through 26.2 on NeoForge, so unlike SWEM and Icy’s it is a mod this could genuinely be installed alongside today.

Two things to check rather than assume:

• Its copper horn overlaps our whistles, and the roadmap wants to take that further still (callable horses). Not a conflict — two items that both recall a horse is redundancy, not breakage — but if a patch is ever written the right move is to bind the two to one notion of “your horse” rather than have each keep its own.
• Its swimming may collide with ours. This mod has its own riding-through-water handling (see architecture) and a magical swim-speed locus. Two mods changing how a ridden horse behaves in water is the one place they overlap in substance.

Mods that only change horse armour

No issues, and there is a structural reason rather than a lucky one. Horse armour in 26.1.2 is an equipment layer: the renderer adds a SimpleEquipmentLayer with its own model and its own EquipmentClientInfo, drawing from minecraft:textures/entity/equipment/horse_body/*. That is a separate texture, a separate model and a separate draw call from the coat. Our generated coat goes on the base layer and knows nothing about it; an armour mod adds items and equipment assets and knows nothing about the coat.

The one caveat is the same as everywhere: an armour mod that also replaces the horse renderer in order to add its layer, rather than adding a layer to the existing one, collides on seam 3 like anything else would. That is unusual and would be a design mistake on their part, but it is the thing to check first if an armour-only mod somehow breaks coats.

Horse Powered

Animal-labour machinery: a horse grindstone, chopping block, press, drying rack, granite anvil and an energy generator, driven by attaching a leashable mob to a block. It targets NeoForge 26.1.2 among others, so it is directly installable alongside this mod today.

The mechanism is the interesting bit. Attached workers become a virtual ghost render: the real mob is stored on the block so it cannot be killed, despawned or wander off. That means two things for us, and both need checking in-game rather than assuming:

• Storing and restoring the entity must preserve the attachments. Our genome, pedigree, bond and cooldowns live on data attachments. If the block serialises the mob with a full NBT round-trip they survive; if it reconstructs a fresh horse from a subset of fields, the horse comes back with a new genome and a different coat. That is the single failure mode to look for, it is silent, and it would look to a player like the horse changed colour in the mill.
• The ghost render has to go through our renderer to be painted at all. If it draws the mob itself with a hand-rolled path rather than the registered entity renderer, a working horse renders white while a loose one renders correctly — cosmetic, obvious, and diagnostic of exactly which path it took.

Beyond that there is no overlap: it adds blocks and consumes labour, we add genetics and coats. It is a good pairing conceptually — a mod that makes a horse’s strength matter is a mod that makes our MSTN / LCORL stat genes matter — and a patch that read our resolved speed or size to set work rate would be a genuinely small piece of code and the most rewarding one on this page.

Horse Combat Controls

Mount-and-Blade-style directional steering: forward accelerates, back decelerates, left and right steer, with a key to toggle between vanilla and combat control modes and a server config to lock players into one. It changes controls and nothing else — no entity, model, renderer, texture, attribute or AI change.

No conflict on any seam. It is a client input mod and we are a server-side data model with a client renderer; the two do not meet. The only thing worth noting is that this mod adds an ATTACK_DAMAGE attribute to horses and a melee goal, so a horse here can fight — which makes combat steering more useful than it is in vanilla, not less compatible. Version support stops at 1.21.4, so like most of this list it is not currently co-installable.

AstikorCarts

Carts pulled by other entities — a supply cart with double-chest storage, a plough, and an animal cart. It adds cart entities and attaches them to existing pullers; it does not modify the horse’s model, texture or rendering, and the puller list is configurable so any entity can be added.

No conflict. All four seams are clear: it hangs a second entity off the horse rather than changing the horse. The one thing to watch is our whistle recall, which teleports horses — teleporting a horse that is pulling a cart is exactly the sort of thing that leaves a cart behind, stretched, or attached across dimensions. If a patch is ever wanted, it is one check: do not recall a horse that is pulling something, or drop the cart first, the way we already drop a lead.

The practical obstacle is age. AstikorCarts is Forge-only and stops at 1.19.2, and its own author points at Astikor Carts Redux (Forge) and NiftyCarts (Fabric) as the maintained successors. Any real work here should target those, and the analysis carries over unchanged — they are the same design.

Resource packs, Fresh Animations, and EMF / ETF

A category apart, because it is where most people’s “better horses” actually come from. Better Horses x Fresh Animations by CanineGray is a resource pack, not a mod: it needs OptiFine, or the modern replacements Entity Model Features and Entity Texture Features, to supply a custom entity model and animations for the horse.

Today that pack and this mod ignore each other completely, in the worst way. We never sample the vanilla horse textures — our template is horse_white.png in our own namespace — so the pack’s art never reaches a coat. And if EMF replaces the horse mesh, our body-space projection is describing a model that is no longer on screen, so every pattern lands somewhere arbitrary.

Both halves have a planned answer, and they are separate pieces of work:

• The texture half is the resource-pack template plan: read the player’s own minecraft:textures/entity/horse/horse_white.png at whatever resolution the pack drew it, and paint the genome onto that. It costs a namespace change plus an un-mirroring pass plus making the sheet size a variable, and it makes every horse resource pack in existence work with this mod automatically.
• The mesh half is the remap format. An EMF .jem file is a box-and-texOffs description already, which is very close to the shape a remap needs — close enough that reading one directly, rather than asking the pack author to write a second file, is worth considering before inventing a format.

Neither is built. Together they would turn the biggest current incompatibility — “this mod ignores your horse pack” — into the mod’s best feature.

Known-good and known-bad

And the named mods analysed above. “Version” is whether it can be installed alongside this mod at all today, which for most of this list is the binding constraint rather than any technical conflict:

Unverified

None of this has been tested against another mod. Every claim above is read off this mod's own source and off how NeoForge's registries and events work, not off a play session with a modpack. The rows marked "fine" are predictions, and the renderer row is the only one that is a certainty. The named mods are described from their own public listings, not from their source — so every claim about what they do or do not touch is their description of themselves, and the two failure modes that matter most (whether Horse Powered's capture preserves data attachments, and whether Icy's Better Horses replaces the renderer for its breed coats) are exactly the ones a listing does not answer. Treat this page as the map of where to look when something breaks, not as a compatibility report.