--- In protomuck@yahoogroups.com, "Jonathan Piacenti" <kelketek@...> wrote:
>
> I have a few programs that I'd like to force the player to enter an
interactive mode for as soon as he connects, specifically to ensure proper
player setup, beginner's tutorial, etc. But the helpfile shows, and my attempts
to work otherwise prove, that _connect, and _arrive programs are forced into
Background mode as soon as they start, making reads impossible. How do I fix
this, or allow programs to be run in the foreground?
>

You /might/ be able to @force them to execute a command that takes them into a
foreground program.
I.e., the _connect/ program forces the player to execute some command that you
otherwise keep very hard to guess, like
@##processlogin

Which then calls the actual forground program you're interested in.

Not 100% sure if that will work because I can't remember if programs called via
@force CAN execute in foreground, but I'm pretty sure they can.

-Akari

--- In protomuck@yahoogroups.com, "Jonathan Piacenti" <kelketek@...> wrote:
>
> On my server, I have a couple of _connect programs, but their output
> is always displayed before the player sees the room's @desc and @suc,
> rather than after. This makes the notification get lost up in the
> text. Is there a way, other than a sleep delay, to get the messages to
> display after the look?
>
Is there any reason that a sleep deplay won't work? That's what I've always done
personally.

I'm not sure if there's any way to query the 'pending text queue' on a
descriptor to such a degree that it would be any more useful than just tossing
in a '1 sleep' off hand.

-Akari

Hey there!

Just moved my MUCK from a windows machine to a Linux one. Problem is I can't get
SSL to work. I've tried using ./configure --with-ssl and #define USE_SSL, but
either/both don't seem to work.

The Pueblo port opens up fine, as does the standard one. If I change the @tune
for the pueblo port to the port I want SSL on, it opens up, so I know it's not
the firewall blocking 8802 (the desired SSL port) it just doesn't open. I've
added the port to muck.config in the $SSLPORT variable, and tried to start it by
entering the ports manually in the command line. It just doesn't seem to be
working.

Any clue what might be wrong?

I have a few programs that I'd like to force the player to enter an interactive
mode for as soon as he connects, specifically to ensure proper player setup,
beginner's tutorial, etc. But the helpfile shows, and my attempts to work
otherwise prove, that _connect, and _arrive programs are forced into Background
mode as soon as they start, making reads impossible. How do I fix this, or allow
programs to be run in the foreground?

On my server, I have a couple of _connect programs, but their output
is always displayed before the player sees the room's @desc and @suc,
rather than after. This makes the notification get lost up in the
text. Is there a way, other than a sleep delay, to get the messages to
display after the look?

8192 is very precise, precisely 2^13

