Door movement sounds on open and close

[SneaksieDave]

Couple of door sound questions:

 

1. What is the correct way (or a clever one) to set up a door to have sounds that play upon start of movement in both the open and close directions? Currently it seems snd_open does this for opening, but snd_close doesn't play on start of movement but rather end of movement (upon closing). Great for a KLUNK! closing sound, but not for a movement/scraping/whatever sound.

 

Devs: if this is currently not supported, can it be? Pretty much a needed property. I might just be missing the correct way though...

 

2. If such sounds are longer than the actual door movement, the sound doesn't cut off properly; instead it keeps playing for the full length, even if the door is open/closed. Limitation, or am I missing the proper way to implement it? I'm sure it can be scripted, but this should be proper canned behavior.

[SiyahParsomen]

That's same the problem while I was making doors of cells in my old map. Thanks to button, door has a sound on both opening and closing. It plays the sound file on closing reversely. Besides, you should be careful on duration of the sound and movement of the door. Check the attachment for better understanding.

Edited July 15, 2010 by SiyahParsomen

[grayman]

The closest you can get with what's currently available is to use snd_move. This sound will play when the door is opening and when it's closing. The drawback is that it's the same sound both ways. For a squeaking/scraping door, that's okay.

 

If you get into scripting, then you can keep track of whether the door is open or closed with frob stims, and play a sound when an open door is frobbed. I don't know if there's a boolean test like $doorname.isOpen() that could be used instead.

 

Door events aren't symmetric. We have this problem with sounds, and there's also a problem with triggers. You can trigger something when a door begins to open, when it's fully opened, and when it's fully closed. But you can't trigger something when a door begins to close. If we had that, then you could trigger your closing sound with it.

 

 

 

 

[Fidcal]

Another workaround might be to frob_peer the door to a hidden button or even a hidden door with a very short open/close movement.

[SiyahParsomen]

The closest you can get with what's currently available is to use snd_move. This sound will play when the door is opening and when it's closing. The drawback is that it's the same sound both ways. For a squeaking/scraping door, that's okay.

 

If you get into scripting, then you can keep track of whether the door is open or closed with frob stims, and play a sound when an open door is frobbed. I don't know if there's a boolean test like $doorname.isOpen() that could be used instead.

 

Door events aren't symmetric. We have this problem with sounds, and there's also a problem with triggers. You can trigger something when a door begins to open, when it's fully opened, and when it's fully closed. But you can't trigger something when a door begins to close. If we had that, then you could trigger your closing sound with it.

 

 

 

Checked the prefab again and I may wrong on playing the sound on closing reversely. Anyway, snd_move is shortcut instead of using frob_peer with a button.

[SneaksieDave]

Yep @what grayman said. And it could no doubt be done with script.

 

The button method in the map above suffers the problem where if the player frobs again during mid-movement the sound replays, so you can get multiple movement sounds playing overtop one another.

 

An 'acceptable' method is to use the snd_move property for movement scraping, and then 'silence' out the snd_open and snd_close. It's far from ideal, but the sounds are handled lopsided -- open plays from the start, and closed plays from the end. Both should play from start of movement. The problem this creates is while an open sound can include pre-scrapes and then a klatch at end, the close movement cannot have scrapes at the beginning with a klatch at end... because the whole dang sound plays once the door stops!

 

You can have a stand-alone klatch at end of close, with a _move scrape... but then what about the open sound? Ugh.

 

Maybe I'll submit an issue and see if anything comes of it. This really should be pre-canned behavior.

[Tels]

Hm, if "snd_close" is player _after_ the door closed, we should probably leave it add "snd_onclose" (or something along these lines) which is played from exactly "-X ms" (where X is the length of the sound in ms) before the door would close.

[SneaksieDave]

Yep. That's certainly preferable to using snd_move and (klatch-only) snd_closed sounds (some exist, more needed), in conjunction with a code change to snd_open to make it also play only klatch (or whatever) sounds at end of open (sounds needed).

 

[Komag]

The current sound timings are useful and good, so it just sounds like we need more options added as well, not necessarily to change the ones that already exist

[SneaksieDave]

It's actually only good for the default doors. If different sounds are needed (metal portcullis, stone door...) we're lacking there (flexible useful sounds). And if those doors need sounds at end of open and start of close, we're lacking (code). If the user wants scrapes, they're further at a loss, unless those sounds exist (sounds), not to mention they'll overlap with open and close sounds, if the code doesn't support a fix for that (code). And the open/close sounds only work if they are of the exact right length for the door movement (code, sound).

 

We could go the route of having "smart" doors, which require code changes:

 

* snd_open plays from start (already works, more sounds needed)

* snd_move not needed

* snd_close plays from start of movement toward close (needs coding, more sounds needed)

 

(of course there could also be sounds at end of open and start of close...)

 

 

Or simply get a bunch of new sounds which support the existing model:

 

* snd_open plays from start (already works, more sounds needed)

* snd_move plays during the movement (already works, more sounds needed)

* snd_close plays when door stops moving (just the klatch; already works, more sounds needed)

 

I favor the second method, as it is most flexible for the mapper. You can have a silent open if you wish, or a silent close if you wish, or a silent move if you wish. The other method isn't so flexible and is IMO messy.

 

However, both methods have significant legwork in the way:

 

Method one requires coding. How likely that is to happen, you'd have to ask programmers.

Method two requires a sound department. Good luck with that.

[Baddcog]

As far as sounds for doors goes I was thinking that a different sound for chest lids would be nice. If nothing more than to mix it up a bit (door sounds do get repetive).

[PranQster]

Would it be possible to add a speaker, triggered by the door mover, but only when the door closes and not triggered when the mover opens?

Perhaps using 'trigger_on_close' '1' and 'trigger_on_open' '0' to trigger the speaker?

I suppose that would mess up anything else which gets triggered by the door mover.

 

How about cloning the door/mover, putting it either out of sight or use 'nodraw' and use that one with 'trigger_on_close' to trigger a speaker with the desired sound? Then the main door can be used with its assigned open and closed sounds and even have a speaker for its sound while in motion if needed, yet have a custom sound which only triggers when the door starts to close.

 

OOOPS... I just read the tooltip for 'trigger_on_close', and it is the one which triggers when fully closed. Doh! I should know that, I used it in my test map twice already.

Edited July 17, 2010 by PranQster

[grayman]

My brain just blew up.

[SneaksieDave]

The more I worked with it and thought about it, the more I think having separate start-of-open, movement, and end-of-close movements is, while not ideal, the combination of best and easiest. It already works this way, just needs proper sounds (of which we don't have many at the moment). So, more a sound issue than one of code.

[OrbWeaver]

The more I worked with it and thought about it, the more I think having separate start-of-open, movement, and end-of-close movements is, while not ideal, the combination of best and easiest.

 

As far as I remember this is what the original games did (which is what I always consider when in doubt).