4.14.1 Footsteps undesirable behaviour, maybe bug

[Enjay]

I have noticed a potential problem when using footsteps on a terrain that has both footsteps and a splash defined. The problem is, you get both sounds.
There is also a related problem with 3D bridges.

Test file attached.

StepTest.pk3

Just load it and start Doom2 Map01
Minimal required lumps are included.
To make things easier, there is no music on the map.

a)
To the right of the player start is a strip of FLOOR0_3.
This should play "misc/chat" as a footstep.
It also has a splash with "world/quake" set as a small sound and "world/spark" set as its main sound.

If you run along it, you hear "misc/chat" and "world/quake" playing with every footstep.
I don't know if this was intended, but I only expected to hear "misc/chat".
(If you jump up and down on it (without otherwise moving), you hear "world/spark", and only "world/spark" as expected. (i.e. you trigger the main splash sound))
(If you shoot it you hear "world/quake", and only "world/quake", as expected. (i.e. you trigger the small splash sound))
IMO the combined effect of footsteps and splashes playing is undesirable behaviour because it means that the small splash sound is being played with every footstep.
This means that you either:
● have to accept that the small sound will be made whenever you walk on this floor, as well as any (perhaps) quieter walking sounds you might want to allocate to the terrain (which are likely to be drowned out by the splash sound),
● or you forgo the small sound and leave it all up to the footsteps. However, that would mean that small items and bullet puffs hitting the floor will not make the small sound as they would with a splash sound allocated to it,
● or you forgo the footstep sound, and leave it up to the splash sound. This would allow small items hitting the floor to make a sound, but it has to be a sound that is acceptable as a footstep and not some other kind of splash/impact. Moreover, the footstep volume CVAR does not affect the volume of splashes, so the player would have no control over how loud such splashes are.

So, for example, you can't set up a liquid that: if you walk on it you get a quiet sloshy sound; if you shoot at it you get a small splash sound, and if you jump on it you get the big splash sound.

The bottom line is that a splash is a splash, and a footstep is a footstep. They have different purposes and a splash sound really shouldn't be getting played every time a footstep happens.


b)
On the left, just so that it can be tested on its own, is a strip of FLAT4.
This should play "misc/chat2" as a footstep sound.
It does not have a splash defined, so that's all you should hear. Jumping on it or shooting it will be silent.

c)
In the middle of the map there is a 3D bridge.
On the top surface, there is FLAT4.
The floor below the bridge is FLOOR0_3.

Expected behaviour: walk across the bridge and you should hear the "tick, tick, tick" of "misc/chat2".
Actual behaviour: walk across the bridge and you hear "misc/chat2" and "world/quake".

In other words, it is playing the footstep sound from the top of the bridge (correct behaviour) and it is also playing the small sound from the splash attached to the FLOOR0_3 flat below the bridge (not correct).

This was noticed in an actual map where a metal bridge crossed a pool of lava. As I walked across the bridge, I could hear the "clank, clank, clank" of footsteps on the bridge, and the lava sizzling with every footstep around 200+ map units below.


What I feel should be happening:
● When walking/running on a floor, only the footstep sounds should play.
● When a small item (mass <10) hits a floor, only the smallsound from any allocated splashes should play.
● When a big item (mass >10) hits a floor, only the main sound from any allocated splash should play.
● When walking on a 3D floor over a terrain, only the footsteps from the top of the 3D floor should be heard. The floor below the bridge should not be making any noises/splash sounds at all.

So, what I think is happening is that when you walk on a flat that has a splash allocated, the footsteps code not only generates the footstep sounds, but it also triggers the smallsound from any splashes allocated to the terrain - both when you walk directly on it and even if you are walking above it on a 3D bridge. How easy it is to stop that happening, I have no idea.

It took me a while to unpick what was happening, so I hope I have got it right, and I hope the above makes sense.


TLDR version.

1) If you have a splash and footsteps allocated to a flat, the footsteps sound for the terrain and the small sound from the splash will be played with every footstep. I feel that footsteps should be made when walking, and the small sound should only be heard for its original intent - when small things (mass <10 IIRC) hit the floor.
2) If a 3D bridge passes over a floor with that has a terrain allocated to it which has a splash, the small sound for that splash will be played, even though the player is not actually on that floor, but passing over it on the 3D bridge.

[Enjay]

I've just had a look at the ZScript for the footsteps.

I think this is probably the responsible bit - and it seems deliberate, but I wonder if the actual implications were unforeseen/unintended:

