Change the way default sounds are handled

Post Reply
User avatar
ACrazyNewfie
Member
Posts: 28
Joined: Thu Dec 03, 2015 10:34

Change the way default sounds are handled

by ACrazyNewfie » Post

Currently, a lot of mods rely on the default mod to give them sounds through functions like default.node_sound_defaults. I suggest this functionality be removed from the default mod and added to the core engine, that way instead of depending on default, you could just call minetest.node_sound_defaults. This could be extended to allow sound/resource packs to change these sounds, and reduces dependency on minetest_game, something I think the community is generally in favour of.

Would there be any issues with this from a technical perspective?

User avatar
rubenwardy
Moderator
Posts: 6251
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: Change the way default sounds are handled

by rubenwardy » Post

I attempted to implement this, but you unfortunately end up with dependency issues. Mods would still need to load after any mods that provide sounds

https://github.com/minetest/minetest/pull/10134

User avatar
ACrazyNewfie
Member
Posts: 28
Joined: Thu Dec 03, 2015 10:34

Re: Change the way default sounds are handled

by ACrazyNewfie » Post

rubenwardy wrote:
Thu Sep 03, 2020 14:58
I attempted to implement this, but you unfortunately end up with dependency issues. Mods would still need to load after any mods that provide sounds

https://github.com/minetest/minetest/pull/10134
If I read your PR correctly, you were trying to let mods register and define the sounds as opposed to the engine. I'm thinking of an audio equivalent for the built-in textures, which would be loaded before any mods and could be changed with a "sound pack" as opposed to a mod.

User avatar
PolySaken
Member
Posts: 632
Joined: Thu Nov 09, 2017 05:18
GitHub: PolySaken-I-Am
In-game: PolySaken
Location: Wānaka, Aotearoa
Contact:

Re: Change the way default sounds are handled

by PolySaken » Post

I'm in favor of this. I have a sound module in vision_lib for generic sounds so I don't have to repeat them across mods, but it would be far better for the engine to include generic sounds for node materials.

User avatar
TumeniNodes
Member
Posts: 2861
Joined: Fri Feb 26, 2016 19:49
GitHub: TumeniNodes
IRC: tumeninodes
In-game: TumeniNodes
Location: in the dark recesses of the mind
Contact:

Re: Change the way default sounds are handled

by TumeniNodes » Post

PolySaken wrote:
Fri Sep 04, 2020 02:26
I'm in favor of this. I have a sound module in vision_lib for generic sounds so I don't have to repeat them across mods, but it would be far better for the engine to include generic sounds for node materials.
This would be a nightmare for modders/game makers, while adding no remarkable advantage, overall.
Ich mag keine grünen Eier und Schinken, ich mag sie nicht Sam I Am

User avatar
ACrazyNewfie
Member
Posts: 28
Joined: Thu Dec 03, 2015 10:34

Re: Change the way default sounds are handled

by ACrazyNewfie » Post

TumeniNodes wrote:
Fri Sep 04, 2020 05:00
PolySaken wrote:
Fri Sep 04, 2020 02:26
I'm in favor of this. I have a sound module in vision_lib for generic sounds so I don't have to repeat them across mods, but it would be far better for the engine to include generic sounds for node materials.
This would be a nightmare for modders/game makers, while adding no remarkable advantage, overall.
Not sure I understand. All I'm suggesting is migrating the sounds out of the default mod so that mods/games that aren't built on minetest_game could still use them. It's main advantage, while perhaps not remarkable, would be allowing more mods/games to move away from minetest_game. How would this be a nightmare?

Again, perhaps I didn't understand what you were saying, I'm just asking for a bit of clarification.

User avatar
TumeniNodes
Member
Posts: 2861
Joined: Fri Feb 26, 2016 19:49
GitHub: TumeniNodes
IRC: tumeninodes
In-game: TumeniNodes
Location: in the dark recesses of the mind
Contact:

Re: Change the way default sounds are handled

by TumeniNodes » Post

If I understand what you're suggesting, sounds such as "sounds = default.node_sound_stone_defaults" would be hard coded in the engine?
If this is the case, what happens when someone wants to create a game which does not use "stone", and wishes to use "rock" instead or, maybe no stone-like sounds at all?

Builtin sounds could be overridden by using soundfiles under the same name, same as builtin textures but, if one does not desire to use the builtin names of those files, now they have to take extra steps

