#d/TMI/boards/generalboard.c
ob_data (["long":"@@query_long","short.text":"General purpose bulletin board","short":"@@query_short","long.text":"This is a bulletin board. For information on how to use it, use `help board'.
","id":({"board","bulletin board",}),"silent_look":1,"last_location":0,])
messages ({(["id":195,"body":"Why doesn't the terminal stuff working now?  You know the % ^ stuff?
We have used this quite a bit and don't want to lose it.  Thanks.

Farrow
","time":826778494,"poster":"Farrow","title":"terminal.c",]),(["title":"Re: terminal.c","poster":"Leto","time":826836635,"body":"On Thu Mar 14, Farrow wrote:
> Why doesn't the terminal stuff working now?  You know the % ^ stuff?
> We have used this quite a bit and don't want to lose it.  Thanks.
> 
> Farrow

It's a problem with the terminal code in the receieve_message() call
which i haven't had time for to check.
Basically, Tmi always had two different systems of doing term stuff.
At Earth (and maybe here too if people are interested) I am migrating
to my term/_term combination, and tintegrating the shell and 
Robo's scrollback into the receive_message. Then we need a terminal_d
call in there to translate to whatever colours your place.

Volunteers to help ? :)

Leto
","id":196,]),(["title":"Re: terminal.c","poster":"Farrow","time":826845722,"body":"> It's a problem with the terminal code in the receieve_message() call
> which i haven't had time for to check.
> Basically, Tmi always had two different systems of doing term stuff.
> At Earth (and maybe here too if people are interested) I am migrating
> to my term/_term combination, and tintegrating the shell and 
> Robo's scrollback into the receive_message. Then we need a terminal_d
> call in there to translate to whatever colours your place.
> 
> Volunteers to help ? :)
> 
> Leto

What would need to be done?  I would be willing to help you.  Quite
busy right now, but I think I could spend some time on it.  

Farrow
","id":197,]),(["id":198,"body":"On Thu Mar 14, Farrow wrote:
> Why doesn't the terminal stuff working now?  You know the % ^ stuff?
> We have used this quite a bit and don't want to lose it.  Thanks.
> 
> Farrow

uh, it seems to be working fine here, for receive_message() stuff.  you could
call it a bit out of date for not using terminal_colour(), but that's ok.

there is no code here to make it work for catch_tell() stuff however, such
as 'who'
","time":826853417,"poster":"Hanzou","title":"Re: terminal.c",]),(["title":"Some characters not restoring properly?","poster":"Hideyoshi","time":826951206,"body":"Recently, some of my wizzes (I really have no players) have had trouble
logging in.  Their bodies don't restore properly, and they end up as
\"Noname\" (cap name Noname, id noname, name noname, etc...), with no
language capability.  It seems to be rather random, although it's only
my newer wizards to whom it happens (like those created in the past couple
of weeks).

Any ideas why this happens?
-h
","id":199,]),(["title":"Re: Some characters not restoring properly?","poster":"Hanzou","time":826994479,"body":"On Sat Mar 16, Hideyoshi wrote:
> Recently, some of my wizzes (I really have no players) have had trouble
> logging in.  Their bodies don't restore properly, and they end up as
> \"Noname\" (cap name Noname, id noname, name noname, etc...), with no
> language capability.  It seems to be rather random, although it's only
> my newer wizards to whom it happens (like those created in the past couple
> of weeks).
> 
> Any ideas why this happens?
> -h

there was a /cmds/adm/_fixnoname.c on tmi-2, but i guess it wasn't part of
the tmi-2 1.2 release, so now it's gone.

i've never really checked out an individual occurrance of this however.  but
i suspect it's due to _any_ error while restoring.  tail /log/runtime
","id":200,]),(["title":"Re: terminal.c","poster":"Leto","time":826995661,"body":"> uh, it seems to be working fine here, for receive_message() stuff.  you could
> call it a bit out of date for not using terminal_colour(), but that's ok.
> 
> there is no code here to make it work for catch_tell() stuff however, such
> as 'who'

We don't have catch_tell. Al message directing to livings, players
mnsters etc is done through receive_message.

Leto
","id":201,]),(["title":"Re: Some characters not restoring properly?","poster":"Leto","time":826995828,"body":"About the Noname stuff.

This is usually a permission problem, or a harddisk is almost full
problem.
Check out if the mud hasn't run as another user ('root' is quite
frequently used by accident on linux machines:). Since if root saved
a file and the mud runs on the mudaccount the next time, the file
created is owned by root and cannot ususally be overwritten by the
mud account.

Also, nonames tended to get on by having their user.o file removed while their
connection .o file was still around. (So not using nuke but removing
/data/std/user/f/foo.o wcould cause this)

Leto
","id":202,]),(["title":"Re: Some characters not restoring properly?","poster":"Leto","time":826995897,"body":"On Sat Mar 16, Hanzou wrote:
> there was a /cmds/adm/_fixnoname.c on tmi-2, but i guess it wasn't part of
> the tmi-2 1.2 release, so now it's gone.

It's gone because it didn't really work. Almost all nonames were
due to either the user or the connection datafile to be lost.
And if that's gone, there really isn't enough data to 'fix' a noname.

Leto
","id":203,]),(["title":"Re: Some characters not restoring properly?","poster":"Lucas","time":826998677,"body":"On Sat Mar 16, Leto wrote:
> About the Noname stuff.
> 
> This is usually a permission problem, or a harddisk is almost full
> problem.

We've had that problem on Avatar. The player files don't work 'cause
the disk if almost full.

> Leto

It really sucked cause once, I had to do a complete MANUAL purge of
everyone. 
	-lucas-
","id":204,]),(["title":"Re: terminal.c","poster":"Hanzou","time":827042532,"body":"On Sat Mar 16, Leto wrote:
> We don't have catch_tell. Al message directing to livings, players
> mnsters etc is done through receive_message.
> 
> Leto

just found out about the write(), tell_object(), say(), tell_room(), and shout()
simul efun overrides.  though i noticed write() and tell_object() commented
out.  this appears to be the reason messages from those 2 funcs don't have
color codes converted.  why are those overrides commented out?
","id":207,]),(["title":"Re: terminal.c","poster":"Leto","time":827076551,"body":"> just found out about the write(), tell_object(), say(), tell_room(), and shout()
> simul efun overrides.  though i noticed write() and tell_object() commented
> out.  this appears to be the reason messages from those 2 funcs don't have
> color codes converted.  why are those overrides commented out?

Because when those simuls were created, they were more powerful
then the efuns. However, that's not the case anymore.
Also, those efuns should not do any translating of the
messages they relay. ONLY receive_message should do that. The
same for wrap() and iwrap().
I am currently gathering people to help me convert all that. So
far I think Farrow, Punkette and Dm would be willing to help :)
If anyone else is interested and has the time, let me know and
we can add you to the interest group. Basically, we're going
to move all formatting to receive_message and out of the rest
of the mudlib, and make it possible to use different protocols
depending on the client you are using (Think Java[tm] :)

I'd like to start discussing the topics next week and maybe get
a work schedule set in two weeks. Partially, if will be Java
coding, and partially it will be mudlib coding.

Leto
","id":208,]),(["title":"Re: terminal.c","poster":"Hanzou","time":827080238,"body":"On Sun Mar 17, Leto wrote:
> Because when those simuls were created, they were more powerful
> then the efuns. However, that's not the case anymore.

not sure what you mean by 'powerful'.  those simul efuns use message() so
messages go through receive_message().  without them, messages would go
directly to the user, or catch_tell() if it were a monster.

> Also, those efuns should not do any translating of the
> messages they relay. ONLY receive_message should do that. The

i assume you mean simul efuns when you say 'efuns'.  these simul efuns cause
receive_message() to be called.  if the efuns were used directly instead of
the simul efuns, color codes would not be translated.

> same for wrap() and iwrap().
","id":209,]),(["title":"Re: terminal.c","poster":"Avatar","time":827159380,"body":"On Thu Mar 14, Leto wrote:
> On Thu Mar 14, Farrow wrote:
> > Why doesn't the terminal stuff working now?  You know the % ^ stuff?
> > We have used this quite a bit and don't want to lose it.  Thanks.
> > 
> > Farrow
> 
> It's a problem with the terminal code in the receieve_message() call
> which i haven't had time for to check.
> Basically, Tmi always had two different systems of doing term stuff.
> At Earth (and maybe here too if people are interested) I am migrating
> to my term/_term combination, and tintegrating the shell and 
> Robo's scrollback into the receive_message. Then we need a terminal_d
> call in there to translate to whatever colours your place.
> 
> Volunteers to help ? :)
> 
> Leto
So, I'm not the only one with this weird problem :))
/s
","id":210,]),(["title":"Re: terminal.c","poster":"Avatar","time":827159653,"body":"On Sun Mar 17, Leto wrote:
> Because when those simuls were created, they were more powerful
> then the efuns. However, that's not the case anymore.
> Also, those efuns should not do any translating of the
> messages they relay. ONLY receive_message should do that. The
> same for wrap() and iwrap().
> I am currently gathering people to help me convert all that. So
> far I think Farrow, Punkette and Dm would be willing to help :)
> If anyone else is interested and has the time, let me know and
> we can add you to the interest group. Basically, we're going
> to move all formatting to receive_message and out of the rest
> of the mudlib, and make it possible to use different protocols
> depending on the client you are using (Think Java[tm] :)
> 
> I'd like to start discussing the topics next week and maybe get
> a work schedule set in two weeks. Partially, if will be Java
> coding, and partially it will be mudlib coding.
> 
> Leto
You can add me to... I'll hack the simul_efun wrap/iwrap to generate a logfile.
In that way, we can see WHERE the (x)wraps are used...

