#d/TMI/boards/bugboard.c
ob_data (["last_location":0,"id":({"board","bulletin board",}),"silent_look":1,"long.text":"This is a bulletin board. For information on how to use it, use `help board'.
","short.text":"The Tmi-2 mudlib bug board","long":"@@query_long","short":"@@query_short",])
messages ({(["id":42,"body":"On Fri May  3, Hanzou wrote:
> On Fri May  3, Ciao wrote:
> > I type say %%^^RED%%^^test, and I see exactly that, not %^RED%^test%^RESET%^
> this is due to the removal of that overriding write() simul efun

from /adm/simul_efun/write.obsolete:

void write(string msg)
{
   message(\"write\", msg + \"\", this_player());
}

I doubt it :)

L:eto
","time":831241119,"poster":"Leto","title":"Re: color",]),(["id":43,"body":"On Sat May  4, Leto wrote:
> On Fri May  3, Hanzou wrote:
> > On Fri May  3, Ciao wrote:
> > > I type say %%^^RED%%^^test, and I see exactly that, not %^RED%^test%^RESET%^
> > this is due to the removal of that overriding write() simul efun
> 
> from /adm/simul_efun/write.obsolete:
> 
> void write(string msg)
> {
>    message(\"write\", msg + \"\", this_player());
> }
> 
> I doubt it :)
> 
> L:eto

exactly, the removal of it makes receive_message() no longer called from
write(), as i said before.
","time":831246850,"poster":"Hanzou","title":"Re: color",]),(["id":44,"body":"> exactly, the removal of it makes receive_message() no longer called from
> write(), as i said before.

The removal of the simul write() just causes write() functions
to use the efun write(), which does a message(\"write\",blah,this_player())
(and i believe if there is no this_player, users this_object instead)

I still don't see why this would involve the call to terminal_d which handles
these keyword translations. So feel free to explain it to me :)

","time":831298641,"poster":"Leto","title":"Re: color",]),(["id":45,"body":"> The removal of the simul write() just causes write() functions
> to use the efun write(), which does a message(\"write\",blah,this_player())

that's not what the write() efun does.  write() sends a message directly to
the user, not through receive_message().  or it sends the message to
catch_tell() if the object non-interactive or INTERACTIVE_CATCH_TELL is defined.
and there is no driver option to make the old message efuns use the message()
system.

> eval message(\"write\", \"%%^^GREEN%%^^hi%%^^RESET%%^^\\n\", this_player())
%^GREEN%^hi%^RESET%^
Result = 0
> eval write(\"%%^^GREEN%%^^hi%%^^RESET%%^^\\n\");
%%^^GREEN%%^^hi%%^^RESET%%^^
Result = 0
","time":831312002,"poster":"Hanzou","title":"Re: color",]),(["title":"Re: color","poster":"Beek","time":831335206,"body":"Anyone who thinks write(), et al have anything to do with receive_message()
are on drugs.

The idea that all output goes through recieve_message() is a myth perpetuated
by libs that insist on simul'ing efuns and redefining their behavior to be
something else, causing coders to become confused as to what the the 'correct'
behavior of the efuns is.

receive_message() is ONLY called by the message() efun, and that's all.
As far as the driver is concerned, it has no other significance.

The local routine for intercepting output to players has a different, and
much older name.  The routine is called 'catch_tell'.  Defining
INTERACTIVE_CATCH_TELL causes all output, even to interactives (i.e. users)
to go through it.

-Beek
","id":46,]),(["title":"earth?","poster":"Hanzou","time":831338684,"body":"> tell skylight hi
Skylight is not on Earth.
","id":47,]),(["title":"color","poster":"Farrow","time":831434676,"body":"Well it does have something to do with the write simul_efun cause we put
it back in, but unfortunately with the updated driver it doesn't allow the
mud to reboot so we took it back out.  At least I think it was the driver. 
Works fine on the other driver we have.  Anyway that's just my 2 cents.

Mike
","id":48,]),(["title":"Re: earth?","poster":"Leto","time":831464422,"body":"On Mon May  6, Hanzou wrote:
> > tell skylight hi
> Skylight is not on Earth.

Fixed :)

Leto
","id":49,]),(["title":"re:write","poster":"Leto","time":831464746,"body":"IMHO, write is a bad idea. There is hardly any reason to directly
output text to an interactive without processing it. Beek has made some
effort to update some efuns that also uesd it directly to return
strings. Also, with directing all output in a structured way
(good mesg classes) to a single function in users is a good idea.
You can format layout on a per-user basis, and users can chose
how they want it formatted.
IMHO, things as write and tell_object being used for tons of
different kinds of messages is Bad[tm].

Leto

Ps. Now if we could only have a @String foo String construct that
allows us to hit return a few times, and turn it into one big
long string (concatenated with a space maybe ;) that would help
a lot (it would save an implode(explode()) calll in receive_message
for all input users get :)
","id":50,]),(["title":"@String foo String construct","poster":"Ciao","time":831474067,"body":"it's called the \"to\" command or the \"pipe\" command.
:)
","id":51,]),(["title":"Re: @String foo String construct","poster":"Leto","time":831476210,"body":"On Tue May  7, Ciao wrote:
> it's called the \"to\" command or the \"pipe\" command.
> :)

You didn't understand me :)

for editing in a file, I normally use (because it is hte easist way
of reading and editing) for large chunks of text:

string somefunc() {
return (@EndString
This is
a very
long string,
more then 80 characters, but which i typed in at an 80 char screen.
EndString ;)
}

Thus, i can type screens easily, but this trick uses \\n to concatenate
strings. Now, imagina someone who was a 132 column screen. This layout
would look bad. So, to fix this I now have to do an implode(explode(..))
on the string, using his term settings to get the correct line size.

Now, if i could specify the concatenate character, i could have specified
a space, and then i only need to 'regularly' wrap it. 
Since this is (or will be;) done a lot in receive_message, it would save
a LOT of cpu power.
(The alternative is not using @foo bar foo, but that results in us having
to use quotes on large chunks of texts, making it a lot uneasier to edit
it.

Leto (pondering posting this at IE for Beek ( keeping quarters ready))
","id":52,]),(["id":53,"body":"
Hmm, it seems I was misunderstood.  I didn't say there was anything
wrong with central processing, I just dislike simul'ing efuns to
do something completely different from what they really do.  E.g. a write()
simul that calls message() really isn't anything like the efun any more,
and should have a different name.

Why?  Ask around and see how many TMI coders thing that the write EFUN
calls the message() efun.

Remember, the write() simul was originally a compat hack, and wasn't
supposed to be used.  It should have been removed years ago.

-Beek
","time":831856970,"poster":"Beek","title":"Re: Leto",]),})
id_ref 53