--- In protomuck@yahoogroups.com, Kelketek Rritaa <kelketek@...> wrote:
>
> 8192? That's an awfully precise number.
> -----Original Message-----
> From: Alynna Trypnotk <alynna@...>
>
> Date: Fri, 13 Feb 2009 10:07:43
> To: <protomuck@yahoogroups.com>
> Subject: re: [Protomuck] Speed up MUF execution
>
>
>
> > Wow, then 100 really is low! Guess I'll crank that sucker up.
> >
> > ------------------------------------------------------------------
------
> > From:
> > Date: Mon, 9 Feb 2009 11:21:56 -0600
> > To: <protomuck@yahoogroups.com>
> > Subject: Re: [protomuck] Speed up MUF execution
> >
> > Hm, I think the default is usually 10,000 .... I believe mine are set to
> > 84,000. Try different values, you should be able to figure out where the
> > best spot is.
> >
> > -Michael
> > ----- Original Message -----
> > From: "Kelketek Rritaa" <kelketek@...
> <mailto:kelketek%40gmail.com>>
> > To: <protomuck@yahoogroups.com <mailto:protomuck%40yahoogroups.com>>
> > Sent: Monday, February 09, 2009 11:11 AM
> > Subject: Re: [protomuck] Speed up MUF execution
> >
> > > Ain't my program :-P These ones are found in the standard DB. but only
> > > 100 instructions per program default? I'd think my machine is fast
> > > enough to multiplex well enough with at least 2000. Probably more.
> > >
> > > Thanks!
> > >
> > > On Feb 9, 2009, at 11:04 AM, <hinoserm@...
> > <mailto:hinoserm%40protomuck.org>> wrote:
> > >
> > >> You may want to raise your instr_slice @tune, although at the point
> > >> where
> > >> the default is introducing delays you may want to rethink the
> > >> program design
> > >> first.
> > >>
> > >> -Michael
> > >> ----- Original Message -----
> > >> From: "Jonathan Piacenti" <kelketek@...
> > <mailto:kelketek%40gmail.com>>
> > >> To: <protomuck@yahoogroups.com <mailto:protomuck%40yahoogroups.com>>
> > >> Sent: Monday, February 09, 2009 10:18 AM
> > >> Subject: [protomuck] Speed up MUF execution
> > >>
> > >> Is there any way to speed up the execution of MUF programs? I'm using
> > >> a say replacement program and it's inducing a three second lag.
> > >> There's more than enough processing power on the machine to ensure
> > >> instantaneous execution, so what's the deal?
> >
> > instr_slice lower than 1000 is actually very bad, it doesn't actually
> > have anything to do with the speed the MUF executes itself, but it
> > does have everything to do with how often the MUF interpreter task
> > switches.
> >
> > at 100 the MUF interpreter will be spending about as much time
> > switching between MUF programs as it does executing them.
> >
> > A good value for this tune is 8192.   Lower numbers switch tasks more
> > often, which will affect the total speed of the programs running, in
> > favor of giving tasks time more often.  However at instr_slice=100,
> > about as much time will be spent in the scheduler as in the MUF
> > interpreter itself.  However very HIGH numbers (like 65000) will cause
> > MUF programs to become less and less fair about their time, another
> > words it could spend a very long time in a single program and other
> > programs will get slower and experience delays..
> >
>

> Wow, then 100 really is low! Guess I'll crank that sucker up.
>
> ------------------------------------------------------------------------
> From:
> Date: Mon, 9 Feb 2009 11:21:56 -0600
> To: <protomuck@yahoogroups.com>
> Subject: Re: [protomuck] Speed up MUF execution
>
> Hm, I think the default is usually 10,000 .... I believe mine are set to
> 84,000. Try different values, you should be able to figure out where the
> best spot is.
>
> -Michael
> ----- Original Message -----
> From: "Kelketek Rritaa" <kelketek@...
<mailto:kelketek%40gmail.com>>
> To: <protomuck@yahoogroups.com <mailto:protomuck%40yahoogroups.com>>
> Sent: Monday, February 09, 2009 11:11 AM
> Subject: Re: [protomuck] Speed up MUF execution
>
> > Ain't my program :-P These ones are found in the standard DB. but only
> > 100 instructions per program default? I'd think my machine is fast
> > enough to multiplex well enough with at least 2000. Probably more.
> >
> > Thanks!
> >
> > On Feb 9, 2009, at 11:04 AM, <hinoserm@...
> <mailto:hinoserm%40protomuck.org>> wrote:
> >
> >> You may want to raise your instr_slice @tune, although at the point
> >> where
> >> the default is introducing delays you may want to rethink the
> >> program design
> >> first.
> >>
> >> -Michael
> >> ----- Original Message -----
> >> From: "Jonathan Piacenti" <kelketek@...
> <mailto:kelketek%40gmail.com>>
> >> To: <protomuck@yahoogroups.com <mailto:protomuck%40yahoogroups.com>>
> >> Sent: Monday, February 09, 2009 10:18 AM
> >> Subject: [protomuck] Speed up MUF execution
> >>
> >> Is there any way to speed up the execution of MUF programs? I'm using
> >> a say replacement program and it's inducing a three second lag.
> >> There's more than enough processing power on the machine to ensure
> >> instantaneous execution, so what's the deal?
>
> instr_slice lower than 1000 is actually very bad, it doesn't actually
> have anything to do with the speed the MUF executes itself, but it
> does have everything to do with how often the MUF interpreter task
> switches.
>
> at 100 the MUF interpreter will be spending about as much time
> switching between MUF programs as it does executing them.
>
> A good value for this tune is 8192.   Lower numbers switch tasks more
> often, which will affect the total speed of the programs running, in
> favor of giving tasks time more often.  However at instr_slice=100,
> about as much time will be spent in the scheduler as in the MUF
> interpreter itself.  However very HIGH numbers (like 65000) will cause
> MUF programs to become less and less fair about their time, another
> words it could spend a very long time in a single program and other
> programs will get slower and experience delays..
>

