03 Resourcepacks Textures and Models

Adding Skins: the Resource Pack

Once a skin is registered in a datapack (previous page), it exists as data — players can own it, see its name and rarity — but visually does nothing until you add the matching files here. This page covers all three optional-but-usually-wanted asset types: the 3D texture, the 2D inventory icon, and (for advanced skins) a full geometry replacement.

Everything on this page is looked up live, from whatever resource packs are currently active — nothing is baked in at build time. This means you can add, swap, or remove skin art just by shipping a new resource pack, with no Java code involved.

1. The texture (required for a skin to actually look different)

Path

assets/<namespace>/textures/skins/<sanitized_base_gun>/<skin_id>.png

Breaking that down:

• <namespace> — defaults to mcpskins. It's only different if the skin's id in the datapack includes its own namespace prefix ("namespace:path", see the previous page's tip about third-party packs) — in that case, use that namespace here instead.
• <sanitized_base_gun> — your base_gun value with the : turned into a /. So tacz:m4a1 becomes the folder tacz/m4a1.
• <skin_id>.png — the skin's id from the datapack (without any namespace prefix, if it had one), plus .png.

Worked example

For the ak74_golden skin from the previous page (base_gun: "tacz:ak74", id: "ak74_golden", default mcpskins namespace):

assets/mcpskins/textures/skins/tacz/ak74/ak74_golden.png

If instead the skin had been registered with "id": "mypack:ak74_golden":

assets/mypack/textures/skins/tacz/ak74/ak74_golden.png

What it needs to look like

Use the base weapon's own model texture as your starting canvas (extract it from the gun pack's resource pack) and repaint on top of it — the UV layout has to match exactly, since this file is a drop-in replacement for the existing texture, not a new model.

If the file is missing

No error, no crash — the weapon just keeps rendering with its normal stock texture, as if the skin ID had never been applied. This is intentional: it lets you register skins ahead of the art being finished, or ship metadata-only "coming soon" skins.

2. The inventory icon (optional)

TACZ weapons use a separate flat 2D image for their inventory-slot icon — it's not automatically derived from the 3D model's texture. That means re-texturing the 3D model (step 1) alone will not change how the weapon looks sitting in a chest or hotbar; you'll see the reskinned gun in your hands, but the old stock icon in your inventory, unless you also provide this file.

Path

Same folder as the texture, same name, with _icon appended:

assets/<namespace>/textures/skins/<sanitized_base_gun>/<skin_id>_icon.png

Example: assets/mcpskins/textures/skins/tacz/ak74/ak74_golden_icon.png

This is entirely optional — if it's missing, the base weapon's stock icon is kept, and only the held/3D-model texture changes.

3. Full geo-model replacement (optional, advanced)

Everything above only re-paints the existing 3D shape. If you want a skin that's an actual different shape — a different stock, a longer barrel, an attached scope molded into the model, whatever — you need a full geometry replacement instead of (well, in addition to) a texture swap.

Before you start: this feature depends on reflecting into TACZ-1.21.1's internal model-loading classes, and silently degrades to "texture-only" if it can't find what it's looking for on your TACZ build — see Troubleshooting & Internals for how to tell whether it's actually active on your setup. Don't be surprised if a first attempt just quietly doesn't apply; check the log.

Step 1 — find the base weapon's real model location

Every gun pack points its weapon at a model file through its own internal weapon config (the same JSON/config the gun pack itself uses to define animations, sounds, and geometry). You need the exact value of that weapon's model reference — MCPSkins reads it directly rather than guessing, so your skin's file has to line up with whatever that value actually is, not with a naming convention you'd expect.

Two ways to find it:

• Preferred: open the gun pack's own resource pack and find the weapon's display/config JSON (the one that lists its model, animations, sounds, etc.) and copy the exact value of its model field verbatim.
• Fallback: load into the game with any one geo-model skin already attempted (even a guess) and check the client log for a line starting with [MCPSkins][diag] Base weapon's real model ResourceLocation: — this prints the exact namespace and path MCPSkins read for whichever weapon first triggered the geo-model code path that session. It's not printed per-weapon on demand, just once as a sanity check, so treat it as a way to confirm you have the right format, not a per-gun lookup tool.

This value comes in what this wiki calls "collapsed form": no geo_models/ folder prefix, no .json suffix. For example, a weapon might report tacz:geo/m4a1/m4a1_geo — note that's not a literal file path, it's the shorthand TACZ itself uses internally to refer to the file physically located at assets/tacz/geo_models/geo/m4a1/m4a1_geo.json.

Step 2 — name and place your skin's model file

Given the base model's collapsed form <namespace>:<dir>/<base_file_name> and your skin's id, the skin's model must physically exist at:

assets/<namespace>/geo_models/<dir>/<base_file_name>__skin_<sanitized_skin_id>.json

Where <sanitized_skin_id> is your skin's id with any : or / characters replaced by _ (only relevant if your skin id has a namespace prefix).

Worked example

Base model (from step 1): tacz:geo/m4a1/m4a1_geo Skin id: m4a1_cobra

assets/tacz/geo_models/geo/m4a1/m4a1_geo__skin_m4a1_cobra.json

Note this file lives under the base weapon's own namespace (tacz in this example), not under mcpskins — unlike the texture files above. Geometry has to sit alongside the original model for TACZ's own asset pipeline to find and parse it correctly.

The one hard requirement: matching bone names

MCPSkins doesn't reimplement TACZ's model parser — it asks TACZ's own code to parse your geo-model file exactly like it would for a real weapon, by building a copy of the base weapon's config with only the model field swapped. The upside is your file gets parsed with 100% engine-accurate behavior. The one thing this means for you: your replacement model's skeleton (bone names) must match what the base weapon's existing animations expect. If a bone the animation system looks for doesn't exist in your model, the skin fails to build — safely, with a warning in the log, falling back to the base geometry — rather than crashing anything.

Everything else stays the base weapon's

Animations, sounds, and the base weapon's own icon are untouched by a geo-model swap — only the shape changes. Pair it with a texture (step 1 above) for the new shape to also be re-colored; a geo-only skin with no matching texture file will show the new shape wearing the old weapon's original texture.

How players (and you) can tell a skin has a custom model

The in-game Armory screen (see In-Game UI) marks any skin that successfully loaded a geo-model override with a small badge, and has a filter to show only those skins — handy for double-checking your own work in-game after a /reload.

Summary table

Asset	Required?	Namespace	Path
Texture	Yes, to visually differ from stock	mcpskins (or skin id's own namespace)	textures/skins/<base_gun, ":"→"/">/<skin_id>.png
Inventory icon	No	Same as texture	textures/skins/<base_gun, ":"→"/">/<skin_id>_icon.png
Geo-model	No, only for shape changes	Base weapon's own namespace	geo_models/<base model's dir>/<base model file>__skin_<skin_id>.json

Next: now that a skin looks the part, learn how players actually get their hands on it — Commands & Unlocking.