Sound issue in DP

[Cobalt]

I emailed LH a few times on this, so far no answer.

I believe I have found a bug with DP's new sound feature where sounds now travel with entities.

In my experimentation I have some ents spawned that represent "wind"....and randomly travel around open spaces near skyboxes. When they contact world, they 'rebound' and gain velocity. I mostly have their attenuaiton levels at static or idle making them short range. So far the system is good when you are close near these, you can hear wind move by you as they travel. However if you are in a distant room far away from the attenuaiton range, and you firs the grappling hook, the hook "picks up" the wind noises, and seems to even reflect their attenuation levels. I have noticed other moving ents like spikes from traps sometimes pick these up too. I have checked for channel conflicts, and I am doing CHAN_AUTO on the wind sounds, and I have changed the channel on the Hook for its noises, but no help. I had the winds movetype set to flymissile initially when I noticed the bug. I changed it to fly, and it seems to have helped reduce the sound level, but the problem is def still there. Im guessing the problem is engine side and related to sounds now moving with ents when the sound is applied to them directly. I suppose I could go with pointsound, but it does not support pitching the sound. Any input appreciated.

[frag.machine]

Interesting. CHAN_AUTO can makes things a bit unpredictable. Have you tried to use a fixed channel for the wind entity ?

[Cobalt]

CHAN_AUTO is suppose to pick a clear channel I believe.....the specs say its wont override a sound playing on any channel, so I guess if they are all playing a sound, the sound wont get played?

Anyhow, yes, tried a seperate channel just for the wind, problem still there. Initially I had the ent coded movetype bouncemissile not flymissile and that was the one that made it very bad. SO far the fly movetype seems to amplify it the least. I also decided to knock down the winds .velocity and that seems to have made a reduction as well. Perhaps there is a velocity limit, which makes sense because to a certain point when moving past a certain level the sound may as well not play at all its so brief. But this problem seems like another ent within a certain radius of the ent making the sound picks up the sound sort of like an antenna. Meanwhile the amplitude that this issue is passing onto the other ent is quite mild and I can only hear it if I listen carefully and have ambient_level set to zero otherwise those sounds mask it quite alot. I guess its not a major bug per say right now but I will experiment some more and see if velocity changes it, unless an angine coder can check the src and locate the specific problem.

Interesting. CHAN_AUTO can makes things a bit unpredictable. Have you tried to use a fixed channel for the wind entity ?

[frag.machine]

CHAN_AUTO is suppose to pick a clear channel I believe.....the specs say its wont override a sound playing on any channel, so I guess if they are all playing a sound, the sound wont get played?

Hence my statement: "CHAN_AUTO can makes things a bit unpredictable". I wasn't saying you shouldn't use it. I was just trying to get more info to figure out what could be causing the problem.

You mentioned that changing the entity velocity affects the problem intensity. Maybe this can also be related to the server tic rate (after a given speed the sound position update can become erratic), so the next experiment I'd suggest would be trying higher/lower values for sv_ticrate and check how this affects the bug. Also, for debug purposes try to replace the wind sound with something less subtle - a constant tone is preferable so you can better follow the sound "movement" and the evetual "antenna" effect.

[Spike]

chan_auto doesn't 'pick' anything. using chan_auto won't make it pick a random channel. channel 0 is channel 0, just as channel 1 is channel 1. the ONLY difference is that channel 0 will not remove any sounds already playing on that entity's channel 0. and yes, each entity has its own set of channels - playing any sample on a player entity should never replace a sample playing on a door or a different player.

if a sound is lingering weirdly in the wrong locations, chances are its because the server is now culling the entity for some reason and the client doesn't know where it moved to. you can always try disabling pvs and/or traceline culling (probably both) as a test.

[Cobalt]

I have the ent flagged as EF_NODRAW and EF_LOWPRECISION, and thought maybe the low precision was doing it but nope.

Now I recall this happening a long time ago when I assigned a rocketfly noise to the rocket model when fired. There were times I could hear someone's rocket flying when it was nowhere near where I was.


@ Frag Machine, I tried higher ticrates, problem definately worsens....in fact the player starts to emit the wind noises when moving fast.

So this bug is more or less forcing the sound to be on ent's that are also moving.....moving perhaps at a certain speed.

@ Spike, not sure how to do those things....

if a sound is lingering weirdly in the wrong locations, chances are its because the server is now culling the entity for some reason and the client doesn't know where it moved to. you can always try disabling pvs and/or traceline culling (probably both) as a test.

[Spike]

ch->entnum = MAX_EDICTS; // entity was removed, disown sound
this can prevent sounds from being replaced once the entity leaves pvs, which I would consider a bug in DP and could cause problems with doors and stuff in exotic situations...
it'll also start to use snd_csqcchannelXvolume instead of snd_worldchannelXvolume although I doubt anything but xonotic cares.

I don't see any way for it to follow the wrong entity though, just ways for it to stop following at all.


EF_NODRAW doesn't do what you think it does. its really EF_DONTTELLTHECLIENTABOUTTHISENTITYMOOHARHARMINEALLMINEMYPRECIOUUUUS.
Thus unconditionally triggering the ch->entnum=MAX_EDICTS bug (and related issues) that I mentioned earlier.

[Cobalt]

I removed the NODRAW effect, issue still persists. I also tried slowing down the ents velocity to 1/3rd normal speed, make the sound, then return to old velocity, no help.

Not sure what you mean by the MAX_EDICTS reference, but I have a regulator that hijacks then monitors the spawn () builtin to count spawned edicts, and warn us in console if we exceed 6000. I could tell by my initial tests we were nowhere coming close to that and I made sure they get removed after counting a certain number of think field executions. So far they all seem to remove fine. Are you saying perhaps do something to manually clear the sound channels on the ents before removing them? Such as stuff in misc/null.wav ?

UPDATE/ EDIT:

Well I did try stuffing in a null wave just before the remove, no go. Also I have a findradius going that looks for nearby wind ents who are executing their think and possibly playing a sound, and if so, we wait another think to check that situation again. I commented that out in the event the findradius was effecting somehthing, still no help.

Im thinking this issue is so minor maybe its not worth looking into further. In the case of wind, its possible to maybe hear wind in remote locations and this is more or less a 'leak' so to speak and since my amplitude for the wind is set to a low value and the attenuation is the highest I guess we can live with it. The other one I saw a while back with the rocket/ missile was of concern though and resembled this a great deal.

ch->entnum = MAX_EDICTS; // entity was removed, disown sound
this can prevent sounds from being replaced once the entity leaves pvs, which I would consider a bug in DP and could cause problems with doors and stuff in exotic situations...
it'll also start to use snd_csqcchannelXvolume instead of snd_worldchannelXvolume although I doubt anything but xonotic cares.

I don't see any way for it to follow the wrong entity though, just ways for it to stop following at all.


EF_NODRAW doesn't do what you think it does. its really EF_DONTTELLTHECLIENTABOUTTHISENTITYMOOHARHARMINEALLMINEMYPRECIOUUUUS.
Thus unconditionally triggering the ch->entnum=MAX_EDICTS bug (and related issues) that I mentioned earlier.

[Cobalt]

Another sound question not related to this - DP_POINTSOUND

Does not allow a sound channel to be assigned, is it assumed to be using CHAN_AUTO ?