Change the way default sounds are handled
- ACrazyNewfie
- Member
- Posts: 30
- Joined: Thu Dec 03, 2015 10:34
Change the way default sounds are handled
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?
Would there be any issues with this from a technical perspective?
- rubenwardy
- Moderator
- Posts: 6978
- Joined: Tue Jun 12, 2012 18:11
- GitHub: rubenwardy
- IRC: rubenwardy
- In-game: rubenwardy
- Location: Bristol, United Kingdom
- Contact:
Re: Change the way default sounds are handled
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
https://github.com/minetest/minetest/pull/10134
- ACrazyNewfie
- Member
- Posts: 30
- Joined: Thu Dec 03, 2015 10:34
Re: Change the way default sounds are handled
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.rubenwardy wrote: ↑Thu Sep 03, 2020 14:58I 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
- PolySaken
- Member
- Posts: 817
- 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
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.
Guidebook Lib, for in-game docs | Poly Decor, some cool blocks | Vision Lib, an all-purpose library.
- TumeniNodes
- Member
- Posts: 2943
- 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
This would be a nightmare for modders/game makers, while adding no remarkable advantage, overall.
A Wonderful World
- ACrazyNewfie
- Member
- Posts: 30
- Joined: Thu Dec 03, 2015 10:34
Re: Change the way default sounds are handled
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?TumeniNodes wrote: ↑Fri Sep 04, 2020 05:00This would be a nightmare for modders/game makers, while adding no remarkable advantage, overall.
Again, perhaps I didn't understand what you were saying, I'm just asking for a bit of clarification.
- TumeniNodes
- Member
- Posts: 2943
- 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
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.
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.
A Wonderful World
- ACrazyNewfie
- Member
- Posts: 30
- Joined: Thu Dec 03, 2015 10:34
Re: Change the way default sounds are handled
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.TumeniNodes wrote: ↑Fri Sep 04, 2020 23:47If 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.
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.
- rubenwardy
- Moderator
- Posts: 6978
- Joined: Tue Jun 12, 2012 18:11
- GitHub: rubenwardy
- IRC: rubenwardy
- In-game: rubenwardy
- Location: Bristol, United Kingdom
- Contact:
Re: Change the way default sounds are handled
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
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 reasoningACrazyNewfie wrote: ↑Sat Sep 05, 2020 21:41A 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.
- ACrazyNewfie
- Member
- Posts: 30
- Joined: Thu Dec 03, 2015 10:34
Re: Change the way default sounds are handled
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_*.rubenwardy wrote: ↑Sat Sep 05, 2020 23:44I 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
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 reasoningACrazyNewfie wrote: ↑Sat Sep 05, 2020 21:41A 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.
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.
- Wuzzy
- Member
- Posts: 4804
- Joined: Mon Sep 24, 2012 15:01
- GitHub: Wuzzy2
- IRC: Wuzzy
- In-game: Wuzzy
- Contact:
Re: Change the way default sounds are handled
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.
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.
- rubenwardy
- Moderator
- Posts: 6978
- Joined: Tue Jun 12, 2012 18:11
- GitHub: rubenwardy
- IRC: rubenwardy
- In-game: rubenwardy
- Location: Bristol, United Kingdom
- Contact:
Re: Change the way default sounds are handled
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
- ACrazyNewfie
- Member
- Posts: 30
- Joined: Thu Dec 03, 2015 10:34
Re: Change the way default sounds are handled
I see. Thanks everyone for the discussion, I hope this gets implemented someday but obviously the engine just isn't quite ready yet.
- Pyrollo
- Developer
- Posts: 385
- Joined: Mon Jan 08, 2018 15:14
- GitHub: pyrollo
- In-game: Naj
- Location: Paris
Re: Change the way default sounds are handled
Yes, in general, the question would be: what is a "default" sound ?TumeniNodes wrote: ↑Fri Sep 04, 2020 23:47If 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?
I like Wuzzy's suggestion very much.
[ Display Modpack ] - [ Digiterms ] - [ Crater MG ] - [ LATE ]
- paramat
- Developer
- Posts: 3700
- Joined: Sun Oct 28, 2012 00:05
- GitHub: paramat
- IRC: paramat
- Location: UK
Re: Change the way default sounds are handled
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.
> 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.
- PolySaken
- Member
- Posts: 817
- 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
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.
Guidebook Lib, for in-game docs | Poly Decor, some cool blocks | Vision Lib, an all-purpose library.
- ACrazyNewfie
- Member
- Posts: 30
- Joined: Thu Dec 03, 2015 10:34
Re: Change the way default sounds are handled
Paramat,paramat wrote: ↑Tue Sep 15, 2020 19:56ACrazyNewfie,
> 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.
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 :)
Who is online
Users browsing this forum: Ahrefs [Bot] and 8 guests