Hm, I think the default is usually 10,000 .... I believe mine are set to
84,000.  Try different values, you should be able to figure out where the
best spot is.

-Michael
----- Original Message -----
From: "Kelketek Rritaa" <kelketek@...>
To: <protomuck@yahoogroups.com>
Sent: Monday, February 09, 2009 11:11 AM
Subject: Re: [protomuck] Speed up MUF execution


> Ain't my program :-P These ones are found in the standard DB. but only
> 100 instructions per program default? I'd think my machine is fast
> enough to multiplex well enough with at least 2000. Probably more.
>
> Thanks!
>
> On Feb 9, 2009, at 11:04 AM, <hinoserm@...> wrote:
>
>> You may want to raise your instr_slice @tune, although at the point
>> where
>> the default is introducing delays you may want to rethink the
>> program design
>> first.
>>
>> -Michael
>> ----- Original Message -----
>> From: "Jonathan Piacenti" <kelketek@...>
>> To: <protomuck@yahoogroups.com>
>> Sent: Monday, February 09, 2009 10:18 AM
>> Subject: [protomuck] Speed up MUF execution
>>
>> Is there any way to speed up the execution of MUF programs? I'm using
>> a say replacement program and it's inducing a three second lag.
>> There's more than enough processing power on the machine to ensure
>> instantaneous execution, so what's the deal?
>>
>>
>>
>
>

You may want to raise your instr_slice @tune, although at the point where
the default is introducing delays you may want to rethink the program design
first.

-Michael
----- Original Message -----
From: "Jonathan Piacenti" <kelketek@...>
To: <protomuck@yahoogroups.com>
Sent: Monday, February 09, 2009 10:18 AM
Subject: [protomuck] Speed up MUF execution


Is there any way to speed up the execution of MUF programs? I'm using
a say replacement program and it's inducing a three second lag.
There's more than enough processing power on the machine to ensure
instantaneous execution, so what's the deal?

Is there any way to speed up the execution of MUF programs? I'm using
a say replacement program and it's inducing a three second lag.
There's more than enough processing power on the machine to ensure
instantaneous execution, so what's the deal?

Argo can't compile in PROTO (To the best of my ability), Have been
trying for months, off and on, to install it... I think $lib/standerd
has .tell and .otell

- to install it...-- In protomuck@yahoogroups.com, "markastanhope"
<mark@...> wrote:
>
> Does anyone know of where I can get a number of muf macros? In
> particular I am looking for .tell and .otell.
>
> Also if anyone has a database with just the argo system loaded that
> they are prepared to unload that would be really useful.
>
> Mark
>

> Wow, that'll teach me not to just grab something off
> Sourceforge.  Sadly
> this version seems to have identical problems, with the
> detaching from
> the console and whatnot.  I'm baffled.

Interesting.  I seem to recall having a similar problem at some point, but I
don't recall how it was fixed.  If I recall correctly, it had something to do
with the database, or lack thereof.  You may wish to double-check that your
database is valid, or try a different database (e.g. the stock database, which
may or may not be on protomuck.twu.net).  You may also try to connect anyway,
just to be certain the process doesn't exist.  Make sure you use 'ps -A' to
check for it, as 'ps' alone won't list it.

Re: the previous comments regarding muck.conf, you need to make that executable
(chmod 755, I believe) and insert ./muck.conf at the head of the restart script.
That avoids needing to have the environment variables inside the .bashrc file.

Let me know if any of that helps!

Cheers,
  - Kal Zarius




       __________________________________________________________________
Instant Messaging, free SMS, sharing photos and more... Try the new Yahoo!
Canada Messenger at http://ca.beta.messenger.yahoo.com/

