Sound question - re Visportals.

[NeonsStyle]

Hey,

 

Currently, my map WIP is yet to be visportaled (which I will do), however I've noticed something I like in the basement.

 

I know visportals cut sound, however the floor above the basement is a wood floor AI will be walking on. IRL, you would

hear the footsteps of anyone on the floor above the basement ceiling (underside of floor above), so I'd like to hear their

footsteps, but not their voices. Is this possible using Visportals or some other way?

 

It's the only area where it would make sense to hear footsteps on the floor directly above the player, however if

I understand visportals correctly, if I place one on the stairs dividing both floors, it will kill the sound of both footsteps

of AI and their voices. Is this correct? Is there a way to have just the footsteps?

 

If I understand correctly, if I place just one visportal on the stairs, and then visportal all doors (or double visportal

each side) entering the corridor above, then the sound from the corridor should transmit to the basement, but sound in any

rooms will not, correct?

 

Here's a pic.

 

 

 

 

 

Thanks

 

Ven

Edited October 1, 2014 by Venus

[SteveL]

Don't double-visportal in TDM. Use a single visportal in each doorway, and make sure the VP-textured face intersects the closed door.

 

Visportals don't kill sound, they determine the path it can go through. It's closed doors blocking a visportal that kill sound. So if you have an upstairs room and a staircase and a downstairs room, and there are visportals in the doors, then sound made in the upstairs room will have to travel through the doorway, down the stairs, and through the lower doorway to get into the downstairs room. If the doors are closed, then you probably won't hear anything at all by that route. That's realistic for most situations, but it doesn't handle the special effect of feet on wooden floors.

 

Without any VPs the sound will just come straight down through the floor. I'm not aware of any way to make a special case of footsteps I'm afraid: you can have voices and feet or neither.

[Melan]

Visportals don't distinguish between sounds.

 

Double VPs have an use, though, in increasing mission segmentation and properly channelling sounds. They may not always matter, but if you can get away with it, it is an effort well spent.

[grayman]

Your picture doesn't appear.

 

As mentioned above, visportals provide a pathway for sounds. Whether a sound reaches you or not depends on its propagation volume and the distance it must travel.

 

You might want to read this.

[NeonsStyle]

Ahh that's great... because the only sound in the corridor atm is AI's footsteps, but there's a wench in the kitchen

and visportalling the door will make sure she's not heard. Excellent.

 

Thanks Grayman, yeh I'm reading performance stuff atm, and the sound stuff was next on list, didn't have that link yet, so thanks for that.

 

Thanks as always. Much appreciated.

 

Ven

[OrbWeaver]

Double VPs have an use, though, in increasing mission segmentation and properly channelling sounds. They may not always matter, but if you can get away with it, it is an effort well spent.

 

In that example double VPs would benefit visual occlusion too, because the corridor is sufficiently long that many camera viewpoints in the room would not be able to see the distant portal through the near portal, resulting in the other side of the building being non-rendered.

 

Putting two visportals either side of a six-inch door would indeed be pretty pointless, however.

[SteveL]

Yes, for clarification I was talking about 2 VPs wrapping a single door. I've seen that technique in diagrams for T3 maps and thought that's what was being suggested, but whether or not it's useful there it's not in TDM.

[Obsttorte]

You could theoretically make the floor between the two floors a func_static, monsterclip it and place a tdm_nodraw_solid textured patch on top of it, so the correct sound gets played when walking on it. The you place a visportal there and place a func_portal entity in the vp with portal_dist set to zero, so the vp is always closed. You can set sound loss values to dampen the sound.

 

However, this will only affect volume at whole, not frequency dependent which would be more sufficient in your case.

 

Another way is to create dampened versions of the footstep sounds and a sound shader for it, aplly a scriptobject on all ai which checks whether the ai is in the upper room (the location system is quite useful for such situations) and if so place a sound emitter directly below the ai blewo the ceiling of the basement, playing the dampened footstep sounds.

 

