The addition of the new CHAN_OVERLAP flag and the extension of the available number of sound channels are very useful features in their own right. However, their usefulness is somewhat limited when it comes to extending existing code. This is not the fault of the new features themselves, but mostly a shortcoming which stems from the architecture of certain built-in GZDoom classes. Here is an example to demonstrate it:
Suppose I want to write a mod that would add the CHAN_OVERLAP flag to all inventory pickup sounds. (This use case is purely theoretical; see a more realistic example under the spoiler tag further below.) The very first problem is that it is actually impossible to write such a mod, because the only entry point available to us is the Inventory::PlayPickupSound method. It is virtual, which means I can write my own implementation of it, but in my context it would effectively mean that:
I have to override PlayPickupSound for every inventory item there is. This alone makes my original goal (play all pickup sounds with CHAN_OVERLAP) impossible to achieve, because a mod may add an arbitrary amount of new inventory items to the game.
I have to reimplement the original PlayPickupSound logic in my override. This means that if GZDoom changes it later, I will have to change it myself too, and unless I manage to notice the change and backport it to my mod in time, people might complain that it doesn't work "like in vanilla GZDoom".
Let's ignore the second point for now, and focus on the first one. Since I can't modify every inventory item in the game, I could instead implement the CHAN_OVERLAP flag for a fixed subset of items - for example, for all items from the Doom games. And even this approach means that I would need to subclass and replace virtually every item class that I want to modify, which amounts to a very tedious job with lots of copy-pasting. Granted, it has been made somewhat easier recently thanks to mixins, but it's still clear that this is not the best solution.
Spoiler: A more practical use case
I have loosely described it here. I have quite a few custom items in my project, and most of them have different pickup sounds, so I want to make sure that different sounds can play at the same time, but if the sounds are identical, they must override each other. I would also like to re-route pickup sound handling in this way for other items that are not replaced in my project but have new pickup sounds provided for them (misc/health_pkup for health items, for example). The latter is impossible without adding replacements, which might in turn make the mod incompatible with other mods and/or DEHACKED patches, especially those which employ this sort of trickery.)
So here is my proposal:
A new method, Actor::PlayItemPickupSound is added. Its default implementation simply calls A_PlaySound (or A_StartSound) with the provided arguments. This method can be overridden in a custom player class provided by the mod.
The original Inventory::PlayPickupSound method remains and retains its name for backwards-compatibility purposes, but instead of calling toucher.A_PlaySound, it calls toucher.PlayItemPickupSound.
Ideally, all parameters pertaining to the sound itself, like its volume, attenuation etc. should be passed to Actor::PlayItemPickupSound, which can, in turn, either use them as-is, or modify them accordingly in an override. In addition, it would be useful to also pass the inventory item itself (for example, to play pickup sounds for certain items on a different channel).
I am not sure if my proposal might be of any use beyond the use cases I've described, and I'm not yet sure of the exact list of arguments that the new method should accept. If the developers do not consider this too invasive and / or somehow able to break existing mods, and if it actually might be useful to other people, I could eventually provide a PR with an implementation. I will also appreciate if someone could come up with an even better alternative to solve these use cases.
In hindsight the entire design here is flawed. Ideally it shoild have worked so that the item provides the sound and the toucher plays the sound. It'll be a hell of a challenge to get this right without breaking things.
Graf Zahl wrote:In hindsight the entire design here is flawed. Ideally it shoild have worked so that the item provides the sound and the toucher plays the sound. It'll be a hell of a challenge to get this right without breaking things.
Can't help but completely agree here. That's why I didn't propose a PR right away - I don't have a vision of what the final result should look like. I was hoping to get some input from other people, in case anyone's interested.