Kalvin Zarius wrote:
>
> ProtoMUCK 1.81b3, eh?  Not sure what the issue is, although it does sound
similar to some of the problems I had at some point.  Before you go any further,
though, you might want to try using a more recent version of ProtoMUCK.  I'd
point you to the website, except it seems to be on fritz again.  Thankfully,
Google's cache revealed where to download them from:  http://protomuck.twu.net
>
> Go ahead and grab yourself ProtoMUCK 2, beta 8.25.  It may work for you
better.

Wow, that'll teach me not to just grab something off Sourceforge.  Sadly
this version seems to have identical problems, with the detaching from
the console and whatnot.  I'm baffled.


--
Doklands - http://cyberinsekt.livejournal.com

So...

I'm kinda bored playing around with a lab setup of protoMUCK...

I'm trying to figure out how to run @fixwizbits.

I tried typing @fixwizbits Convert Mucker Levels , but it just
replies, What's the magic phrase?

How can I witness this fireball of death the help file so pleads with
me not to unleash?

> (<MUCKNAME> on port <MAINPORT> from
> <MUCKDB>): ProtoMUCK 1.81b3 now
> detaching from console.

ProtoMUCK 1.81b3, eh?  Not sure what the issue is, although it does sound
similar to some of the problems I had at some point.  Before you go any further,
though, you might want to try using a more recent version of ProtoMUCK.  I'd
point you to the website, except it seems to be on fritz again.  Thankfully,
Google's cache revealed where to download them from:  http://protomuck.twu.net

Go ahead and grab yourself ProtoMUCK 2, beta 8.25.  It may work for you better.

Cheers,
  - Kal Zarius


       __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

Kelketek Rritaa wrote:
> Check the logs. Paste what they say here.

Thanks again for your help with this.  None of this looks to be terribly
illuminating, but here you go:

protomuck
> Max FDs = 1024

protomuck.err
> LOAD: /home/vpadmin/proto/game/data/proto.db
> LOAD: /home/vpadmin/proto/game/data/proto.db (done)
> INIT: external host resolver started
> Checking objects 0 to 1...
> Searching for orphan objects...
> Done.

status
> 12/17/08 12:18:37: INIT: ProtoMUCK 1.81b3 starting as pid 14450.
> 12/17/08 12:18:37: init_game
> 12/17/08 12:18:37: INIT: Macro storage file muf/macros is tweaked.
> 12/17/08 12:18:37: init_game: macro file loaded
> 12/17/08 12:18:37: init_game/db_free
> 12/17/08 12:18:37: init_game/init_primitives: MUF initialized
> 12/17/08 12:18:37: init_game/mesg_init: MPI initialized
> 12/17/08 12:18:37: init_game: random number generator initialized
> 12/17/08 12:18:37: init_game: loaded parmfile.cfg
> 12/17/08 12:18:37: LOAD: /home/vpadmin/proto/game/data/proto.db
> 12/17/08 12:18:37: LOAD: /home/vpadmin/proto/game/data/proto.db (done)
> 12/17/08 12:18:37: Opening port: 5080
> 12/17/08 12:18:37:         Sock: 4
> 12/17/08 12:18:37: Opening port: 5081
> 12/17/08 12:18:37:         Sock: 5
> 12/17/08 12:18:37: Opening port: 5082
> 12/17/08 12:18:37:         Sock: 6

--
Doklands - http://cyberinsekt.livejournal.com

Kelketek Rritaa wrote:
> You should use the ./restart script, even if the MUCK isn't already running.
See what happens then.

Still the same message.  Nothing seems to be running in the background
either.  I should probably contact the host about this, see if there's
something I'm missing.

Not sure why, but each attempt to start it creates protomuck.pid files
in both ~/proto/game and ~/proto if that rings any bells.

--
Doklands - http://cyberinsekt.livejournal.com

You should use the ./restart script, even if the MUCK isn't already running. See
what happens then.
-----Original Message-----
From: Pete Strover <doklands@...>

