v2

Information for everyone

Summoning Command

Summoning axolotl can be now done with a string value as the "variant" nbt.

This is similar to the namespace system minecraft uses almost anywhere else but doesn't for some entity variants included the axolotl's.

For example this would be how to summon the vanilla lucy variant:

/summon minecraft:axolotl ~ ~ ~ {variant:"minecraft:lucy"}

Or to summon a variant from More Axolotl:

/summon minecraft:axolotl ~ ~ ~ {variant:"more-axolotl:neon"}

Item components

Use mavapi:axolotl/variant over minecraft:axolotl/variant. minecraft:axolotl/variant only works with vanilla variants and isn't namespaced.

Without MavAPI: /give @s minecraft:axolotl_bucket[minecraft:axolotl/variant="blue"] With MavAPI: /give @s minecraft:axolotl_bucket[mavapi:axolotl/variant="minecraft:blue"]  

Information for Modders

The recommended way of creating new variants is to use the datapack method. If you need to interact with axolotls in Java code, see § Java API;

Importing the API

Currently importing can only be done by importing the mod jar via gradle.

We are working on a way to implement it into jitpack or similar but because of the use of forgix this sadly comes with some difficulty.

Adding a new variant

Axolotl variants can be defined in data packs, as part of the directory structure below.

data pack name.zip or data pack name
├ pack.mcmeta
└ data
       └ namespace
             └ mavapi
                   └ axolotl_variant
                         └ <name>.json

Axolotl variants are defined using the following format:

The root object.
├ asset_id: The identifier of the texture to use.
├ baby_asset_id: The identifier of the baby texture to use.
├ rare: Optional. Whether or not this variant can rarely spawn from breeding. Defaults to false.
└ spawn_conditions: The spawn conditions of this variant, see Mob variant definitions § Spawn condition.

Migrating from v1

See § Adding a new variant to for a guide on how to add new variants.

If your axolotl variant was natural in v1, then set rare to false.

If when migrating to v2, you decided to change the variant's id, you can migrate its id in existing worlds using V1AxolotlMigrations.migrateToV2(oldId, newId).

Otherwise, migrating an existing world from 1.20.4 to 1.20.5+ should work without any hitches.

Java API

Axolotl variants now use AxolotlVariant instead of the hardcoded Axolotl.Variant enum. You can get and set the variant of an axolotl in the AxolotlHelpers class.
It is recommended for you to make a class containing all the variants your mod adds.

public class ModAxolotlVariants {
	public static final ResourceKey<AxolotlVariant> CHEESE = createKey("cheese");

	private static ResourceKey<AxolotlVariant> createKey(String name) {
		return ResourceKey.create(MavApiRegistries.AXOLOTL_VARIANT, MoreCheese.id(name));
	}
}

To check if an axolotl is your variant:

AxolotlHelpers.getVariant(axolotl).is(ModAxolotlVariants.CHEESE)

Don't use anything inside the implementation packages unless you understand that it could suddenly stop working.

Adding a Bucket Texture and Tooltip Translations

The API has the feature of replacing the Axolotl Bucket Item Model based on the axolotl variant.

To use this feature place an item model for a variant in yourmodid:models/item/axolotl_bucket_yourvariantname.json

Also you can add translations that are used in the Bucket's tooltip to show the variant and the mods name.

These can be changed from automatically generating based on the internal names to translated ones using these language keys:

• Mod Name: mavapi.mod.yourmodid
• Variant Name: mavapi.variant.yourmodid.yourvariantname

The api will automatically grab the translations instead of the internal names if they exist.