Play sound needs some work.

[Argh]

It's nobody's fault, that this is a pain. I'm sure Trepan didn't anticipate us wanting this particular wrinkle- we have all hated certain aspects of Spring's soundcode, and well... I was hoping this would be reasonably quick to get fixed, because the way it works in COB is not flexible, and shouldn't be changed, either. I'll come back to this when I have had a rest, I started reading about how functions work and stuff, so that I'll finally get a real handle on what to do and why, but I'm just too tired to absorb it right now.

[AF]

This isnt really a problem.

You havea a simple playsound API call and an api for everythign else needed.

Just build a library widget implementing the necessary functionality, changing the volume based on distance, filtering out sounds that are too far away from the edge of los to hear.

[Argh]

Just build a library widget implementing the necessary functionality, changing the volume based on distance, filtering out sounds that are too far away from the edge of los to hear.

<laughs> trust me, when I have better than a 50% chance of getting any given LUA hack to run, I'll be happy to take that on. However, I still suck at writing LUA, and I'm having lots of problems understanding how Functions are passing stuff around, so I'm still at the point where I'm not really writing new logic yet.

LUA's very alien to me- I haven't used any language except for BOS for over a year now, except for poking around at Spring's C++, which is also fairly familiar territory, and LUA is very strange to me thus far, because it's calling dependencies that aren't easy to find, variables are very ephemeral, and the syntax is odd. It's just going to take a minute, and I'm buried in work getting PURE to Alpha, so it's rather like balancing multiple sheets of glass on a thin stick

[AF]

*_*

Its very simple

You have tables.

tables store values

You have functions in a table called Spring written by trepan linked to spring

Trepans code will call functions defined in your code.

Ontop of that, all you need to know are very basic language constructs like iterating through a table, defining tables, and thats not very hard either.

imo you're vastly overcomplicating things argh, its simpler than you think and your just jumbling it all up because you percieve it to be harder than it really is.

Trepan has a global widget table. Any other widget can just lookup another widget in the global table and do their stuff. Thus one could create a widget that doesnt do anything but serves as a library for other widgets to call on.

[Zpock]

Yeah everything seems simple once u know all about it.

When you have no idea, its like:

Tables?

The thing you eat on?

[j5mello]

Yeah everything seems simple once u know all about it.

When you have no idea, its like:

Tables?

The thing you eat on?

nope we need the ones for ping-pong you silly fool

[Argh]

After reviewing what LUA can do, and how, and how it works with Spring, this is my thought:

Trepan / FLOZi / other slightly-interested parties:

I don't think we can achieve what I and Smoth want here, which is sounds that play only for the user. To do so, with LUA, would involve wasting massive CPU cycles every frame, checking to see whether enemy units have LOS or not. It'd be a big drag on gameplay, given how many sounds we want to play in order to hear stuff like footsteps, etc., and I don't think the tradeoff in performance is acceptable, now that I've looked into this a bit more.

I would actually prefer, myself, a COBHandler call, using the parameters SET PLAYSOUND_UNIT_TEAM, and PLAYSOUND_UNIT_LOCAL, that accepted arguments like this:

Code: Select all

PLAYSOUND_UNIT_TEAM (1, 100)

Where 1 = the first sound listed under the Unit's sound category (typically,"select1"), and 100 corresponded to volume scale, and acted just like acknowledgments, etc.

That way, the sound would play "privately", and would just use whatever code is used now for such sounds.

In short, doing this with LUA is possible, but I think it'd be a massive waste of computing resources. Unless this capability already exists, and can be invoked through LUA, this was a dead end- a new feature needs to be written, specifically for this sort of thing.

For now... I'll just keep using the LUA that I have, because it works better, in terms of volume scaling, than playsound does. That, however, is the only real advantage, and going further with the idea of using LUA to control this behavior, when the root cause is that we just don't have a "private sounds" method in Spring (to my knowledge, mind you) would be a waste of time.

[lurker]

I would actually prefer, myself, a COBHandler call, using the parameters SET PLAYSOUND_UNIT_TEAM, and PLAYSOUND_UNIT_LOCAL, that accepted arguments like this:

Code: Select all

PLAYSOUND_UNIT_TEAM (1, 100)

Where 1 = the first sound listed under the Unit's sound category (typically,"select1"), and 100 corresponded to volume scale, and acted just like acknowledgments, etc.

That way, the sound would play "privately", and would just use whatever code is used now for such sounds.

Expect it tomorrow. And I'm doing my best to also have one based on los. If I get los working, I might make los the way PLAY_SOUND works.

For now... I'll just keep using the LUA that I have, because it works better, in terms of volume scaling, than playsound does.

What's wrong with the scaling?


Edit: oh goody, los is extremely easy. This patch will be done very soon.
So should PLAY_SOUND get the los treatment or stay as is?

[Argh]

It should get the LOS treatment, subject to "field testing" to determine whether performance is satisfactory. That would give us "private sound" to broadcast only to users, and "public sound" that would only be broadcast within LOS, assuming that performance isn't a terrible issue. I'm a bit worried about performance hits should aircraft hit a base area in large numbers, or during the collision of large armies, but... er, compared to the performance savings inherent in not causing "private" sounds to be broadcast everywhere, I strongly suspect that it'd be a win-win all around!

As for scaling, yes, it's mainly because we're forced to use integers, therefore a sound event at 100 should correspond to the volume set by the user in Settings.exe for "Unit Reply Volume", allowing designers to, for example set one "private sound" at 50%, another at 200% for something especially dramatic, etc.

I most appreciate your interest in addressing this problem promptly and effectively! It seems like a minor thing, but it's really a larger problem than you'd think, in terms of behavior and utility.