Date: Wed, 17 Dec 2008 15:45:45
To: <protomuck@yahoogroups.com>
Subject: Re: [protomuck] Trouble compiling on Debian


Kelketek Rritaa wrote:
> Create a muck.conf file in the same directory as restart with contents similar
to these (this is what's in mine)
>
>
> MUCKDB="proto.db"
> MUCKOUT="proto.out"
> MAINPORT="8888"
> MOREPORTS=""
> PUEBLOPORT="8823"
> SSLPORT="8802"
> ADMINEMAIL=your@...
> STARTDB=0
>
> I think that's all you need. You may want to adjust the variables so they are
specific to your system.

Thank you for setting me on the right path.  That didn't work for me,
but defining them and exporting them in my .bashrc did.  However, it's
left me with another problem.  On running ./proto start I now get the
message:

(<MUCKNAME> on port <MAINPORT> from <MUCKDB>): ProtoMUCK 1.81b3 now
detaching from console.

And protomuck doesn't show amongst the active processes when I examine
them with ps.  Any idea what might have happened there?

Thanks again.


--
Doklands - http://cyberinsekt.livejournal.com

------------------------------------

Yahoo! Groups Links

Kelketek Rritaa wrote:
> Create a muck.conf file in the same directory as restart with contents similar
to these (this is what's in mine)
>
>
> MUCKDB="proto.db"
> MUCKOUT="proto.out"
> MAINPORT="8888"
> MOREPORTS=""
> PUEBLOPORT="8823"
> SSLPORT="8802"
> ADMINEMAIL=your@...
> STARTDB=0
>
> I think that's all you need. You may want to adjust the variables so they are
specific to your system.

Thank you for setting me on the right path.  That didn't work for me,
but defining them and exporting them in my .bashrc did.  However, it's
left me with another problem.  On running ./proto start I now get the
message:

(<MUCKNAME> on port <MAINPORT> from <MUCKDB>): ProtoMUCK 1.81b3 now
detaching from console.

And protomuck doesn't show amongst the active processes when I examine
them with ps.  Any idea what might have happened there?

Thanks again.


--
Doklands - http://cyberinsekt.livejournal.com

I've managed to get Proto compiled on the Debian system that I'm using
as a host after only a few hitches.  It seems gcc couldn't find all of
the requisite header files, but copying found versions into src/inc
seemed to do the job.  Also had to manually move the protomuck
executable for some reason.

The problem I'm currently facing is that some of the variables needed
by the restart script don't seem to be defined.  For instance, when I
type "echo $MUCKOUT" I just get a blank line, and without these it's
proving impossible to get the game running.  Anyone with more
experience of Debian or Proto got a solution for this?

Thanks in advance.

Yeah, It works when I connect from home. I was a bad kitty and tried
to grab the latest server code while waiting for a build at work. The
corporate firewall must not like outbound connection attempts to port
8080.

--- In protomuck@yahoogroups.com, "Jonathan Piacenti" <jonathan@...>
wrote:
>
> You need to type the www explicitly.
>
> http://www.protomuck.org:81
>
> Their DNS is whack.
>
> --- In protomuck@yahoogroups.com, Ryan Fitzgerald <kalzarius@> wrote:
> >
> > I had trouble accessing the website once.� My firewall was
> configured to only allow my web browser to use the http port (80), and
> so it couldn't communicate with the site at all.
> >
> > �- Kalzarius
> >
> > --- On Fri, 8/15/08, Furry StarCat <furrystarcat@> wrote:
> > From: Furry StarCat <furrystarcat@>
> > Subject: [protomuck] Re: Is the Web Site dead?
> > To: protomuck@yahoogroups.com
> > Received: Friday, August 15, 2008, 12:45 PM
> >
> > *headshakes* Still no dice...
> >
> > --- In protomuck@yahoogroups.com, "seoman_tv" <seoman@>
> > wrote:
> > >
> > > Try http://protomuck.org:81/
> > >
> > > --- In protomuck@yahoogroups.com, "Furry StarCat"
> > <furrystarcat@>
> > > wrote:
> > > >
> > > > Okays... I pinged the server, and it seems to be alive. It
shares an
> > > > IP with "Alynna's Webpage" (aka kitsunet.net,
> > faefox.org).
> > > >
> > > > In the meantime, can anyone provide a link to somewhere I can
get my
> > > > paws on a copy of the latest source code and Windows build?
> > > >
> > > > --- In protomuck@yahoogroups.com, "Furry StarCat"
> > <furrystarcat@>
> > > > wrote:
> > > > >
> > > > > I haven't been able to get on protomuck.org for a while
> > (order of
> > > > > months)... Is it gone for good, or just temporarily unavailable?
> > > > >
> > > >
> > >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
__________________________________________________________________
> > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark
> your favourite sites. Download it now at
> > http://ca.toolbar.yahoo.com.
> >
>

Hello all, I recently had a hard drive crash on my mac, which required
me to reinstall everything.  Oddly enough, I had a running MUCK server
on my mac before it crashed, but now I can't get the code to compile.
  I've tried the source available on sourceforge and the web site, but
neither works.

I followed the instructions in config.h for Macs, and these did not
seem to help.  I've got Xcode as well, so that shouldn't be the issue.

Here's what it says before giving up during a compile:

p_socket.c:50: error: conflicting types for `socklen_t'
/usr/include/sys/socket.h:108: error: previous declaration of
`socklen_t' was here
p_socket.c: In function `prim_sockcheck':
p_socket.c:700: warning: pointer targets in passing argument 5 of
`getsockopt' differ in signedness
p_socket.c: In function `prim_sockaccept':
p_socket.c:888: warning: pointer targets in passing argument 3 of
`accept' differ in signedness
make: *** [p_socket.o] Error 1


Here are some warnings it spits out while compiling other files:

p_file.c: In function `prim_send_binary':
p_file.c:1325: warning: pointer targets in passing argument 2 of
`notify_descriptor_raw' differ in signedness

disassem.c:124:42: warning: trigraph ??) ignored, use -trigraphs to enable
disassem.c:127:42: warning: trigraph ??) ignored, use -trigraphs to enable
inst.c:263:31: warning: trigraph ??< ignored, use -trigraphs to enable


