www.rebol.org/advanced/multisession.r
Alternatively you could look at the code of my MUD: Monsters and Treasures.
It's sitting on a web/ftp site, I've just never thought of simply giving
out the address (in http form) for people to view it. In particular, the
"mod.players" module handles all the port stuff.
http://members.home.net/michael1356/files/montreas/
- Michael Jelinek
"Paul Tretter" <[EMAIL PROTECTED]>@rebol.com on 01/08/2001 09:07:18 AM
From: "Paul Tretter" <[EMAIL PROTECTED]>@rebol.com on 01/08/2001 09:07
AM
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: [REBOL] Re: Advanced port stuff
I believe what your doing with MUD is very similiar with what Im doing in
my
script. I got alot of help with this on IRC from other programmers where I
was able to do this in realtime and post results in the channel and get
good
feedback. I could not locate the multisession.r script from the site. If
anyone has it please forward to me as Im curious about the use of ports
within a block.
Paul Tretter
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 08, 2001 7:56 AM
Subject: [REBOL] Re: Advanced port stuff
>
> You might try checking out multisession.r on REBOL.org. I THINK it does
> this (associating literal words to port objects in a 'waitports list)...
>
> If not, what you might have to do is either do a 'find within the list of
> 'waitports, or keep a synchronized list (block) of literal words to match
> the 'waitports list.
>
> BTW to want this task does not imply that you have badly designed code
IMO
> - or even that a simpler solution exists. I do the same 'waitports list
> scheme in my MUD and given the complexity of the desired task I see no
way
> around it.
>
> Actually, what I do in the MUD (and I mention this because you may want
to
> do this also) is associate each 'port object in 'waitports with a client
> object (ie a "player" in my MUD). It would be nice if the 'port objects
> could point to (ie reference) the associated client object, but alas it
> doesn't and I haven't been brave enough to overuse one of the 'port
> elements to do this (don't even know if I COULD). SO, I create a
reference
> to the associated 'port object from the client object when the port is
> created. Then I perform an "ugly" loop through the client list to find
the
> matching client for a given 'port.
>
> - Michael Jelinek
>
>
>
>
>
> "Paul Tretter" <[EMAIL PROTECTED]>@rebol.com on 01/05/2001 08:53:46 AM
>
> From: "Paul Tretter" <[EMAIL PROTECTED]>@rebol.com on 01/05/2001 08:53
> AM
>
> Please respond to [EMAIL PROTECTED]
>
> Sent by: [EMAIL PROTECTED]
>
> To: <[EMAIL PROTECTED]>
> cc:
> Subject: [REBOL] Re: Advanced port stuff
>
>
> Ok, so far the answers relating to objects I have all ready known but
> appreciate your input. I think the complexity is that these objects are
> port objects that have been added to a block. The block is referenced by
> the
> word 'waitports. waitports contains the port objects which are appended
to
> it dynamically as the script runs. For example if waitports contained
> three
> port objects - then the following:
> >> print waitports
> ?port? ?port? ?port?
>
> ok print now this:
> >> print first waitports
> irc-open-port
>
> now I try moving the index to get the literal of the second port since
the
> first port responded correctly:
> waitports: next waitports
>
> >> print first waitports
> ?port?
>
> I notice that it shows only one ?port? instead of two and it didnt give
me
> the literal word referencing that port object. Is this a bug or is there
> new information we need to document regarding objects appended to blocks
> when they are port datatypes.
>
> As you can see this script deals with IRC. The first port in the block
is
> the port object for the irc server itself. The next port and subsequent
> ports are for dcc ports that are dynamically added to the block while the
> script is online and active on irc. These dcc ports objects are assigned
> to
> the nickname of the user on irc (since each user must have a unique
> nickname
> on the irc network). This assignment was done with this function in my
> script:
>
> dcc-parser: does [
> if secured [
> if dcc-chat-flag [
> dcc-client: message/nick
> dcc-client-port: message/dataparse/5
> dcc-connect: [
> scheme: 'tcp
> host: dcc-ip
> port-id: to-integer dcc-client-port
> ]
> either error? error-dcc-open-client: try [dcc-open-client:
> open/lines/direct/no-wait dcc-connect][
> error-dcc-open-client: disarm error-dcc-open-client
> error-proc error-dcc-open-client
> ][
> insert dcc-open-client read %help.txt
> dcctemp: :dcc-client
> dcctemp: make set-word! :dcctemp
> mold dcctemp :dcc-open-client
> append waitports get make word! copy :dcc-client
> dcc-chat-flag: off
> dcc-client-port: dcc-connect: none
>
> ]
> ]
> ]
> ]
>
> message/nick above is the object containing the nickname of the user from
> the ircparser function (not listed). As you can see from the third line
> from the bottom of the function the port is appended to waitports. The
> script does everything I want it to do. However, I am getting ready to
add
> more code to this function to perform some logic based on the literals
> within waitports block. Thats is what Im having trouble determining
since
> its dynamically assigned during execution. Hope this helps.
>
> Paul Tretter
>
>
>
>
> ----- Original Message -----
> From: "Andrew Martin" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, January 05, 2001 2:28 AM
> Subject: [REBOL] Re: Advanced port stuff
>
>
> > Elan wrote:
> > > 3. Your question bothers me. Why do you need to know which words
> reference
> > these objects? I suspect that there may be a conceptual bug involved in
> your
> > question. I.e. a more (REBOLlish) elegant = simpler solution may
prevent
> > this question from coming up altogether.
> >
> > I'd agree with this. It sounds like there's a design problem in the
> script
> > as the problem sounds confused.
> > Usually if you can write clearly what the problem is, the Rebol
code
> > becomes immediately apparent, as Rebol script "surfaces" in the
> description
> > of the problem. For example, in my earlier emails about the 'Fun
> function,
> > where Ladislav pointed out, IIRC, that 'fun needed to exclude
> Arguments--the
> > rebol script to solve the problem "surfaced" as:
> > Locals: exclude Locals Spec
> >
> > I hope that helps!
> >
> > Andrew Martin
> > ICQ: 26227169 http://members.nbci.com/AndrewMartin/
> > -><-
> >
> >
> > --
> > To unsubscribe from this list, please send an email to
> > [EMAIL PROTECTED] with "unsubscribe" in the
> > subject, without the quotes.
> >
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
>
>
>
>
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
