From: Marc VanHeyningen <mvanheyn@silky.cs.indiana.edu>
Subject: Re: Sound in the client
X-Quoted: 23%
Reply-To: mvanheyn@whale.cs.indiana.edu
Organization: Computer Science Dept, Indiana University
Date: Wed, 19 Aug 1992 10:34:33 -0500

Thus said sfd@neuromancer.metaphor.com (Scott Drellishak):
>In article <1992Aug18.171549.28634@news.cs.indiana.edu> Marc VanHeyningen <mvanheyn@silky.cs.indiana.edu> writes:
>>You don't need much of a text-to-speech setup; a few key words like
>>"ogg" and "bomb", numbers and letters of ships, and maybe names of planets
>>is adequate, IMHO.  Easy to make with a microphone.
>>
>>BTW, I am assuming the changes you have made are in a client of your own
>>and won't go into the blessed one, yes?
>
>No.  I'm hoping to put together a sufficiently portable and flexible sound
>system that it will be adopted into the Next Big Release client.
>
>I don't like the idea of sampling speech and parsing messages for key
>words.  Among other things, suppose after I write the program, somebody
>comes up with another popular shorthand like "F5++" or "ogg", which I
>haven't included in the client?  Also, it'd be really easy to spoof
>an enemy by sending them fake ogg messages -- this would both slow down
>their machine and make them go after the wrong people.  In any case,
>sampled speech could be quite large, making the distribution that much
>larger.

Having the parser simply ignore messages like:

R3->FED ogg 5

is a simple addition; mine does this.  (I still don't see how a Rom can
transmit messages to the Feds without his team being able to tell, but
that's how da server works.)  If there is a traitor on your team, many
servers allow you to ignore messages from that person; I haven't yet
bothered to add such a provision to the program, though it wouldn't be
hard.  It also figures out who you are, and doesn't read messages from you
aloud, since you probably already know what you said.

If someone comes up with a new popular shorthand which is being used
quite a bit, then you add a new rule to the grammar and re-yacc it.  If
one doesn't know enough to know how to add rules and yacc stuff, obviously
(s)he's not a Real computer person and should go away. :-)  Admittedly,
LALRish parsers such as the one I have don't deal terribly well with
typographical errors, which can be common when people are typing in a
hurry.  Other than slightly broadening the tolerance of the lexical
processor, I don't know a good solution.

The size argument is indeed a concern, since there isn't any very good
way to compress sound.  A sufficient but small library probably could
take at least 500 blocks.  Having it stored in a central place wouldn't
be too bad, but at sites where the admins are not netrek-friendly, it
would be prohibitive for each person to have a copy.  Fortunately, HOMEs
need not be permitted 700.

On the other hand, simply reading the content of each message with a
conventional speech synth is not OK, IMHO.  For example, distress calls
would take at least 10 seconds to read the full text of.  (Here in
Indiana, we end prepositions with.)  Repeated distress calls, as is
common, would mean distracting and annoying sounds would permeate you
while you couldn't hear new useful messages for a substantial period of
time.  Other messages, like "planet under attack" messages, are also
common and would be really annoying.  (Imagine what the speaker would do
during the initial bombing run.)  If you started reading kill messages
aloud, the speaker would never catch up with the messages.  (Allowing
kill messages passed through a pipe also allows borgish mods.)  I think
it's important to distill messages down to their core informational
content when possible; e.g. in distress calls, the critical information
is who it is, how many armies, and whether they're hurt.

I assume that an NBR proposal for what you suggest would more or less
break down to a modification of the existing NBR message-hooks proposal
(I don't know if it has passed or not, but I didn't hear any objections
to it provided it excluded kill messages.)  The new pipe contents might
look sort of like:

t			# torp
p			# phaser
mF3->FED 6++		# message
e			# explosion (?)
mRb->F2 you suck	# message

Is that more or less how it'd be integrated?  I'd support such a
proposal, after knowing exactly what would be reported and considering
whether it allows anything "unfair" to be done with the information.
I also would guess the pipe would be flushed after each update or
something, since flushing for each torp seems a little much.
-- 
Marc VanHeyningen     mvanheyn@whale.cs.indiana.edu     MIME accepted
On->ORI Ogg their base!
Om->ORI Killing their base does nothing to help our team at this point.
On->ORI But he's hurt!!!