Any help would be appreciated!

You need to type the www explicitly.

http://www.protomuck.org:81

Their DNS is whack.

--- In protomuck@yahoogroups.com, Ryan Fitzgerald <kalzarius@...> wrote:
>
> I had trouble accessing the website once.  My firewall was
configured to only allow my web browser to use the http port (80), and
so it couldn't communicate with the site at all.
>
>  - Kalzarius
>
> --- On Fri, 8/15/08, Furry StarCat <furrystarcat@...> wrote:
> From: Furry StarCat <furrystarcat@...>
> Subject: [protomuck] Re: Is the Web Site dead?
> To: protomuck@yahoogroups.com
> Received: Friday, August 15, 2008, 12:45 PM
>
> *headshakes* Still no dice...
>
> --- In protomuck@yahoogroups.com, "seoman_tv" <seoman@>
> wrote:
> >
> > Try http://protomuck.org:81/
> >
> > --- In protomuck@yahoogroups.com, "Furry StarCat"
> <furrystarcat@>
> > wrote:
> > >
> > > Okays... I pinged the server, and it seems to be alive. It shares an
> > > IP with "Alynna's Webpage" (aka kitsunet.net,
> faefox.org).
> > >
> > > In the meantime, can anyone provide a link to somewhere I can get my
> > > paws on a copy of the latest source code and Windows build?
> > >
> > > --- In protomuck@yahoogroups.com, "Furry StarCat"
> <furrystarcat@>
> > > wrote:
> > > >
> > > > I haven't been able to get on protomuck.org for a while
> (order of
> > > > months)... Is it gone for good, or just temporarily unavailable?
> > > >
> > >
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>
>       __________________________________________________________________
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark
your favourite sites. Download it now at
> http://ca.toolbar.yahoo.com.
>

I have added two new programs to the files section.

cmd-su allows you to switch users during a session.

cmd-ls is a content lister similar to (but not exactly like) its UNIX
counterpart.

ATM has also been updated.  It has a couple of bugfixes.

As always, feedback is appreciated.