What do you need for a quote?

The mod (link or file), the version and loader it's on now, and where you want it. If you're the author or have their permission, say so too. With that I can tell you whether it can be done and what it would cost.

Do you need the source code?

No. I can work from the compiled mod and decompile whatever needs to change. It doesn't have to be on CurseForge or Modrinth either: the file you send me is enough. What decides whether I can touch it is the licence or the permission, not where it's hosted.

How long does it take?

It depends on the mod. You get an estimated timeline together with the price, before I start. If you have a date that can't move, tell me at the start and I'll tell you whether I can commit to it in writing.

By Wise or PayPal, always as Goods and Services. Small jobs are usually paid at the end; bigger ones can go in stages agreed in writing. Either way, you see the build running before the final payment.

Can the port be published?

It depends on the original mod's licence, and I tell you which case you're in before you pay. Open source: yes, published with credit to the author. Your own mod, or with written permission: yes, and I tell you what credit to include. All rights reserved and no permission: no, and I don't take the job on those terms.

What if a bug shows up later?

For 30 days from delivery I fix, at no cost, any bug I introduced within the agreed scope and setup. After that, or if it comes from a Minecraft update, other mods or changes to your server, we treat it as maintenance.

Why is 1.20.1 the shortest route?

It sits just below the big recent changes in Minecraft (networking, data components, worldgen), so bringing a mod there usually takes less work. Other versions have to cross those changes, and that shows in the price.

What exactly is a compatibility patch?

Making two or more mods work together without adding new content. For example: getting one mod's mobs to spawn in another mod's biomes, or fixing a conflict that breaks a feature. Each one is custom, so I quote it by scope.

Can you leave parts of the mod out, or change what it does?

Yes, and it is worth asking. A port does not have to be the whole mod: I can drop a feature you do not want, change values like spawn rates, durability or damage, retune or remove effects, and adjust recipes and loot. Tell me when you send it and it goes into the fixed quote, instead of turning into a second job later. The line is between tweaks and a redesign: rebalancing the whole mod is its own job and I quote it separately.

The mod's original textures and assets come across with the port. What doesn't: brand-new textures, 3D models or animations, full gameplay or balance redesigns, and ongoing maintenance across future Minecraft versions. Those get quoted separately, so tell me upfront and I'll fold it into the price.

Minecraft Mod Porting & Backporting Service

Things that break in a 600+ mod pack

I keep a huge test pack on my own. It's where I test compatibility, and where I keep running into bugs that almost never show up while a mod lives on its own.

Seven mods with no spawns

Seven mods loaded fine. Their mobs never showed up. All seven had the same misspelled folder: biome_modifier instead of biome_modifiers. Forge skipped it without a useful error. One letter was keeping seven mods from spawning anything.

Technical detail

Forge reads biome modifiers from a folder called biome_modifiers. Seven mods in my pack had the singular, biome_modifier, so Forge quietly skipped the whole folder: no warning, no error. It looks exactly like a broken mod. It's one missing letter.

Mutant More, written off as a rewrite

It had been out of my pack for weeks because it crashed on load, and the working theory was that it needed rewriting. It didn't. Its mixin config said JAVA_16 while its 577 classes were compiled for Java 17, so the mixin loader rejected every one of them. I changed that one word in my own copy, after checking in the Mixin library itself that JAVA_17 was a value it would accept.

Technical detail

Mutant More had been sitting out of my pack for weeks, crashing on load. The previous read was that its bytecode would have to be rewritten. It did not. Its mixin config declared compatibilityLevel: "JAVA_16" while all 577 of its classes were compiled as Java 17, so the mixin loader refused every one of them. Java 16 caps at class version 60; the classes were 61.

JAVA_16 became JAVA_17. Before touching it I opened mixin-0.8.5.jar, the version Forge 1.20.1 loads, and read its CompatibilityLevel enum to confirm JAVA_17 was a value it would actually accept, rather than assuming. Original jar backed up first, then repacked.

Mutant More is by AlexandersFunAndGames. That config line was the only thing I touched, and only in my own copy.

Fresh Animations on the mobs, Epic Fight on the player

Everything was set up right and Epic Fight kept winning anyway. Half the fix was a datapack that never loaded: it was missing its pack.mcmeta, and the log said nothing. The other half I found by reading how Epic Fight handles its renderers.

Technical detail

Fresh Animations on almost every creature, Epic Fight on my character alone. Taking a mob off Epic Fight takes two changes: a datapack entry stops its combat patch, but the mob still draws through its own renderer, so Fresh Animations never gets a look in. The other half is a script that pulls the mob out of that renderer map on world load. I found the split by decompiling the render engine.

The half that hid the longest. It was missing its pack.mcmeta, so the loader skipped the whole folder without a word. Both halves now name the same 24 mobs, and they still match today.

Fresh Animations is by FreshLX, Epic Fight by its own team. All I did was make them share a world.

I checked which mods animate themselves

48% of their creatures were already animated. They never needed Fresh Animations at all. I checked 645 jars instead of guessing.

The numbers

Fresh Animations does nothing for a mod that already animates its own creatures. Between GeckoLib, AzureLib and Citadel: 305 mods, 3,951 creatures. The scan turned an open-ended job into a short list.

I read 414 jars before letting one of them into my pack

Sixty-seven contradicted my own notes. Eight could never have loaded at all. I only found out by opening every single one.

What was actually inside them

I keep a store of mods I might want one day. Nothing goes from there into the pack until it has been read: the metadata, the loader it was built for, the version it targets, and whether anything already installed collides with it. 414 candidates went through that and came out sorted into 103 ready to go in, 192 in due course, 44 that needed a decision, and 75 on hold behind a missing dependency or ruled out on purpose.

Eight of them were never going to load. Three had no mods.toml, which means they were not mods at all. Three carried malformed JSON. One was a NeoForge build and one was compiled for a different Minecraft version. Every one of them sat in that folder looking exactly like a working mod, and my own spreadsheet said they were fine.

Six mods whose only job was making other mods get along

I wrote all six. Then I deleted all six. Five of their names still live inside the mod that absorbed them, on purpose.

Why the names stayed

Making a pack behave means writing glue: spawn entries, tags, recipes and loot that teach one mod about another. Mine had grown into six separate add-on jars that did nothing on their own. Six more entries in the mod list, six things to keep in step, and two of them shipped the same file path, so which one won was decided fresh on every launch. I folded all six into the two mods I already owned and deleted the jars.

I did not rename a single file. Data loads from the jar that carries it, not from the mod whose name is on the folder, so paths like omega_ssg_compat and omega_toasty_compat still sit inside a mod none of them belongs to any more. Renaming them would have meant touching every reference for no gain. It reads wrong and the game does not care.