That amounts to facilitating the listening of the music. Whilst the ability is there but not encouraged Valve are probably ok. With tools about to play music over the channels TECHNICALLY the people playing it need to be paying royalties....
I also doubt it would stop people playing it over the voice channel using the age old method (heh) of sticking their mic against the speaker ;) Still, good idea :)| Tom -------------------------------------------------- From: <[EMAIL PROTECTED]> Sent: Tuesday, July 22, 2008 8:55 PM To: <hlds@list.valvesoftware.com> Subject: [hlds] Suggestion: Independant PFF Voicecom channel > As you know, a lot of people use the VoiceCom Play-From-File feature > (Heretofore refereed to as "PFF") to do things like play music and > prerecorded sounds with the assistance of tools like HLSS and HLDJ. While > many people find this annoying, others rather enjoy it. Unfortunately for > everybody, the sound files used must be converted to a low-quality wave > file and altered to prevent distortion, and are played back through the > general VoiceCom system. > > My suggestion is actually quite simple and would improve enjoyment for all > players across the board, with the notable exception of people who play > the game for the sake of causing others grief. > > Step 1: Add a second VoiceCom channel. The current voice channel should be > renamed to reflect it's status as a sub-channel, such as "VoxChan", and > this second one should be titled something like "PFFChan". > Step 2: Force any audio that's played from a file to be broadcast over > "PFFChan", and any audio from a system input to be broadcast over > "VoxChan" > Step 3: Allow people to selectively mute entire channels so that they can > (if they so choose) listen exclusively to people talking, to exclusively > file-based content, to everything, or to nothing at all. Allow servers to > block "PFFChan" and/or "VoxChan" via a setting, just as servers can block > VoiceCom now. > Step 4: Add support streaming precompressed files (MP3 and OGG formats > would likely be best), since precompressed files have a much higher > quality to bandwidth ratio. This allows for full-quality sound for far > less bandwidth. (Limiting it to 96kbps would be acceptable) > Step 5: Increase flexibility of sound options to allow players to adjust > the three-way balance between the two channels and the game as they see > fit. > > The following are optional, but recommended: > Option 1: Support for media information (ie: ID3) so that players could be > easily informed as to the source of a file (Via overlay, menu, or HUD > message). > Option 2: Local buffering options to prevent skips, drops, or desychs in > playback. File playback is not as time-sensitive as voice, and so a local > buffer could protect against sudden lagspikes or short periods of lessened > bandwidth. > > Although the ability to manage these files in game would be convenient, > there are actively maintained third-party packages that would be quickly > retrofit for this task. > > Benefits: > > *Easier server administration: Many servers disapprove of PFF, but > encourage the use of VoiceCom. These servers are often faced with > transient players who make use of the PFF feature, often resulting in the > admins being forced to take action against them. Blocking PFFChan on a > server would preemptively stop most such events. > *Increased Difficulty for Griefers: If PFFChan is blocked on a server, > then griefers would need to use either an awkward hardware solution or a > virtual soundcard driver/software package. > *Increased PFF Audio clarity: Currently PFF is limited to 11khz 16bit mono > sound, which quite frankly is horrible. Since compression takes far more > CPU time than decompression, and is by it's very nature a time/memory > trade-off, you can get far better quality for the same bandwidth without > increasing CPU load by simply streaming precompressed audio instead of > compressing streamed audio under heavy CPU load. > *Decreased Bandwidth Consumption: As corollary to the above, the bandwidth > consumption is less per quality for precompressed audio than for real-time > compression. A carefully chosen KBPS limit would allow both vastly > improved quality and reduced bandwidth. > > > Here's a crude flowchart showing the key differences between the current > system and the one I propose: > http://img.photobucket.com/albums/v247/Baikasu/voicecomflow_MkII-1.gif > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
