Strider's mapping thread

[Tels]

I have no time today but briefly keep in mind that sound loss through a door visportal is fixed by a cvar. I suspect that was changed from sound_loss for a good reason so don't change anything in the code without more thought. I considered dynamically changing this value in game some time ago but decided it would be really bad.

 

The actual existing working code for a frobdoor does not consult any cvar, it uses the spawnargs set on the door to modify the soundloss of the portal when the door is opened/closed. And all I was saying is that a info_location_separator entity touching the portal has a documented way to modify this soundloss further, e.g. making the sound even more muffled. That works (as far as I can see) when there is no door touching the visportal, but as soon as a door touches the portal, instead of adding the two losses together, the door simply overrides it. Which is a bug (because either the documentation is wrong, or the code is wrong).

[Fidcal]

Mmmm... no time right now but I did try the cvar a few weeks ago and it changed the audible sound loss through doors OK. The spawnarg on the door only affected the propagated signal to the AI.

[Tels]

Mmmm... no time right now but I did try the cvar a few weeks ago and it changed the audible sound loss through doors OK. The spawnarg on the door only affected the propagated signal to the AI.

 

Ah. That means the spawnargs aren't documented properly, because from their descriptions or the code I cannot see whether they are for the player heard sounds, or for the sounds propagated to the AI. I don't even know if the original request talks about one or the other...

[Strider]

So... I'm wondering if there's any consensus on how I might be able to work around this problem for now.

[Fidcal]

No, there might be a complicated way of doing it by triggers but how important is it? I mean compared to say just removing the glass and putting in open bars so the sound is supposed to come through?

 