Requires some work and testing, though

[Lux]

Or you can play a trick on the player. Since they can't physically see anyone above them but are aware there are people up there, you can just leave the hallway properly visportaled so sound comes down the stairs and in to the basement as it should and you could place 1 or 2 speakers playing the occasional footstep sounds with delay and set the audio really low on them. Then you'd only get footsteps and no conversation, the player could hear footsteps above them and when they moved up the stairs they'd be out of range of the speakers so when they saw the people upstairs, actual footsteps would match the AI movement.

[Obsttorte]

But if the player takes out all the ai in the upper room he would still get to hear footsteps in the basement

[Lux]

AH! Yeah, you're right :\ ... or can you remove individual speakers when linked AI die?

[SteveL]

Ingenious though, I like it. "Would the last person to drop please turn off the speaker?"

[demagogue]

Lux gave my answer, with one difference. Just put a trigger_multi brush in the upper room. When AI are inside the brush (as long as they're inside), then trigger the footstep sounds below. Make sure the brush is off the ground so KOd AI don't trigger it (unless KOd AI never trigger it, I don't know offhand.

 

Edit: IIRC Grayman added a script feature where a script can know when an AI is in a location. That'd be maybe easier or more robust (trigger_multis are fiddly with AI aren't they?), just have a script that plays footstep noises if an awake AI is in the upstairs location... if you don't mind a little scripting. Otherwise there's the trigger brush option.

[NeonsStyle]

Wow those are some great suggestions.

 

Only sounds that should be in the corridor are the AI guards, unless the wench is fleeing, which

she might if she heard the player below (which she does now, but once VP'd that should fix that.)

 

As for Double VP's on a single door, I saw a vid by Komag on his channel, where he talked of the benefits of double VP's over a door.

 

That corridor continues behind the player about the same distance, and there it turns right at 90 deg. I VP'd that corner, the bottom of

the stairs, the top of the stairs, and kitchen door (with the wench). I could not hear the wench, and could only just hear the AI guard

patrolling. When I could hear him, instead of the sound coming from above, it came from the portal on top of the stairs (which was

closed using r_showportals 1).

 

I might mess with some of these methods (as best as I can work out), and see if I can make his footsteps a bit clearer.

 

love the idea of messing with the player. lol

 

Thanks

 

Ven

Edited October 2, 2014 by Venus

[Obsttorte]

Lux gave my answer, with one difference. Just put a trigger_multi brush in the upper room. When AI are inside the brush (as long as they're inside), then trigger the footstep sounds below. Make sure the brush is off the ground so KOd AI don't trigger it (unless KOd AI never trigger it, I don't know offhand.

 

Edit: IIRC Grayman added a script feature where a script can know when an AI is in a location. That'd be maybe easier or more robust (trigger_multis are fiddly with AI aren't they?), just have a script that plays footstep noises if an awake AI is in the upstairs location... if you don't mind a little scripting. Otherwise there's the trigger brush option.

Trigger_mulit'S only response to the player, not to ai.

[grayman]

trigger_entityname can be used as a multiple trigger for a specific AI ("entityname/<AI name>").

 

There's no trigger that will recognize any AI.

[Tels]

trigger_entityname can be used as a multiple trigger for a specific AI ("entityname/<AI name>").

 

There's no trigger that will recognize any AI.

 

Er? Are you sure that:

 

	"anyTouch"    "1"

 

doesn't work? If not, that would definitely something we need to add to trigger_multi.

 

Incidentily, I'm using trigger_touch and was under impression, it responds to AI. If this doesn't either, then I'm screwed and need to do further fixes on the triggers. Why oh why didn't id just build a generic trigger entity and added lots of options to in, instead they build a dozend trigger entities, each of them can do something, but not others....</end of lament>

Edited October 2, 2014 by Tels

[grayman]

	"anyTouch"	"1"

 

I sit corrected. Never knew about that spawnarg.

 

The code is there to support it, but I've never tested it (obviously).

[Tels]

I sit corrected. Never knew about that spawnarg.

 

The code is there to support it, but I've never tested it (obviously).

 

To be fair, the spawnarg has an obscure name, and the documentation is not really clear, either. I admit, I never have tested it, nor knew about until a few weeks ago, either, just saw it during looking through the code, and used it, but before I could test it, changed to trigger_touch, which is a completely different mechanism.

 

Btw, just tested, trigger_touch reacts to AI An AI walking over my pressure plate properly triggers it (The AI wouldn't know what the plate does, so it can't use it to open doors, but that is what I need, so there

[NeonsStyle]

trigger_entityname can be used as a multiple trigger for a specific AI ("entityname/<AI name>").

 

There's no trigger that will recognize any AI.

 

Can you use this to make a specific AI go to a place? If so, then since it's specific to the AI name,

that means even if an AI of name say Roger, isn't triggered by a players action, he won't go

to that place?

 

Also, if the place is a path_corner, will he only go to that path_corner when triggered, and not

part of his normal patrol? Thinking of using this as one of my objectives.

 

Ven

[SteveL]

(The AI wouldn't know what the plate does, so it can't use it to open doors, but that is what I need, so there

 

If the pressure plate is a button, you might find they do use it. grayman taught them that trick in 2.02. If they don't figure it out automatically there's the "door controller" spawnarg. Although I guess they'd stoop to operate it by hand.

 

Can you use this to make a specific AI go to a place? If so, then since it's specific to the AI name,

that means even if an AI of name say Roger, isn't triggered by a players action, he won't go

to that place?

 

Also, if the place is a path_corner, will he only go to that path_corner when triggered, and not

part of his normal patrol? Thinking of using this as one of my objectives.

 

I don't understand question 1, but I think you can do (2) using a target_changetarget to make your AI switch paths.

[Tels]

If the pressure plate is a button, you might find they do use it. grayman taught them that trick in 2.02.

 

Hm, the pressure plate is a binary_mover (actually, it inherits from door). And it is not "connected" in the TDM sense to something, the triggering all uses its own (scripted) path, so you can have a much more complex system with "only once", "only 4 times", "only with a delay of 3 seconds" and so on. So, they probably won't use it.

 

If they don't figure it out automatically there's the "door controller" spawnarg. Although I guess they'd stoop to operate it by hand.

 

Since they only need to step on it, that would work. I'll see if the door controller is something I might add in a few cases. The intent is to have "dumb AI" like skeletons etc. that you can "trick" by having gates close in their face, let them fall down pits and so on. It would defeat the purpose if they knew about trap doors or floor pressure plates.

 

Thanx for the hint!

Edited October 3, 2014 by Tels

[grayman]

Door-controlling buttons are assumed to be on walls.

 

Anything on the floor would need to be tested, and might not work if the code can't provide the AI with a valid place to stand when operating the button.

[NeonsStyle]

I don't understand question 1, but I think you can do (2) using a target_changetarget to make your AI switch paths.

 

Well my plan was to have the player find a readable, then drop it in an AI's room, where it complete's an objective,

and that also triggers an AI to go to a specific room upstairs. Also, it would be up to the player which AI's room (out of 3)

to drop the readable, whichever he choices is the one that goes to this room, to complete the main objective.

 

Once he goes, the other two AI are not triggered so they stay where they are.

 

So I'll go look up triggers, but that trigger does sound like it would do the job. Thanks Grayman

 

The important part of it is that the player dropping the readable is what changes the AI's path. So he needs to be triggered.

[Moonbo]

Hey Venus,

 

Given that set up, it might be easier just to teleport the AI into the room, or remove the walking AI and then teleport a clone of the AI into the room (though you'd need to test that since teleportation has its own set of problems).

Edited October 5, 2014 by Moonbo