Volume argument for ambient sound things

[Enjay]

I don't *think* this exists.

I know that sounds can have volume set in their SNDINFO definitions, and there is also the $volume SNDINFO command. Sometimes, however, it would be more convenient, rather than having to create a new sound definition (with a new number and so on), to be able to set an arg on the sound thing in a map to modify its volume. I suggest that 1-127 be quieter than normal and 129-255 to be louder with 0 and 128 being unaltered.

With this, it would be possible to place the same sound in a map several times with different volumes, or in different maps or whatever, whilst only ever placing the same sound thing object. The various ACS ways of playing sounds have volume arguments but not the map placeable ones.

And, I suppose, whilst I'm in this vein, perhaps further arguments could be used that would be analogous to the $rolloff SNDINFO command for modifying attenuation on the sound things.

[NeuralStunner]

A splendid idea.

[randi]

Added all of it. (volume, min distance, and max distance)

[Enjay]

Excellent. Thank you.

[Enjay]

Code: Select all

*Third argument: Minimum distance before volume fading starts.
* Fourth argument: Maximum distance at which the sound is audible. 

Can I ask how the third and fourth arguments were handled? I've tried to read the code, but couldn't make sense of it.

If these are map units, then that seems somewhat limited (ahem) seeing as how the biggest number possible is 255 in ZdoomHexen format.

If it isn't already this, how about handling it like the quake-effect units ( ie value x 64)?

[Gez]

If these are map units,

They are.

then that seems somewhat limited (ahem) seeing as how the biggest number possible is 255 in ZdoomHexen format.

UDMF, baby!

I know, I know. There's only one map editor that supports UDMF at the moment, and it's not your favorite. But, not everything is lost anyway! You can always define new actors and use [wiki=Actor properties#Args]this[/wiki], or maybe [wiki=A_SetArg]this[/wiki], or maybe even through ACS with [wiki=SetThingSpecial]this[/wiki].

[Xaser]

Why cripple the older formats? I don't see any reason why such precision is needed, really -- units of 64 (or even 32 if you want to be a little more precise) would work better, IMO. Even in UDMF, dealing with long distance sounds would get really annoying when using individual units.

[Graf Zahl]

If these are map units, then that seems somewhat limited (ahem) seeing as how the biggest number possible is 255 in ZdoomHexen format.

You will have to accept the fact that as time progresses, more and more features will be added that require UDMF to be fully exploited. After all, getting rid of these crippling limits was one of the main motivations to implement UDMF in the first place.

Why cripple the older formats? I don't see any reason why such precision is needed, really -- units of 64 (or even 32 if you want to be a little more precise) would work better, IMO. Even in UDMF, dealing with long distance sounds would get really annoying when using individual units.

Why hang on stubbornly to the past? Let's face it: The old binary formats have some serious shortcomings and there's already far too many hacks in the engine to get around them. That time is over. In my book UDMF is the future and will be considered the primary map format new features will be designed for. If they can be made to work with ZDoomHexen, fine. If not, well, pity - but it wouldn't stop me from implementing them anyway.

[randi]

If it isn't already this, how about handling it like the quake-effect units ( ie value x 64)?

If I did that, then I would lose precision with Blood's ambient SFX. (To be honest, being able to load up a Blood map and hear the ambiance was my ulterior motive for implementing this.)

However, since the final argument was still unused, I can make it a scalar for the distances. Then you can set it to 64 and get what you want. (Unless somebody else thinks there should be a better use for it.)

[Graf Zahl]

Well, I think that a setthingspecial call to set the args would have been enough for those who still use those outdated map editors...

[Enjay]

Well, I think that a setthingspecial call to set the args would have been enough for those who still use those outdated map editors...

Outdated map editors?

Better, merely missing one feature but containing far more, map editors (IMO of course).
OK, OK, so the one feature is a big one but meh...

Randy's suggestion sounds (ahem again) good to me.

[edit] And I see that it is already in. Thanks. [/edit]

[Gez]

Outdated map editors?

Better, merely missing one feature but containing far more, map editors (IMO of course).

Editors that should have been open-source so that the missing feature could have been added to it by now. IMO of course.

Heh, the "normal" value has been changed to 100, but the source comments still say 128.

Also, question: if "50 is a typical value for Blood levels", doesn't that mean that then 50 correspond to normal, and 100 to double?

[Enjay]

As a side question, if all this effort is being made to make certain parts of Blood easier/better to load in Zdoom, does it have a wider implication for perhaps eventual Blood support or is this merely to enhance Doom engine game support.

[Graf Zahl]

Better, merely missing one feature but containing far more, map editors (IMO of course).

One feature?

Better make that 'the future of ZDoom editing' which is missing!

And as Gez said, both of the editors left in the dust have one thing in common: They were sold to rip off a community which lives from free content. And of course the fact that both programmers have left for good as it seems.


So far there hasn't been much that's UDMF only except for seriously improved mapping convenience but sooner or later some new features will actually require UDMF.

[randi]

Also, question: if "50 is a typical value for Blood levels", doesn't that mean that then 50 correspond to normal, and 100 to double?

No, you often don't want a background sound to play at full volume. I assume 100 is full volume in Blood, since it's a convenient number for digital users to work with and 50 is exactly half that.

does it have a wider implication for perhaps eventual Blood support or is this merely to enhance Doom engine game support.

For fun. That's the reason the Build loader is there, too. Blood does seem the best suited for ZDoom support, since it's much better structured than the other Build games, but I wouldn't hold my breath waiting for anything that could be considered "support".