If it is absolutely important that the sound be diminished then it might be possible to rig up the door with the double lever method I devised (I'd have to find it) that would swap a loud speaker for a quiet speaker when the door is closed plus work in conjuction with a double optional invisible control objective to make sure you are out of the room! I can describe this but is it worth it?

[Strider]

Hm... tell you what, I'll mess around with volume, speaker placement, which shader to use, etc., and see if it can be managed without a whole system like you're talking about. The physical layout of the two rooms is unchangeable without detracting from the very reason they exist, but the invisible aspects (like speakers and such) can be more flexible. I'll see what I can do; planning on having the afternoon for mapping today, so I should know very soon. Thanks for working with me on this...

 

Edit: We've had a ton of rain here today, and I came home to find the ceiling leaking on the desk where I have my PC... so it may be a while before I can get back to the mapping. PC's fine and out of harm's way, though, so... crisis averted.

Edited September 23, 2010 by Strider

[Strider]

Okay, I think I can just make do with some tweaking of the volume and speaker placement. Would really have preferred the glass to just be able to block sound, but maybe sometime in the future that'll be possible.

 

Anyway, got a question about something I presume will be a pretty quick fix, I just don't know the correct spawnargs/triggers for it: I need to disable a particular switch under certain conditions. Here's the situation: I have a sliding door and an two-stop elevator in front of it, and the sliding door needs to be disabled while the elevator is in the "up" position, otherwise the door, if closed, will clip through the elevator, which obviously looks terrible. I've tried having another sliding door textured with "clip" or "player clip" come out of the wall and cover the switch while the elevator is up (using the trigger_on_leave spawnarg), but you can still frob the switch through that. I also fiddled with the "target_set_frobable" a little bit, but couldn't figure out how to get it working.

[Fidcal]

Drag a small clip brush around the switch origin; it doesn't need to 'fit' the switch just so long as the switch is clipping into the brush. Give that brush atdm:target_set_frobable then target it from some trigger to toggle it frobable or not.

[Strider]

Ah, that makes sense. I think I was using "nodraw" or something with the target_set_frobable entity. Thanks!

[Strider]

Is there a way I can increase an AI's visual acuity so that they will see the player regardless of how well-lit an area is?

Edited October 2, 2010 by Strider

[Fidcal]

Yes, on the AI increase the spawnarg value of acuity_vis from the default 100. If you check the 'show inherited properties' in Entity Inspector with the AI selected you will see various acuity_ spawnargs you can tweak. Just change the values.

[grayman]

Strider filed issue #2355 regarding sound loss through a transparent window.

 

I'm trying to understand how sound propogation should work through portals.

 

I built a long hallway and created a speaker at one end of it whose min/max distances were greater than the length of the hall.

 

I placed visportals every 64 along the hall, each with a func_portal with portal_dist = 256.

 

So as I walked down the hall away from the speaker, portals closed behind me. I didn't experience any dropoff in sound volume as the portals closed.

 

After a few tests with varying speaker distances and varying numbers of portals, I found that the point where the sound disappeared in each test was a function of how many closed portals there were between me and the speaker, and the speaker's distance settings.

 

It looks like each closed portal reduces the speaker's min/max distances. Note that if you're still w/in the min distance from the speaker, you're still going to hear the full volume of the sound.

 

The more portals that close between you and the speaker, the shorter the speaker distances become, until you finally reach the point where you pass the reduced min distance, and volume begins to fall off. When you pass the max distance, the sound is gone.

 

So when you shut a portalled door, and you hear a dropoff in the sound, or if the sound goes completely away, what's happening is that the min/max sound distances become smaller, and you've fallen into the space between min/max (less volume), or you're now beyond the max (silence). If you make the speaker distances really big, way beyond the room you're in, shutting the door isn't going to change the speaker volume, even though the portal closed, because the reduced min/max distances are still way larger than your distance from the speaker.

 

And info_locationseparators don't seem to affect sound dropoff at all.

 

I haven't looked at any code yet. I was just trying to understand current behavior. The key to fixing Strider's problem appears to be to make the info_locationseparators work the way we think they're supposed to work. If they're supposed to reduce sound volume on an open portal the way a closed portal reduces sound volume, I expect they'll be applying the same min/max reduction factor that closed portals apply. Then it becomes a matter of adjusting the sound loss to a value that makes sense for the scene.

[grayman]

Probably an old name or typo, please change the wiki.

 

 

Found it still broken, so I changed it.

 

I didn't say anything about sound_loss not working, though.

 

 

[grayman]

Since I see upthread that Tels is planning to do something for this problem, I won't do any further research.

[Tels]

Since I see upthread that Tels is planning to do something for this problem, I won't do any further research.

 

No, that was before I noticed that there is a mixup between sounds from AI => player, and from player => AI. Please continue

[Fidcal]

In that case I'l add my two cents FWIW. Not studied this in detail but this is what I think happens though I may just be confusing the issue.

 

On the speaker everywhere within the volume enclosed by s_mindistance is fixed at the max volume set at the centre.

The drop off through closed visportals just adds virtual distance so if it is still not greater than s_mindistance there is no audible change

Outside the distance determined by (s_mindistance - total drop off virtual distances) then the sound starts to fade (to zero when it reaches s_maxdistance.)

 

IMO what we really need is two new spawnargs on say the func_portal entity to set audible sound drop off. This is placed to cut the visportal surface and should be made to work optionally if the visportal is open or closed. The reason is, one use is eg, for a glass window the visportal must remain open; the other is to add to selected door visportals to give extra drop off, eg,

 

s_loss_open

s_loss_closed

 

defaulting to zero.

 

Note that the existing loss_open and loss_closed only affects the sound signal propagated to AI not the audible sound and AFAIK only works on doors not func_portals.

 

I need this myself in my own FM because the loss through doors is sometimes not enough.

[SneaksieDave]

It looks like each closed portal reduces the speaker's min/max distances. Note that if you're still w/in the min distance from the speaker, you're still going to hear the full volume of the sound.

I'd guess based on this that the noisemakers have/had(?) the min radius set too large, so they weren't being blocked by e.g. closed doors or rooms above your head. Might also explain hearing AI footsteps on separate floors.

[Strider]

Good to know. For now the problem is fixed in my mission just by shuffling speakers around and decreasing their volumes, but would be really cool to have that feature working in the future.

 

Not to derail the discussion, but... some of you might remember that I'm creating a set of objectives that includes: 1. read this letter, 2. re-seal this letter, and 3. hide it in a particular location.

 

Now, 1 is easy to set up, and I've got a nice chain of stim/responses going for 2 (apply heat stim to bowl of wax, dip ring into wax, touch ring to letter), but my issue is this:

 

I want #1 to enable #2, and #'s 1 and 2 to enable #3, but it just isn't working. I've set the enabling objectives in the Objective Editor according to the instructions on the Wiki, but when I test it I can still do them all out of order (i.e., hide the letter, then seal it, then read it, which makes absolutely no sense).

 

Further, I can't get the "item is in location" component to work on #3. Again, I've followed the instructions on the Wiki (set "objective_ent 1" on the letter, etc.), and I've even set up a basic test map to try to just get the system working, but no luck. Are there any common mistakes I might be making with this process?

[Fidcal]

Yes, the most common mistake is that even though the location entity is named info_location-something the 'item must be in info_location' is NOT the right component type. If you have that then change it to 'item must be in location' which is further down the list.

 

The first type is for areas defined by visportals and second defined by a clip brush.

 

It's hard to understand why the objectives can be done in any order without seeing it. Can you upload the map somewhere and pm me the url and I'll take a look?

[Strider]

It's hard to understand why the objectives can be done in any order without seeing it. Can you upload the map somewhere and pm me the url and I'll take a look?

 

Sure, will do ASAP, but I'm working all day tomorrow, so tomorrow evening most likely.

[Strider]

So this is bizarre -- was just testing it a bit, and even though I was apparently already using the correct objective component, it just decided to start working. So the item location issue seems to be solved, and it even seems to be recognizing the enabling objectives now, because the "place letter" obj won't complete unless I have both read the letter and sealed it.

 

However, the "seal letter" obj is still completing even if I haven't read the letter first. Would this be because it's controlled by a target_setobjectivestate rather than an actual objective component?

[Fidcal]

Yes. I've pm'd you a solution but I might as well post it here as well for anyone else:

 

The problem is that when we set the objective 'controlled by external script' all control is handed over to that so it forcibly sets the objective complete no matter what and enabling objectives have no effect. So Instead, do this:

 

Name the atdm:target_setobjective_state to Setobjective3

Create a trigger_relay and name it Obj3Relay

Create a atdm:target_changetarget and name it Addsetobjective3TargetToRelay

Change the seal stim response on the letter to trigger Obj3Relay instead of Setobjective3

On the read letter #2 objection put Addsetobjective3TargetToRelay in the completion target box.

 

Now, if you try to seal the letter before reading it then the relay is triggered but it has no target so nothing happens.

When you read the letter it adds target Setobjective3 to the relay.

Now when you seal the letter it goes through the relay and completes the objective.

The place letter objective seems to work OK.

[Springheel]

Might also explain hearing AI footsteps on separate floors.

 

AI footsteps (and vocals) have a mindistance of 1. I think all environmental sounds probably should, unless they're supposed to becoming from a large area (like a big machine sound or something).