Pointless, people can still mic-spam without using voice_inputfromfile -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dustin Wyatt Sent: Wednesday, July 23, 2008 10:59 AM To: Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] Suggestion: Independant PFF Voicecom channel
This sounds like an awful lot of work for a very small minority of people. I can honestly say I've NEVER seen (heard?) anyone on my sever trying playing music for a "shared experience". There's already an SM plugin (http://forums.alliedmods.net/showthread.php?t=72227) that blocks use of HLSS and HLDJ (works great!), making this even less of a priority, I'm sure. On Tue, Jul 22, 2008 at 2:55 PM, <[EMAIL PROTECTED]> wrote: > 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 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