Code: Select all

		//Steps make splashes regardless.
		bool Heavy = (Mass >= 200) ? 0 : THW_SMALL; //Big player makes big splash.
		HitWater(CurSector, (Pos.XY, CurSector.FloorPlane.ZatPoint(Pos.XY)), true, false, flags: Heavy | THW_NOVEL);

I think that means footsteps will always trigger a splash, but unless the player is particularly heavy (>=200), only the small sound will be played. [Edit: yes, I just increased the player mass to 250 and got the big sound with every footstep as well as the actual footstep sound. Honestly, with actual splashes, that would be a major problem.]

So, playing the splash sound along with the footsteps may be intended, but (as mentioned above in my other post) that comes with several problems (not least of which is that the splash sound is outside the player's ability to control the volume - so they really should just be occasional "something hit the water" sounds, not annoying every-few-tics sounds).

So, the splashes always playing does seem to be intended but, IMO, it is very much undesirable.

Obviously, the 3D bridge problem is an actual problem. Splashes should not be getting made under a bridge as you walk over it.

I haven't tried yet, but removing the "Steps make splashes regardless" section should fix both issues.
[Edit: I just checked and, yes, it does.]

[inkoalawetrust]

The splash thing was intentional and done by me, since logically, taking steps in a liquid DOES make it splash.

Being able to trigger splashes on the floor below when walking on a 3D floor is absolutely a bug however. If I'm not busy working with other stuff tomorrow, I'll look into fixing it. Sounds like either SecPlane.ZAtPoint() isn't the right function to use, doing a quick glance at P_HitFloor(), I'll probably need to add a dedicated 3D floor check by the looks of it.

I MIGHT also make the "step = splash" default logic only apply on terrains actually marked as liquids. Not too sure about that though, even on a non-liquid terrain with splashes (i.e sand that gets kicked up when walking), being able to splash when walking over it makes sense. So that'll probably stay, since there's no way to add a control for it (Like a property or something) that creates unacceptable amounts of extra overhead compared to what it adds.

[phantombeta]

Sounds like either SecPlane.ZAtPoint() isn't the right function to use, doing a quick glance at P_HitFloor(), I'll probably need to add a dedicated 3D floor check by the looks of it.

It isn't the right function, yeah. You need Sector::NextLowestFloorAt instead.

[Enjay]

The splash thing was intentional and done by me, since logically, taking steps in a liquid DOES make it splash.

I understand the logic, and I can see why you did it, but it has potentially undesirable effects - if you have splashes and footstep sounds defined - it reduces the usefulness. I also disagree; taking steps in a liquid, unless you want to make a splash, makes it ripple, not splash.

IMO, they are separate things. Compare wading through knee deep water versus jumping into water. One makes a swirly sloshing sound, the other a big splash.

It's very possible to walk through even shallow water (e.g. puddles) and not make much of a splash (I was doing it today on a hike). If I'd jumped in the puddles though, I'd expect a splash.

Conversely, throwing or dropping something into water creates a splash, not a walking effect.

We have the capability in game to have both splashes and footsteps and, therefore, set up the game for things that should splash, and things that should make a "walking through water" sound. Forcing splashes for footsteps cuts down the options IMO.

Also, I find the constant splashes annoying.

However, if there was some way to optionally define a terrain as an "always splash with footsteps" terrain, we'd have the best of both worlds.

[Enjay]

Sorry, it was very late when I posted last night. All I was really trying to say is that necessarily tying footsteps to splashes is limiting.

e.g. it's impossible to set things up like this:

Small splash: small items being dropped into/hitting water (discarded clips, bullet casings, bullet puffs)
Big splash: player (and other heavy things) jumping/falling into water
Footsteps: wading through water

Also, the footsteps volume cvar doesn't affect splashes. So, if someone has turned that down a bit, splashes will still be loud.

And, personally, I don't like the player stomp-stomp-stomping through water, creating splashes with every step.

I really do appreciate the feature though, and your efforts in making it. It just strikes me as limiting to force a connection between the two features in a way that is not normally done in GZDoom.

Given that there is no way to create a property. How about two player flags? +PLAYERPAWN.MAKEFOOTSTEPS plus something like +PLAYERPAWN.FOOTSTEPSSPLASH; (or, conversely +PLAYERPAWN.FOOTSTEPSDONTSPLASH; if you prefer) then those could just be conditions checked in the ZScript?