Strider's mapping thread

[Baddcog]

Not really sure about your post there Fid, you alright? lol.

 

--------------

Visportals WITHOUT a door do help lead sound through that doorway.

 

Glass - see thru textures do not block vision/sound.

 

You can put a portal at the glass, and you CAN set location entities there, and they will work for the sound locations (in the street outside the glass you play street.ogg, inside the building on other side of portal you play ambient01.ogg.)

That's what sound locations are for, defining boundries of ambient sounds by location.

 

-------------

What I was saying is windows (that are transparent) will NOT block sound no matter what. Unless you force the portal closed. In which case you won't have a transparent window anymore.

 

Sound locations work just fine.

 

Sound attenuation settings DON'T work at all from the work I did following Wiki instructions and when working on that map it was raised with team and it couldn't/wasn't fixed as far as I know.

 

---------

It would be nice to be able to set attenuation so transparent windows would act 'solid' as far as sound goes, and the Wiki makes it seem like they will, and I guess in theory it should work.

 

But it doesn't.

[Strider]

Yeah. Bummer. Like I said though, I seem to recall such sound loss occurring at various points in vanilla D3, although it's been a long time since I've played through it. And I've played Dead Space much more recently, which has similar visuals/ambiance and might have a working system for said sound loss. Maybe that's what I'm thinking of.

 

Any recommendations on how to work around this issue then? I've a speaker rather close to the glass that's fairly loud... Is the only solution just to find a happy medium with volume/speaker placement?

[Fidcal]

So are we saying then that the sound location entity control method only works if a visportal is closed? It does not work if the player is just further along a street past an open visportal?

[Strider]

The info_locationseparator works for location settings (i.e. ambient sound and light) regardless of whether portals are open or closed, but it apparently cannot be used to cause sound loss between two areas through a transparent brush. The wiki page called Sound Propagation Page 1 should probably be edited to reflect that, since that's where I found the instructions for setting it up.

 

I still don't think I understand what the "func_location_separator" is, though, and how it's different from the info_locsep. It's referred to in step 3 of those instructions.

[Fidcal]

In that case I don't believe it. I am certain you can have a glass window as I've previously described. Look at it this way:

 

Create an area with two doorways both with visportals and set up using the location entities to control the sound sso there are ambient sounds within that area and outside. Are we agreed that this works whether the visportals are open or closed?

 

Now place a tiny glass brush the size of a thimble in one doorway not touching the visportal. Are we agreed it cannot possibly have any effect on how the sound is controlled?

 

Now enlarge the glass brush as big as you like so long as it doesn't completely fill the doorway nor touch the visportal. Are we agreed it doesn't matter at all how big this brush is so long as it does not completely seal the doorway and does not touch the visportal? If it leaves a tiny gap the doorway is not sealed. In fact that gap could be a wooden func_static post to fill the visible gap. The visportal of course must not rely on it but must have worldspawn on all sides.

 

You now have a window. I rest my case again. Furthermore I predict that if you make that glass brush a func_static you can completely seal that doorway and it probably does not matter at all if it touches the visportal either.

[Tels]

Not really sure about your post there Fid, you alright? lol.

 

--------------

Visportals WITHOUT a door do help lead sound through that doorway.

 

Glass - see thru textures do not block vision/sound.

 

You can put a portal at the glass, and you CAN set location entities there, and they will work for the sound locations (in the street outside the glass you play street.ogg, inside the building on other side of portal you play ambient01.ogg.)

That's what sound locations are for, defining boundries of ambient sounds by location.

 

-------------

What I was saying is windows (that are transparent) will NOT block sound no matter what. Unless you force the portal closed. In which case you won't have a transparent window anymore.

 

Sound locations work just fine.

 

Sound attenuation settings DON'T work at all from the work I did following Wiki instructions and when working on that map it was raised with team and it couldn't/wasn't fixed as far as I know.

 

---------

It would be nice to be able to set attenuation so transparent windows would act 'solid' as far as sound goes, and the Wiki makes it seem like they will, and I guess in theory it should work.

 

But it doesn't.

 

I think this would be a bug then (or a not-yet-implemented feature).

 

The sound_loss is *only* set on the portal when you have a info_locationSeperator entity touching the portal. Here is what the code does:

 

 

void idLocationSeparatorEntity::Spawn()
{
   idBounds b;
   float SoundLoss;

   b = idBounds( spawnArgs.GetVector( "origin" ) ).Expand( 16 );
   qhandle_t portal = gameRenderWorld->FindPortal( b );

   if ( !portal )
   {
       gameLocal.Warning( "LocationSeparator '%s' didn't contact a portal", spawnArgs.GetString( "name" ) );
       goto Quit;
   }
   gameLocal.SetPortalState( portal, PS_BLOCK_LOCATION );

   // update the sound loss for the associated portal (Note sound loss must be positive)
   SoundLoss = spawnArgs.GetFloat("sound_loss", "0.0");
   gameLocal.m_sndPropLoader->SetPortalLoss( portal, idMath::Fabs(SoundLoss) );

Quit:
       return;
}

 

So:

 

* no portal => no sound loss

* no info_locationSeperator => no sound loss

* portal open => no sound loss

 

This all can be changed, we can add a new entity spawn class that does nothing but set the sound loss for the portal, and I think we can also change it so that you have two different sound losses, one for open and one for closed portals.

 

Please file a tracker entry.

 

Since I need to look into the portals for the local ambient lights anyway, I can also look into this.

 

Edit: As a workaround, you can use a script event to set the sound loss on the portal to a fixed value (although I have no idea how you get the handle of the portal):

 

void idThread::Event_SetPortSoundLoss( int handle, float value )

{

gameLocal.m_sndProp->SetPortalLoss( handle, value );

}

[Tels]

I still don't think I understand what the "func_location_separator" is, though, and how it's different from the info_locsep. It's referred to in step 3 of those instructions.

 

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

[Strider]

Now enlarge the glass brush as big as you like so long as it doesn't completely fill the doorway nor touch the visportal. Are we agreed it doesn't matter at all how big this brush is so long as it does not completely seal the doorway and does not touch the visportal? If it leaves a tiny gap the doorway is not sealed. In fact that gap could be a wooden func_static post to fill the visible gap. The visportal of course must not rely on it but must have worldspawn on all sides.

 

You now have a window. I rest my case again. Furthermore I predict that if you make that glass brush a func_static you can completely seal that doorway and it probably does not matter at all if it touches the visportal either.

 

If I'm understanding you correctly, I've tried this a couple of times -- visportal across the opening, info_locsep piercing visportal, transparent brush also across opening but touching neither the visportal nor the info_locsep. It still does not block sound, even in the most very basic test map I could set up.

 

Wait... are you saying that the transparent brush should not fully seal the opening, in addition to not touching the visportal or the info_locsep? If that's the case, I shall give it a go immediately, and I'm sorry I've been missing your point -- it just seems very counter-intuitive .

 

But I think, as Tels says above, the issue is the portal being open, not whether the opening is sealed completely/properly.

 

 

I think this would be a bug then (or a not-yet-implemented feature).

 

The sound_loss is *only* set on the portal when you have a info_locationSeperator entity touching the portal. Here is what the code does:

 

 

 

So:

 

* no portal => no sound loss

* no info_locationSeperator => no sound loss

* portal open => no sound loss

 

This all can be changed, we can add a new entity spawn class that does nothing but set the sound loss for the portal, and I think we can also change it so that you have two different sound losses, one for open and one for closed portals.

 

Please file a tracker entry.

 

Since I need to look into the portals for the local ambient lights anyway, I can also look into this.

 

Edit: As a workaround, you can use a script event to set the sound loss on the portal to a fixed value (although I have no idea how you get the handle of the portal):

 

I've definitely been using the info_locsep, and it is definitely functioning properly regarding ambient sound and light. It would be absolutely splendid if someone could instruct me as to how I can set up that script event, because in this particular situation the lack of sound loss between these two rooms seems very bizarre in-game. The transparent glass is, in this case, vital to what I'm trying to do.

 

Also, where do I put a tracker entry, and what info is it necessary to supply?

Edited September 17, 2010 by Strider

[Tels]

I've definitely been using the info_locsep, and it is definitely functioning properly regarding ambient sound and light. It would be absolutely splendid if someone could instruct me as to how I can set up that script event, because in this particular situation the lack of sound loss between these two rooms seems very bizarre in-game. The transparent glass is, in this case, vital to what I'm trying to do.

 

Also, where do I put a tracker entry, and what info is it necessary to supply?

 

http://bugs.angua.at/my_view_page.php

 

You might need to request an account before you add an entry, tho. As for the info, I think linking back to this thread is enough.

 

I am still on vacation so I might not be able to reply before the 20th.

[Strider]

Consider it tracked.

[Baddcog]

The glass has no effect whatsoever on sealing/open/closing the visportal.

 

It can be worldspawn or func_static. It has NO effect (I swear I already said this),

gaps, no gaps, NO EFFECT.

 

That's what the location info - soundloss prop is SUPPOSED to take care of. It doesn't.

 

A new entity probably would be best Tels. That allows authors not using location settings to block sounds with a window. (and even with a func_static window or model window)

[Strider]

Agreed. I had to hold out hope, though.

 

Now, can anyone describe for me how to implement that workaround Tels was talking about? I haven't messed around with any scripting yet, so the most basic explanation of the process would be much appreciated .

[Fidcal]

I'll take a look at it but I might not have time tonight and tomorrow as I've got visitors but I think I could use this script myself for something. So unless someone comes up with a script before me then I'll probably find time on Sunday.

 

Looking again at this I thought you were using the atdm:location_settings method. Looking at your post again I see you are using the old method. That is why I couldn't understand what difference the glass could make. In fact I just tried it and it doesn't.

 

The new method described at http://wiki.thedarkmod.com/index.php?title=Location_Settings works but the problem is that it is time-based rather than distance based. So you can have silence in Room 1 and no sound comes through the window. Go through the door and the sound starts up after a time set by the mapper. When you leave it fades out again at a time set by the mapper. This is only really suitable for ambient effects like music or atmosphere not say, a machine. So if you step just outside of the machine room door then the machine noise continues but then fades to silence after N seconds. But if ambient music is what you want then try it.

 

Set up your window as a func_static and put a visportal in the window frame and in the door. Put an info_location_separator in both visportals (not sure if only one will do.) Then follow the wiki article.

 

But if you want the sound to partly come through the window and/or door, eg, a machine noise, then wait for the script.

[Strider]

Yes, machine noise coming from a speaker is what I'm using -- I'm already using some ambient music in both rooms, and that's working just fine. This might not be such a critical issue except for the fact that the speaker from the machine is, necessarily for this situation, very close to the glass separating the two rooms.

 

I shall therefore wait for help with scripting. Thanks in advance, Fidcal!

[Baddcog]

You can probably just move the speaker away from the machine. Just adjust the inner/outer radiusus and position accordingly. Not always the best option, but if the radius' aren't too large it should work fine. Even if the fade ut goes through the wall it would still be fairly realistic, a noisy machine would probably still be heard a little bit on the other side of a window anyway.

Might not fade off as much as you want...

 

But AI on either side will still not be muffled.

 

Sounds like the Tels script would require knowing the name of the portal to target it, but how?

[Strider]

I might adjust the speaker as a temporary fix, but the script looks like the best option. There's got to be some way to locate a specific portal, right? Or can you name them somehow in the editor to make them easier to find?

[Fidcal]

A visportal is just worldspawn. I'm guessing the info_location_separator entity name will identify it in the script.

[Strider]

That would certainly be convenient

 

Quick question in the meantime -- can I get a brief rundown on how to set up a glowing window texture? The wiki instructions assume I know how to write and use a .mtr file, which I don't. For example, I want to add a moonlit sort of glow to "roundtop_diamond_pattern01_grey_moonlit".

[Fidcal]

Briefly:

If you know nothing about materials you need to study the wiki or google to get a basic understanding.

 

Find the pk4 with the mtr files and extract the one you want

Copy that definition to a new file in materials folder & name it eg, mymap.mtr

Edit it in a plain text editor