Avatar of Eodon (is finally Back)
","id":211,]),(["id":212,"body":"On Sun Mar 17, Leto wrote:
> > just found out about the write(), tell_object(), say(), tell_room(), and shout()
> > simul efun overrides.  though i noticed write() and tell_object() commented
> > out.  this appears to be the reason messages from those 2 funcs don't have
> > color codes converted.  why are those overrides commented out?
> 
> Because when those simuls were created, they were more powerful
> then the efuns. However, that's not the case anymore.
> Also, those efuns should not do any translating of the
> messages they relay. ONLY receive_message should do that. The
> same for wrap() and iwrap().
> I am currently gathering people to help me convert all that. So
> far I think Farrow, Punkette and Dm would be willing to help :)
> If anyone else is interested and has the time, let me know and
> we can add you to the interest group. Basically, we're going
> to move all formatting to receive_message and out of the rest
> of the mudlib, and make it possible to use different protocols
> depending on the client you are using (Think Java[tm] :)
> 
> I'd like to start discussing the topics next week and maybe get
> a work schedule set in two weeks. Partially, if will be Java
> coding, and partially it will be mudlib coding.
> 
> Leto

Yeppers, I'm in. Give me a starting spot, and I'll go to town. :-)
","time":827310419,"poster":"Dm","title":"Re: terminal.c",]),(["id":213,"body":"
Ok, we now have 5 people who can work on things. I wiull definetly
send out a list of things to do, and we can see about meeting
and gets things organised.