Moving away from MTG really isn't as difficult as some are making it out to be.
You can start from scratch completely... or simply use completely different sounds and new code or even edited code which already exists, etc..
But hardcoding sounds into the engine, imo, just adds aggrevation
If you wish to get away from MTG default, the worst thing to do, is to start hardcoding it into the engine

This is just my own opinion. And it is possible maybe I am the one who is misunderstanding.
Ich mag keine grünen Eier und Schinken, ich mag sie nicht Sam I Am

User avatar
ACrazyNewfie
Member
Posts: 28
Joined: Thu Dec 03, 2015 10:34

Re: Change the way default sounds are handled

by ACrazyNewfie » Post

TumeniNodes wrote:
Fri Sep 04, 2020 23:47
If I understand what you're suggesting, sounds such as "sounds = default.node_sound_stone_defaults" would be hard coded in the engine?
If this is the case, what happens when someone wants to create a game which does not use "stone", and wishes to use "rock" instead or, maybe no stone-like sounds at all?

Builtin sounds could be overridden by using soundfiles under the same name, same as builtin textures but, if one does not desire to use the builtin names of those files, now they have to take extra steps

Moving away from MTG really isn't as difficult as some are making it out to be.
You can start from scratch completely... or simply use completely different sounds and new code or even edited code which already exists, etc..
But hardcoding sounds into the engine, imo, just adds aggrevation
If you wish to get away from MTG default, the worst thing to do, is to start hardcoding it into the engine

This is just my own opinion. And it is possible maybe I am the one who is misunderstanding.
In my mind, it would be entirely optional. Games could use their own sounds, but for mods which want to integrate with multiple games, it could be helpful to have a way to access that core set of sound files. For example, the carts mod uses the metal placing sounds provided by default. Supposing I wanted to use that carts mod with a different game, I would get an error because the sound doesn't exist. But, if the engine was the one providing the function, it could use the regular sounds or whatever sounds the game provided to replace them.

