JSB> I'm not sure which version of hl it started in, but I've really noticed JSB> this lately.. I don't know how easily it can be fixed (or if anyone JSB> there at valve will even fix it, it's just irritating), again this is JSB> another post where that I'm not sure where to send it; so I'm posting it JSB> here since it IS mod related as well.
JSB> It seems that any created on the client via the function JSB> gEngfuncs.pfnPlaySoundByIndex( iSound, vol ); uses CHAN_ITEM now, and JSB> ALWAYS kills _ANY_ sound already playing on it. I don't remember this JSB> happening a long time ago. A good example is the Geiger counter, if JSB> you're near radiation, it stomps all over your weapon select on the hud; JSB> which used to ALWAYS play, and the code for it looks the same as it did JSB> back in sdk 1.0. JSB> Even if you cycle weapons, anything on the client using that function JSB> will stomp on the previous sound playing on it. Is it possible to make JSB> it just use the auto channel like I *think* it used to a long time ago? JSB> -omega JSB> http://www.frontline2.com Not cool.. __Help:____________________ Quick fix: generate a temporal entity, and make that entity the sound generator. _Random Gibberish Stuff____ Maybe you can force to use CHAN_AUTO somewhat. I don't think is now imposible to access that. I dont know the HL netcode, *maybe* the HL svc_sound whas originally that: MSG_WriteByte (&sv.datagram, svc_sound); MSG_WriteByte (&sv.datagram, field_mask); if (field_mask & SND_VOLUME) MSG_WriteByte (&sv.datagram, volume); if (field_mask & SND_ATTENUATION) MSG_WriteByte (&sv.datagram, attenuation*64); MSG_WriteShort (&sv.datagram, channel); MSG_WriteByte (&sv.datagram, sound_num); for (i=0 ; i<3 ; i++) MSG_WriteCoord (&sv.datagram, entity->v.origin[i]+0.5*(entity->v.mins[i]+entity->v.maxs[i])); [byte][byte]{[byte][byte]}[short][byte][float][float][float] Interesting enough, *maybe* channel whas send as a short and now something like: if (volume == 1) //use a new svc_sound version { MSG_WriteByte (&sv.datagram, svc_soundsmall); //new svc // asume attenuation normal // asume channel is ..CHAN_BODY?.. //MSG_WriteByte (&sv.datagram, volume);//assume volume is 1 MSG_WriteByte (&sv.datagram, sound_num); for (i=0 ; i<3 ; i++) MSG_WriteCoord (&sv.datagram, entity->v.origin[i]+0.5*(entity->v.mins[i]+entity->v.maxs[i])); [byte][byte][float][float][float] or [byte][byte][short][short][short] I think is lame that sound send a short over the net, and i dont understand is mod coders only where capable to use that: gEngfuncs.pfnPlaySoundByIndex( iSound, vol ); has here you can't affect attenuation, channel,.... I guess for 99.99% sounds volume is 1, attenuation is 1, channel is 1. Is lame to send over the net a [byte][byte][short] that is soo constant! IMHO. Other option, cleaner?,.. can be to add new SND_ values to filter_mask Maybe other funcion exist, something similar to this: gEngfuncs.pfnPlaySoundChannelByIndex( iSound, vol , channel );//????? I dont know because I am newbie here. __Sign_____________________ My english is crap. postdata: I am still interested in the dem file format for hl _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
