by Enjay » Wed Sep 17, 2025 3:50 am
For me, what we have right now covers my needs: I only have one Doom-like player pawn and putting stuff in TERRAIN by building on the older is a convenient, and relatively easy way to do what I want. But, I guess that's the problem you're facing: it's a simple system built on to the existing TERRAIN stuff. To be fair, it seems like that's what it was intended to be.
I'm not saying "it works for me, so it doesn't need to be better"; simply that I'm lucky that (with a minor change - that took me far too long to figure out) I can use the system that exists to do exactly what I want, and I think I'm using it more-or-less in the way it was intended (i.e. as a base for my mod).
However, I totally see your points; particularly in a game where different player pawns are going to be used. There does, of course, need to be some way to define "this is a rocky surface and it makes a hard sound, this is gravel and it makes a crunchy sound, this is mud and it makes a squelchy sound" etc, and TERRAIN seems to be the logical place for that. Part of the consideration would also be the fact that some PlayerPawns will make different sounds depending on who/what they are - so that needs to be covered too, perhaps being able to add class identifiers to the sounds for a TERRAIN makes sense:
Code: Select all
terrain Whatever
{
...
StepSounds.fighter floor/fighter/tile
StepSounds.cleric floor/cleric/tile
StepSounds.mage floor/mage/tile
}
Or something?
But, yep, speed/frequency of footsteps and so on make sense to be in the PlayerPawn. I never thought about it when I was doing my stuff (because it wasn't on my radar for what I was trying to achieve), but tying how fast footsteps are to the terrain definition does seem limiting - especially for a multi-class game, because all player classes, regardless of type, always make the same sounds with the same frequency. There's certainly a big difference between an armoured beast of a fighter stomping across the land in full plate mail versus a ninja-like player tip-toeing across the same ground in a pair of tabi. However, some kind of "this terrain has a multiplication factor of X" for slowing/speeding up footsteps might have some mileage?
All that being said, a lot of the handling is actually in the player definition. If you look in player.zs in GZDoom.pk3. That's where I found the code that I modified to remove the forced always splashing on liquid surfaces, and I added my modified code to my player definition to override the default. So, perhaps what you are looking for is tailor-able to your needs (or to be closer to your needs). Perhaps you could look at what is needed and put different, relevant code in each of your player pawns? I don't know enough about ZScrip handling to say whether that is workable or not.
Some of the really old footstep systems were essentially done in the player pawn using ye olde DECORATE definitions too. However, they were far more clunky/primitive than a proper ZScripted solution.
Anyway, I'm just musing to myself really, but the basic tools might already be there. A more advanced footstep system is not in GZDoom already, but it does seem like the kind of thing that might be doable via ZScript. Of course, it would be a reasonably involved task, and not for everyone (certainly not for someone with my limited ZScript skills), and I totally get that a system where you could add a few properties to the player pawn to easily access existing code would be far more modder-friendly, but - with a bit of work - something could be doable.
I also like the idea of being able to add bigger splashes, or actor/impact-type specific splashes. Again, it wouldn't surprise me if that was also doable via ZScript.
The more I think on this, the more it seems like it could probably be best as a "third party" footsteps library than something built-in to the engine release (like several libraries and "starter kits" that already exist for other things). The existing stock system fixes/enables what was there already and provides limited expansion (and that's all it was intended to do). Doing more seems like the territory of a bolt-on library mod to me. Of course, that would require someone with the time and skills to be willing to create one (as, indeed, would adding it to the engine).
But, like I said, that's all just me musing and carries no weight whatsoever.
For me, what we have right now covers my needs: I only have one Doom-like player pawn and putting stuff in TERRAIN by building on the older is a convenient, and relatively easy way to do what I want. But, I guess that's the problem you're facing: it's a simple system built on to the existing TERRAIN stuff. To be fair, it seems like that's what it was intended to be.
I'm not saying "it works for me, so it doesn't need to be better"; simply that I'm lucky that (with a minor change - that took me far too long to figure out) I can use the system that exists to do exactly what I want, and I think I'm using it more-or-less in the way it was intended (i.e. as a base for my mod).
However, I totally see your points; particularly in a game where different player pawns are going to be used. There does, of course, need to be some way to define "this is a rocky surface and it makes a hard sound, this is gravel and it makes a crunchy sound, this is mud and it makes a squelchy sound" etc, and TERRAIN seems to be the logical place for that. Part of the consideration would also be the fact that some PlayerPawns will make different sounds depending on who/what they are - so that needs to be covered too, perhaps being able to add class identifiers to the sounds for a TERRAIN makes sense:
[code]
terrain Whatever
{
...
StepSounds.fighter floor/fighter/tile
StepSounds.cleric floor/cleric/tile
StepSounds.mage floor/mage/tile
}[/code]
Or something?
But, yep, speed/frequency of footsteps and so on make sense to be in the PlayerPawn. I never thought about it when I was doing my stuff (because it wasn't on my radar for what I was trying to achieve), but tying how fast footsteps are to the terrain definition does seem limiting - especially for a multi-class game, because all player classes, regardless of type, always make the same sounds with the same frequency. There's certainly a big difference between an armoured beast of a fighter stomping across the land in full plate mail versus a ninja-like player tip-toeing across the same ground in a pair of tabi. However, some kind of "this terrain has a multiplication factor of X" for slowing/speeding up footsteps might have some mileage?
All that being said, a lot of the handling is actually in the player definition. If you look in player.zs in GZDoom.pk3. That's where I found the code that I modified to remove the forced always splashing on liquid surfaces, and I added my modified code to my player definition to override the default. So, perhaps what you are looking for is tailor-able to your needs (or to be closer to your needs). Perhaps you could look at what is needed and put different, relevant code in each of your player pawns? I don't know enough about ZScrip handling to say whether that is workable or not.
Some of the really old footstep systems were essentially done in the player pawn using ye olde DECORATE definitions too. However, they were far more clunky/primitive than a proper ZScripted solution.
Anyway, I'm just musing to myself really, but the basic tools might already be there. A more advanced footstep system is not in GZDoom already, but it does seem like the kind of thing that might be doable via ZScript. Of course, it would be a reasonably involved task, and not for everyone (certainly not for someone with my limited ZScript skills), and I totally get that a system where you could add a few properties to the player pawn to easily access existing code would be far more modder-friendly, but - with a bit of work - something could be doable.
I also like the idea of being able to add bigger splashes, or actor/impact-type specific splashes. Again, it wouldn't surprise me if that was also doable via ZScript.
The more I think on this, the more it seems like it could probably be best as a "third party" footsteps library than something built-in to the engine release (like several libraries and "starter kits" that already exist for other things). The existing stock system fixes/enables what was there already and provides limited expansion (and that's all it was intended to do). Doing more seems like the territory of a bolt-on library mod to me. Of course, that would require someone with the time and skills to be willing to create one (as, indeed, would adding it to the engine).
But, like I said, that's all just me musing and carries no weight whatsoever.