How is a plugin that is designed to block people from using HLSS and HLDJ and succeeds at that task pointless?
On Wed, Jul 23, 2008 at 10:07 AM, Spencer 'voogru' MacDonald <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
