MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

Re: The best way for @beep



Don Schwarz wrote:

> Both ways work fine in 1.8.0, but using set_connection_option is definately
> the prefered way to do it (especially for portable code, I guess for a MOO
> to use specifically for their own stuff, it doesn't matter as much). Version
> 2.2 of my ANSI system uses set_connection_option to output binary strings
> like you suggested above, the only reason 2.1 didn't is because I released
> it before 1.8.0 was in beta.  Using set_connection_option isn't really
> dangerous though, as long as you wrap the notify() call with a try-finally
> (to unset the binary bit if it traces back) and don't call any verbs which
> might output their own text between setting the binary flag and unsetting
> it.

Jefferson M. Dubrule wrote:
> 
> @program $player:beep
> if (ticks_left < 500)
>    raise(E_QUOTA, "Not enough ticks to complete beep.");
> else
>    try
>       set_connection_option(this, "binary", 1);
>       this:notify("~07");
>    finally
>       set_connection_option(this, "binary", 0);
>    endtry
> endif
> .
> 
> That's about it . . .
> (The tilde,07 is a beep in hex)

Thanks all of you
I guess the ticks check is for being sure that non-binary is restored
Looks like quite secure now.
But I am still suspicious about that solution.
I do not what to think about the db hack. Well, is a hack, but in later
versions this can be a feature if I am right.

I know a disadvantage: If you store only a -r wiz-only prop in the moo
with 07 and another for 27 is secure, but you have to perform
substitutions every time you print something (I have an ansi parchis
game-board 40x23 that runs out of ticks in substitutions)
What I did to solve that is to store the strings in "binary" (It is
posible after the hack) making a simple verb that makes the
substitutions once. The problem is that this new prop must be -r or else
anyone can get and use an ansi code, and this looks dangerous.
Maybe filtering notify() can help.
I know this could look like a very complex solution, but as a clear
advantage: db size (notice that a lot of ansi text can be quite big),
and speed, both of them very valued, I guess.

What do you (all) think about this? Any suggestions?
Am I wrong at something or miss something?
Thanks




Follow-Ups: References:

Home | Subject Index | Thread Index