-
-
Notifications
You must be signed in to change notification settings - Fork 21
Custom sounds for mod developers
Starting from 2.3, the sound generator explained below requires SoundDefinition objects, instead of just SoundEntry. Definitions are just containers in case you wish to use different sounds for pickup/placing or the hotbar selection. If you want to use the same sound, but with different pitches, you may wrap your SoundEntry results with SoundDefinition.of(yourSoundEvent), which results in the same functionality described below. The wiki will be updated for this eventually.
The same steps apply for mods as for resource packs, except you have to place the sounds.json under your assets folder. Make sure to use the extrasounds folder as well, just like in ExtraSounds' resources folder.
Starting from 2.0.0, apart from the usual sounds.json, you are also able to autogenerate sounds for items that share the same class or certain properties, all up to your discretion. As an example, you can check the default generator for Vanilla blocks and items.
ExtraSounds autogenerates the JSON file every single time resources are reloaded, and you need to make sure your autogenerator can be run at any point after item or block registration.
In addition to that, the autogenerator will only receive item identifiers that are of the same namespace, and only one generator can be registered for any given namespace. If you override the minecraft namespace, the default generator will not run anymore.
The build artifact is hosted on my personal Maven server. Add the following to your repositories block:
maven {
name = "stashymane's repo"
url = "https://repo.stashy.dev"
}And the following to your dependencies:
modImplementation "dev.stashy:extra-sounds:${project.extrasounds_version}"If you are going to use the project variable for the version, make sure to include it in your gradle.properties. Otherwise, you may include the version explicitly.
There are two ways to create a generator - you can either create an entire class that extends SoundGenerator, or just create a static field of it. For fields, the SoundGenerator class has a helper function SoundGenerator.of(), which builds a generator for you. This is the recommended way to do so, especially if the class will be modified in the future, as backwards compatibility will be retained, at least to a certain extent.
public static SoundGenerator fieldName = SoundGenerator.of(namespace, id -> { /* convert */});Sound generators essentially receive an item identifier, which you have to convert to a SoundEntry. Creating it manually is pretty verbose, so for more simple sounds (single events or sounds that already have categories) there are some helper functions in the Sounds class provided by ES. You may also use the registered categories so you don't have to manually create identifiers for categories that are provided by default.
To actually have your generator register, you have to add an extrasounds entrypoint in your fabric.mod.json, be it a class or a field. That will automatically be picked up and registered by the mod.
"extrasounds": [
"com.package.mod.class::fieldName"
]Of course if you extend the SoundGenerator class instead of creating a field you shouldn't include the ::fieldName part.
NOTE: IntelliJ will warn that it cannot resolve the field name if you have the Minecraft development extension, you may safely ignore this.