A similar argument could be made against the built-in textures. Why do we we need to define a heart, or a bubble? Why not let the games do it?. (I know it's a somewhat flimsy argument, but bear with me). IMO, mods shouldn't have to supply their own sounds for everything, especially routine things like placing and breaking nodes.

User avatar
rubenwardy
Moderator
Posts: 6251
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: Change the way default sounds are handled

by rubenwardy » Post

I against this, as it doesn't really fix the problem. You're "fixing" the sounds issue for just one game, by hardcoding the sounds into the engine
ACrazyNewfie wrote:
Sat Sep 05, 2020 21:41
A similar argument could be made against the built-in textures. Why do we we need to define a heart, or a bubble? Why not let the games do it?. (I know it's a somewhat flimsy argument, but bear with me). IMO, mods shouldn't have to supply their own sounds for everything, especially routine things like placing and breaking nodes.
Because they are used in built-in elements. Nodes are not built in. I would prefer to not health and breath in the engine, personally. Note that just because something exists is not justification for something similar to exist - this is circular reasoning

User avatar
ACrazyNewfie
Member
Posts: 28
Joined: Thu Dec 03, 2015 10:34

Re: Change the way default sounds are handled

by ACrazyNewfie » Post

rubenwardy wrote:
Sat Sep 05, 2020 23:44
I against this, as it doesn't really fix the problem. You're "fixing" the sounds issue for just one game, by hardcoding the sounds into the engine
ACrazyNewfie wrote:
Sat Sep 05, 2020 21:41
A similar argument could be made against the built-in textures. Why do we we need to define a heart, or a bubble? Why not let the games do it?. (I know it's a somewhat flimsy argument, but bear with me). IMO, mods shouldn't have to supply their own sounds for everything, especially routine things like placing and breaking nodes.
Because they are used in built-in elements. Nodes are not built in. I would prefer to not health and breath in the engine, personally. Note that just because something exists is not justification for something similar to exist - this is circular reasoning
Hmmm, perhaps you're right. It seemed like a good idea at the time, but maybe we need to think of a different approach. What if we took your initial PR, but only allowed games to set up that functionality? Similar to the current way default handles sounds, mods in the game could call the "core mod's" functions (default.node_sounds_*) while mods from outside the game could call minetest.node_sounds_*.

I think this would also run into dependency issues, but I've got another solution. What if one mod in a game could be designated as the central mod, like default is for MTG. This mod would be loaded first, and all other mods would automatically depend on it. That way, it could set up the sound functionality before other mods are loaded, eliminating dependency issues and only requiring one set of functions (minetest.node_sounds_*).

It might be a bit overkill to change the way mods are loaded to solve one, admittedly small, wrinkle. But are there other ways this could be useful? I can't think of any off the top of my head, that doesn't mean there aren't any. This whole idea might go nowhere, but I want to make sure we've checked off all possibilities before we throw it down the drain because I think it could be valuable to mod makers wanting to integrate with multiple games.

User avatar
Wuzzy
Member
Posts: 4046
Joined: Mon Sep 24, 2012 15:01
GitHub: Wuzzy2
IRC: Wuzzy
In-game: Wuzzy

Re: Change the way default sounds are handled

by Wuzzy » Post

The problem with node sounds currently is (minor) dependency hell.

If you want to add a node, you MUST hard-depend on the game, or some special sound mod. This is annoying, and makes it complicated to make generic nodes.

What I suggest:

- Allow games to specify a default node sound
- Allow games to specify named sounds
- Allow node registrations to use a named sound
- Take inspiration from the group system

Proposed syntax:
minetest.register_named_node_sounds(name, sounds)
-- Registers a named table of node sounds. This function is to be used by games.
-- name = unique node sounds ID, sounds = same as 'sounds' in node def (so it may include footstep, dig, dug, etc.)
-- The name can be anything you want, but I suggest to always use something simple like “wood” and “stone”. The name is meant to be used across mods, and explicitly does not generate a dependency. Think of it as “groups for sounds”.
-- The name 'default' is special in that it will be the fallback sound

minetest.use_named_node_sounds(name, sounds_override)
-- To be used in the node def for the 'sounds' field
-- name = same as above, sound_override = optional table of sounds to overwrite some fields of the sound table
-- If use_named_node_sounds can't find a sound with the given name, it will fall back to the default sound.
-- If there is no default sound, just silence.

This proposed API is 100% backwards-compatible to existing game solutions, like the sound functions from default; they will still work perfectly fine. Also, this solution will eliminate the dependency hell between mods. You just define or query names.

Minetest will not offer any names except 'default'. But it is reasonably that some names will become very common, like 'stone', 'wood', 'glass', etc. This could be written into the Dev Wiki to attempt some standardization.
My creations. I gladly accept bitcoins: 17fsUywHxeMHKG41UFfu34F1rAxZcrVoqH

User avatar
rubenwardy
Moderator
Posts: 6251
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: Change the way default sounds are handled

by rubenwardy » Post

That's very similar to what I implemented, but you end up with the same issue of dependencies. The way around it is to more tightly integrate these named sounds into the API, and resolve when all mods have loaded. It becomes a pain, though

User avatar
ACrazyNewfie
Member
Posts: 28
Joined: Thu Dec 03, 2015 10:34

Re: Change the way default sounds are handled

by ACrazyNewfie » Post

I see. Thanks everyone for the discussion, I hope this gets implemented someday but obviously the engine just isn't quite ready yet.

User avatar
Pyrollo
Member
Posts: 384
Joined: Mon Jan 08, 2018 15:14
GitHub: pyrollo
In-game: Naj
Location: Paris

Re: Change the way default sounds are handled

by Pyrollo » Post

TumeniNodes wrote:
Fri Sep 04, 2020 23:47
If this is the case, what happens when someone wants to create a game which does not use "stone", and wishes to use "rock" instead or, maybe no stone-like sounds at all?
Yes, in general, the question would be: what is a "default" sound ?

I like Wuzzy's suggestion very much.
[ Display Modpack ] - [ Digiterms ] - [ Crater MG ] - [ LATE ]

User avatar
paramat
Developer
Posts: 3679
Joined: Sun Oct 28, 2012 00:05
GitHub: paramat
IRC: paramat
Location: UK

Re: Change the way default sounds are handled

by paramat » Post

ACrazyNewfie,

> Currently, a lot of mods rely on the default mod to give them sounds through functions like default.node_sound_defaults. I suggest this functionality be removed from the default mod and added to the core engine

That is unacceptable, the way MT works is that content is provided by games.

> reduces dependency on minetest_game, something I think the community is generally in favour of.

> It's main advantage, while perhaps not remarkable, would be allowing more mods/games to move away from minetest_game.

You claim this is 'moving away from MTG' but it is actually the opposite. This is hardcoding a part of MTG into the engine, which is the opposite of what we are trying to do in moving away from MTG and becoming a more game-neutral engine.

> I'm thinking of an audio equivalent for the built-in textures

The reason there are built-in textures is because those are the absolute minimum engine fallback textures that are essential for MT to function, they are perhaps useful in that way, but we could insist games provide them. Sounds are different because sounds are not necessary for MT to function.

> All I'm suggesting is migrating the sounds out of the default mod so that mods/games that aren't built on minetest_game could still use them

Your attitude to mod and game creation here is wrong. But this is not a personal criticism because your attitude is probably the result of influence from the MT mod/game creating community, much of which unfortunately has the wrong attitude to mods and games due to many years of focus on MTG.

If a mod is for MTG and uses sounds from default, there is no problem with depending on default.
If a mod is not for MTG and wants to use MTG sounds, or of a game wants to use MTG sounds, those sounds should be copied into that mod/game, they are freely usable.

> In my mind, it would be entirely optional.

That does not justify a wrong approach.

> but for mods which want to integrate with multiple games

There should not be an expectation that mods can work with multiple games. Each game is a different universe that does things differently. Mods should be written or edited for the game they are intended for.
I was discussing this with Sokomine in the MTG freeze thread, that this is a wrong attitude resulting from the unfortunate focus on MTG.

> For example, the carts mod uses the metal placing sounds provided by default. Supposing I wanted to use that carts mod with a different game

Then you should add the sounds into the new game or into an edited version of the carts mod.

User avatar
PolySaken
Member
Posts: 632
Joined: Thu Nov 09, 2017 05:18
GitHub: PolySaken-I-Am
In-game: PolySaken
Location: Wānaka, Aotearoa
Contact:

Re: Change the way default sounds are handled

by PolySaken » Post

As it stands now, mods are pretty much either for nodecore, mtg, or game independent. Games can provide default sounds in the way that mtg does, but a possible alternative is a dependency-free sound library mod. As I said before, my vision lib mod does this to an extent, but I only add sounds that I need. A sound focused mod wouldn't be too difficult for anyone with a freesound account and audacity.

User avatar
ACrazyNewfie
Member
Posts: 28
Joined: Thu Dec 03, 2015 10:34

Re: Change the way default sounds are handled

by ACrazyNewfie » Post

paramat wrote:
Tue Sep 15, 2020 19:56
ACrazyNewfie,

> Currently, a lot of mods rely on the default mod to give them sounds through functions like default.node_sound_defaults. I suggest this functionality be removed from the default mod and added to the core engine

That is unacceptable, the way MT works is that content is provided by games.

> reduces dependency on minetest_game, something I think the community is generally in favour of.

> It's main advantage, while perhaps not remarkable, would be allowing more mods/games to move away from minetest_game.

You claim this is 'moving away from MTG' but it is actually the opposite. This is hardcoding a part of MTG into the engine, which is the opposite of what we are trying to do in moving away from MTG and becoming a more game-neutral engine.

> I'm thinking of an audio equivalent for the built-in textures

The reason there are built-in textures is because those are the absolute minimum engine fallback textures that are essential for MT to function, they are perhaps useful in that way, but we could insist games provide them. Sounds are different because sounds are not necessary for MT to function.

> All I'm suggesting is migrating the sounds out of the default mod so that mods/games that aren't built on minetest_game could still use them

Your attitude to mod and game creation here is wrong. But this is not a personal criticism because your attitude is probably the result of influence from the MT mod/game creating community, much of which unfortunately has the wrong attitude to mods and games due to many years of focus on MTG.

If a mod is for MTG and uses sounds from default, there is no problem with depending on default.
If a mod is not for MTG and wants to use MTG sounds, or of a game wants to use MTG sounds, those sounds should be copied into that mod/game, they are freely usable.

> In my mind, it would be entirely optional.

That does not justify a wrong approach.

> but for mods which want to integrate with multiple games

There should not be an expectation that mods can work with multiple games. Each game is a different universe that does things differently. Mods should be written or edited for the game they are intended for.
I was discussing this with Sokomine in the MTG freeze thread, that this is a wrong attitude resulting from the unfortunate focus on MTG.

> For example, the carts mod uses the metal placing sounds provided by default. Supposing I wanted to use that carts mod with a different game

Then you should add the sounds into the new game or into an edited version of the carts mod.
Paramat,

You are absolutely right. Since quite a few "games" end up being the Minecraft equivalent of "modpack + resource pack", I guess I got started on the wrong track. Thanks for all the criticism, very helpful :)

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests