Looping sounds not looping?

[Springheel]

I noticed there are a series of sounds called "machine_noise06_loop". However, none of them actually have the "looping" keyword in their shader, so if you just add them to your map, they'll play just once and the mapper will be left wondering why they are silent by the time he gets there.

 

Can anyone think of a reason not to add "looping" to the shader of sounds with "loop" in the name?

[grayman]

Someone's already used them in a non-looping situation?

 

Edit: And I thought mappers always had to use s_looping on the speaker, and that the "loop" in the shader name just meant that the sound was created so it could loop.

[Springheel]

Some loop automatically and some don't. And there's no way to tell without opening the sound shader.

[Bikerdude]

Can anyone think of a reason not to add "looping" to the shader of sounds with "loop" in the name?

Nope, sounds like nothing more than a typo.

[Springheel]

I wonder what the chances are of someone using a "loop" sound when they didn't actually want it to loop. It's a valid concern.

[demagogue]

I thought the speaker spawnarg overrides the soundshader argument, so the default is the soundshader unless the speaker sets something different. But I don't know, sounds fishy now that I think about it; if the spawnarg had an inherited value then it wouldn't work that way.

 

Edit: Sorry, of course it's more natural to think about it the other way around. The spawnarg sets it, then the soundshader can override it. But that would mean you can still set the spawnarg on the speaker to loop, like grayman said, and it should work (since it probably means the soundshader just doesn't have that value, I think).

[Springheel]

Yes, you can add s_looping 1 to make it work, it just seems odd that you should have to. But for compatibility I'll leave them.

 

Anyone know how to make a value show up in the entity window though? I know there's a way to force a spawnarg to be visible, and if we could force "looping" to be visible then that might be useful for mappers (though it's strange, because the spawnarg you use in the soundshader is "looping" but the one you use on the speaker entity is "s_looping").

[PranQster]

Edit: And I thought mappers always had to use s_looping on the speaker, and that the "loop" in the shader name just meant that the sound was created so it could loop.

And by "could loop", I see it as the sound was created with the ability to loop seamlessly, when set 's_looping' '1'...not that it would loop automatically.

LOL... I will not seriously propose changing the wording to "loop-able", but it is more apt.

But I will propose "loop_friendly"

Edited January 29, 2014 by PranQster