Add a stage eg,

 

	{
       	blend       add
	map     textures/darkmod/window/diamond_pattern01_self_lit
       	rgb         1
}

 

Ideally you should convert the dds diffusemap file to tga and give it more contrast in a paint program so the frames are darker otherwise they might seem too bright.

 

The rgb value determines how bright it will be range: 0.00 to 1.00

[Tels]

A visportal is just worldspawn. I'm guessing the info_location_separator entity name will identify it in the script.

 

No, not really. Each portal has a handle, which is some sort of internal number. However, so far, I see no real way to actually find out the handle of the portal so you could call the script event.

 

The only comment I can find is:

 

Handle must be greater than zero and less than the number of portals in the map

 

However, which portal has which handle is something you don't know.

 

I think it might be possible to add another script event, that goes along the lines:

 

float handle;
handle = sys.getPortalHandle("portal_name_here");

 

where "portal_name_here" is the name of the portal that you set via the info_location_separator as a spawnarg. (That of course makes it nec. that the info_location_separator stores that name somewhere so we later can look the portal number based on the name. Another way would be to add such an event to the info_location_separator entity, so you can do:

 

 

float handle;
handle = $location_entity.getPortalHandle();

 

where "location_entity" is the name of the info_location_separator entity (as you named it in DR) and it simple returns the handle of the portal it touches.

 

Please file a tracker entry for this issue (how to get the handle of a portal for script events), too. Even if this functionality already exists, we need to document it on the wiki/in the code, as the current script event is unusable..

[Tels]

Strider:

 

Please try the following spawnarg:

 

"editor_var sound_loss" "Soundprop: Loss incurred when a sound travels through this portal. Cumulative with door loss if a door is present."

 

On a info_location_separator entity that touches an open visportal (e.g. on a bit behind a glass pane). If I read the comments correctly this should be a positive number (probably DB? Try values between 1 and 30) and set the sound loss on the portal in addition to a door, e.g. also when the portal is open/closed.

 

If that works, it should solve your problem. I'll add the storage of this data and the script event, anyway, because I need this for light loss calculation, too.

[Tels]

Strider:

 

Please try the following spawnarg:

 

 

Hm, even if this works, it will not work in combination with a door:

 

void CFrobDoor::UpdateSoundLoss()
{
   if (!areaPortal) return; // not a portal door

   CFrobDoor* doubleDoor = m_DoubleDoor.GetEntity();

   // If we have no double door, assume the bool to be "open"
   bool doubleDoorIsOpen = (doubleDoor != NULL) ? doubleDoor->IsOpen() : true;
   bool thisDoorIsOpen = IsOpen();

   // TODO: check the spawnarg: sound_char, and return the 
   // appropriate loss for that door, open or closed

   float lossDB = 0.0f;

   if (thisDoorIsOpen && doubleDoorIsOpen)
   {
       lossDB = spawnArgs.GetFloat("loss_open", "1.0");
   }
   else if (thisDoorIsOpen && !doubleDoorIsOpen)
   {
       lossDB = spawnArgs.GetFloat("loss_double_open", "1.0");
   }
   else
   {
       lossDB = spawnArgs.GetFloat("loss_closed", "15.0");
   }

   gameLocal.m_sndProp->SetPortalLoss(areaPortal, lossDB);
}

 

The code above sets the loss on door open/close depending on the spawnargs, but simply ignores the additional loss that should be used based on the spawnarg of the info_location_separator entity. Please someone file a bug entry on this.

[Strider]

Strider:

 

Please try the following spawnarg:

 

 

Just tried it; added the spawnarg "editor_var sound_loss" and values "15" and "30" to the info_locationseparator; tried it both with the visportal touching the glass and without, and didn't notice a difference no matter what the value. Unless there was something more complex you wanted me to do, that doesn't work either.

Edited September 18, 2010 by Strider

[Mortem Desino]

Get rid of "editor_var". That's info in the entity definition parsed by DR. "sound_loss" is the actual name of the spawnarg.

 

There are also more args (though largely associated with idMovers). loss_open and loss_closed. Those may have to be put on a func_portal rather than an info_locationseperator.

[Fidcal]

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.