Avatar, about the wrap calls. I have made a perl script which
will replace all wrap() calls with nothing, so it should be
a quick run of a script file. But it still has some problems with
translating \\n's into real returns (or vise versa ;)

Expect a mail from me on friday.

Leto

Ps. I am having a few hardware problems on my end, so i have a little bit
less access right now then normally. It might take longer for me
to respond to things.
","time":827327161,"poster":"Leto","title":"Cool ;)",]),(["id":214,"body":"Hi! I'm a total newbie in lpc and sorry about my stupid question, but looks like
it is a place, where i can get an answer... I (try to) use MudOS v21 under
solaris... but only library, it seems to be able to run with not big problems
is lil. I have tried tmi2, heaven7 and just now tried Nightmare. I don't
remember exactly, what it said about tmi, but at heaven7 it says
obj/master.c line 205: parse error
The simul_efun (/obj/sim_ef_1.c) and master (/obj/master) objects must be loadable

and about nightmare it says
The simul_efun (/secure/sefun/sefun.c) and master (/secure/daemon/master) objects must be loadable.

what does mean that \"simul_efun (blabla) and master (blabla) objects must be
loadable\"? I looked at config files and there where the locations of these
files correct. What can be the reasons of such kind of message?
","time":827439309,"poster":"Joka","title":"< no title >",]),(["id":216,"body":"> Hi! I'm a total newbie in lpc and sorry about my stupid question, but looks like
> it is a place, where i can get an answer... I (try to) use MudOS v21 under
> solaris... but only library, it seems to be able to run with not big problems
> is lil. I have tried tmi2, heaven7 and just now tried Nightmare. I don't
> remember exactly, what it said about tmi, but at heaven7 it says
> obj/master.c line 205: parse error
> The simul_efun (/obj/sim_ef_1.c) and master (/obj/master) objects must be loadab
> le
> 
Last time I looked at heaven7 it had not been brought up to date with respect to
MudOS v21.  However, someone could have brought it up to date(I doubt it though)

> and about nightmare it says
> The simul_efun (/secure/sefun/sefun.c) and master (/secure/daemon/master) object
> s must be loadable.
> 
Depending on what version of nightmare you are using you might need a version of MudOS newer then v21

> what does mean that \"simul_efun (blabla) and master (blabla) objects must be
> loadable\"? I looked at config files and there where the locations of these
> files correct. What can be the reasons of such kind of message?

You get these these messages when MudOS can't interpret your master or
simul_efun objects.  This is usually caused by some kind of syntax error.  You
could fix this by fixing the error but a better solution would be to use the
correct version of MudOS

-Dalto
","time":827459668,"poster":"Dalto","title":"Re: Joka",]),(["id":217,"body":"
The only driver I have ever seen a Heaven7 lib run on is Amylaar. I was
under the impression that you really lacked a choice with the lib but
I am sure I know very little.

- Mk
","time":827483840,"poster":"Moksha","title":"Re: Joka",]),})
id_ref 231