[REVENGE]

What kind of los treatment are we talking about? It won't be designed to mute sound for all non los units would it?

[lurker]

The current plan:
GET PLAY_SOUND
p1: sound number
p2: volume in percent
p3: 0 = los, 1 = global, 2 = ally, 3 = team (optional, defaults to los)
p4: 0 = play at unit location, 1 = play directly, such as unit replies (optional, defaults to unit location)

What kind of los treatment are we talking about? It won't be designed to mute sound for all non los units would it?

Yes it would. I won't change it if there's a reason. You have one?

Edit: It seems that currently the sound function accepts a number from 0 to 100 for volume, capping it there. Frankly, I'm very confused. Cob and Lua call the same function, but apparently those lua examples multiply by .01, so if you fed them 100 the sound volume in the end would be 1% But surely you would notice something like that. But I can test and see that even though it is never divided by 100, setting the sound to 100 or over in cob makes it come out at normal volume. I can write that more coherently if you desire.

[KDR_11k]

Hm, if this is applied to weapons as well LRPCs and such will need playsound to make sure everyone knows one is firing. Can be done, though.

[lurker]

Hm, if this is applied to weapons as well LRPCs and such will need playsound to make sure everyone knows one is firing. Can be done, though.

I was thinking a tag for weapons. What would be a good name for it?

[Argh]

globalSound, binary on/off.

I'd suggest, for any areas where this gets applied to TDF-land:

playerSound
observedSound
globalSound

Just to keep the differences really obvious.

playerSound is player-only, never broadcasts to other players (and it'd be really awesome, if AIs could somehow ignore these entirely, saving LOTS of CPU-time for singleplayer, since IIRC, they're all "clients" on a player's machine, and they don't exactly need to hear the sounds lol).

observedSound plays to any client with a Unit in LOS. Probably going to be the largest use of this.

globalSound would be for things like LRPCs, nuke explosions, and Krogoth stomping (or, er, the equivalent in PURE... waitaminute, I don't have a Krogoth yet... drat).

[KDR_11k]

Of that list I think player should toggle whether other players can hear it when they are in a position to hear it (e.g. they see the explosion), global should toggle whether it always plays at full volume instead of emitted from a point source and observed means it will only play if you have ALOS to the source of the sound. I think player and observed can be put into one variable since a player will always be able to observe his private sounds, only global needs to be separate (so if e.g. you have ALOS to a nuke silo you could hear a voice "strategic weapon detected", no matter where your camera is). Just mentioning this because your list looks more like a sound can have at most one type of those.

I'd also say there should be a seismic value for sounds so you could use seismic as a display for sound sources.

[lurker]

Maybe observedsound has the options of what argh said, and worldsound is a boolean for whether it is in worldspace or direct. Because I don't want three mutually exclusive tags making things complicated.

Anyway, I think it's time for a little more on the implementation of GET PLAY_SOUND. I think I'll make two similar functions, PLAY_SOUND, and PLAY_UNIT_SOUND.

PLAY_SOUND will access the global table of sound files for the mod, which is sorted in alphabetical order. You'll have to work out the numbers yourself.

Code: Select all

GET PLAY_SOUND (15, 100,0,0)

Plays whatever the 16th sound used by the mod is.

PLAY_UNIT_SOUND is more self-contained. It accesses the table of sounds files that is located at the end of the cob file. This table lists the filenames of every play-sound call, in the order you call them. To use PLAY_UNIT_SOUND, you put an uncalled function near the top of the file. In this function you make a list of play-sound calls to all the sounds you want to use.

Code: Select all

sounds()
{
	play-sound ("zap", 100);
	play-sound ("pewpew1", 100);
}

...

	GET PLAY_UNIT_SOUND (0, 100,0,0);

Plays the first sound in the list, zap.wav


On another note, the call won't play any sounds for AIs unless they're running their own instance of spring. But ugh I have to figure out how to map these to the various spectator modes.

[SwiftSpear]

What kind of los treatment are we talking about? It won't be designed to mute sound for all non los units would it?

No.

Effectively what is needed is two sound groups, immersion sounds, and realistic sounds. It makes sense that a gun firing would make a big bang sound that everyone could hear, it doesn't make sense that if my marine says "yes sir commander" every time he executes an order that all my enemies can hear, unless the marine is within an enemy unit's line of audibility, which roughly speaking we'd estimate is the same range as LoS. Expecially for things like robot gear sounds and electrical sparks, they should be heard by player units when the enemy is within LoS, but not while the enemy is not in LoS, since it's basically giving away LoS information by sound.

Global sound, like Bertha shots and missile explosions should still be global, but not every sound can be used within that same scope and still make sense. That's what's being complained about, modders need more scopes of sound scape to work with, just because TA didn't use many static and persitant sounds doesn't mean spring modders don't want to use them now.

[KDR_11k]

I think most weapon sounds could be limited to ALOS (not LOS, ALOS; that circle around your LOS), too.

[Neddie]

I think most weapon sounds could be limited to ALOS (not LOS, ALOS; that circle around your LOS), too.

I agree.

[lurker]

Input time:
1. I think the global sound list isn't alphabetical after all. So you can't put your indexed sounds at the top, and it would screw up the scripts if you change the mod's sounds. I don't see any need for it if it's going to be that fragile. Everyone fine with me just including the mode with the sound table in the bos file? And if you want you can put that table in your header.

2. I'm also probably implementing a call to play a sound at an arbitrary 2D location, heard by all players. Make a ghost army! Comments?

3. Any confusion resulting from my 3 AM rambling? My examples suck? Ask away!