Exits

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Exits

pizza29965
Well, I am going to implement a full flying capability, but I need some way to have up exits
that are only accessible via flying, and rooms where you can and can't fly, and rooms where
you can and can't land.

If you could get back to me on this it would be nice.

Reply | Threaded
Open this post in threaded view
|

Re: Exits

DaftPun
On both this question and the last, what have you tried so far. I find both of the posts a bit vague to be able to work with. If you are able to inform us on what you have tried so far, we may be able to better steer you in the right direction for a solution to both of your problems.

Daftpun

--- On Thu, 9/11/08, pizza29965 <[hidden email]> wrote:
From: pizza29965 <[hidden email]>
Subject: [nakedmud] Exits
To: [hidden email]
Date: Thursday, September 11, 2008, 5:32 PM










   
            Well, I am going to implement a full flying capability, but I need some way to have up exits

that are only accessible via flying, and rooms where you can and can't fly, and rooms where

you can and can't land.



If you could get back to me on this it would be nice.




     

   
   
       
         
       
       








       


       
       


     
Reply | Threaded
Open this post in threaded view
|

Re: Exits

pizza29965
Well, sorry about being vague, but mostly I need a starting point for implementing florgan,
it is a very powerful ability, so it is a very nonspecific ability.  I mostly just want to know
how I would go about rerouting all output to go to multiple people and input to change to
someone else, it is essentially like making one person become the other one.

On the flying, I want an eventual result of being able to fly outside but maybe not in the
store or blacksmith, and when flying in a room being able to fly upwards, but only when
flying.  Also, I would like a semi reversed capability of not being able to land when up in a
room above ground, unless on the clouds, or something like that, plus I'm not sure If I
want people standing in a room be able to see the exit going upwards that you can only
use when flying.

Thanks for your help, and once again sorry about being vague, I just come up with ideas in
my head and add them to an html file all the time or something like that and then work
with that to expand the game.

If you want to check it out just go to the NeeJean website at www.neejean.org and go to
the NUNs tab at the top, where you will find the IP address, and the port is always 6255,
and if you want to you can download the Dungeon Valley Flash Client that automatically
checks the website for the address to connect.  I have made great strides with this client,
implementing color, command history, and an auto do function similar to the auto say
function in MUSHClient except you type whatever it is you want in the first box the append
to what you put in the second box.  I hope to eventually add triggers and aliases and
maybe timers to the flash client as well, and eventually an open version that lets you
connect to any mud you want.

If you do decide to come and join our mud keep in mind we don't yet have combat, but I
have implemented different races and made them actually seem more important by
changing the command structure slightly to make race specific commands.  It is also just a
rather funny and semi fun (or at least will most certainly be fun when finished) mud.

--- In [hidden email], DaftPun <daftpun@...> wrote:
>
> On both this question and the last, what have you tried so far. I find both of the posts a
bit vague to be able to work with. If you are able to inform us on what you have tried so
far, we may be able to better steer you in the right direction for a solution to both of your
problems.

>
> Daftpun
>
> --- On Thu, 9/11/08, pizza29965 <pizza29965@...> wrote:
> From: pizza29965 <pizza29965@...>
> Subject: [nakedmud] Exits
> To: [hidden email]
> Date: Thursday, September 11, 2008, 5:32 PM
>
>
>
>
>
>
>
>
>
>
>    
>             Well, I am going to implement a full flying capability, but I need some way to
have up exits
>
> that are only accessible via flying, and rooms where you can and can't fly, and rooms
where
>
> you can and can't land.
>
>
>
> If you could get back to me on this it would be nice.
>



Reply | Threaded
Open this post in threaded view
|

Re: Re: Exits

Jon Whitehouse


> how I would go about rerouting all output to go to multiple people   
> and input to change to
> someone else, it is essentially like making one person become the other one.

   This sounds like what ROM uses via snoop. However, being able to  
control someone elses character.. hrm. Take a look at snoop on ROM and  
maybe it will give you some ideas on how to accomplish that.

   > On the flying, I want an eventual result of being able to fly 
> outside but maybe not in the
> store or blacksmith, and when flying in a room being able to fly   
> upwards, but only when
> flying.  Also, I would like a semi reversed capability of not being   
> able to land when up in a
> room above ground, unless on the clouds, or something like that, 

   This one is easy. I'd just create room flags (FLY_ONLY and  
NO_FLYING)  then when the character IS_AFFECTED by flying check the  
room and for when not affected, have the condition checked before a  
character enters a room. I did this in ROM and it was pretty simple.  
Shouldn't be too difficult to implement in nakedmud.


Reply | Threaded
Open this post in threaded view
|

Re: Exits

pizza29965
--- In [hidden email], Jon Whitehouse <jon@...> wrote:

>
>
>
> > how I would go about rerouting all output to go to multiple people   
> > and input to change to
> > someone else, it is essentially like making one person become the other one.
>
>    This sounds like what ROM uses via snoop. However, being able to  
> control someone elses character.. hrm. Take a look at snoop on ROM and  
> maybe it will give you some ideas on how to accomplish that.
That isn't what I want, the florgan is not unlimited really, there is only a limited amount,
and I just want to know my way around the I/O interface of NakedMud

>
>    > On the flying, I want an eventual result of being able to fly 
> > outside but maybe not in the
> > store or blacksmith, and when flying in a room being able to fly   
> > upwards, but only when
> > flying.  Also, I would like a semi reversed capability of not being   
> > able to land when up in a
> > room above ground, unless on the clouds, or something like that, 
>
>    This one is easy. I'd just create room flags (FLY_ONLY and  
> NO_FLYING)  then when the character IS_AFFECTED by flying check the  
> room and for when not affected, have the condition checked before a  
> character enters a room. I did this in ROM and it was pretty simple.  
> Shouldn't be too difficult to implement in nakedmud.
>
That is the easy part, I already know how to really, I was really just looking for more exact
instructions so I wouldn't have to spend as much time working on it.  And what I really
wanted to know is how to create an exit that is only usable when you are in a certain
position.

Sorry about not posting sooner, our internet died.



Reply | Threaded
Open this post in threaded view
|

Re: Re: Exits

Mat Allen
Still, checking out ROM's snoop command would be a good start.  It shows
routing output that normally goes to just one player to go to other players
as well.  It's important that you distinguish between characters (the
players in the game) and descriptors (the player's socket/connection).  A
character is essentially a souped-up mob, with a descriptor attached so that
when something happens to the character it gets sent to the descriptor (the
socket; i.e. over the network).  When you send something to character Bob,
it basically goes, "is Bob a character and not a mobile?"; if yes: "does Bob
have a descriptor?" (this would be a no if, for example, Bob was linkdead);
if yes, send that output to that descriptor.  You basically want to add in:
"if anyone else is configured to receive this character's output, send it to
them too".  So each character might want to have a list of "snoopers" (other
descriptors) in addition to their primary descriptor.

Rerouting input: In this case check out ROM's switch command (I think it's
switch...).  In ROM, switch detaches the descriptor from the player using it
and attaches it to a mob (who, before this, has no descriptor).  Basically
the mob is an empty shell, and the player hooks their I/O (their descriptor)
to the mob, leaving their character body as an empty shell, like a mob.  ROM
doesn't allow messing around with active players' descriptors, you can't
switch into a player, so your idea is a bit different.  But, since you only
want to switch input from one character to another (no one player sending
input to multiple chars/mobs in the game), essentially what you want to do
is swap character A's descriptor with character B's descriptor so they are
controlling one another's character.

As for the exits... be brave, change some stuff around, keep backups in case
you mess something up.  Sometimes the simplest answer is best... if you want
to be able to say a room is flying only or no flying, do what he said, add
flags for FLY_ONLY and NO_FLY that rooms can have, and in the functions that
run when you try to move, add in a check for those things.  For exits that
only appear if you're flying you'd maybe want to add a (separate) FLY_ONLY
flag for exits, then find the function that shows the list of exits, and
only add the FLY_ONLY exits to the list if the character is flying.  It's
hard for us to answer questions very specifically, otherwise we'd be doing
the coding for you.  Every case is different so you'll have to try your own
solutions.

Try coding more stuff in C and python, from scratch, just toy projects,
anything you want. It will hone your problem solving skills so answers seem
more obvious in the future.

Vaz

On Tue, Sep 16, 2008 at 8:55 PM, pizza29965 <[hidden email]> wrote:

>   --- In [hidden email] <nakedmud%40yahoogroups.com>, Jon
> Whitehouse <jon@...> wrote:
> >
> >
> >
> > > how I would go about rerouting all output to go to multiple people
> > > and input to change to
> > > someone else, it is essentially like making one person become the other
> one.
> >
> > This sounds like what ROM uses via snoop. However, being able to
> > control someone elses character.. hrm. Take a look at snoop on ROM and
> > maybe it will give you some ideas on how to accomplish that.
> That isn't what I want, the florgan is not unlimited really, there is only
> a limited amount,
> and I just want to know my way around the I/O interface of NakedMud
>
> >
> > > On the flying, I want an eventual result of being able to fly
> > > outside but maybe not in the
> > > store or blacksmith, and when flying in a room being able to fly
> > > upwards, but only when
> > > flying.  Also, I would like a semi reversed capability of not being
> > > able to land when up in a
> > > room above ground, unless on the clouds, or something like that,
> >
> > This one is easy. I'd just create room flags (FLY_ONLY and
> > NO_FLYING)  then when the character IS_AFFECTED by flying check the
> > room and for when not affected, have the condition checked before a
> > character enters a room. I did this in ROM and it was pretty simple.
> > Shouldn't be too difficult to implement in nakedmud.
> >
> That is the easy part, I already know how to really, I was really just
> looking for more exact
> instructions so I wouldn't have to spend as much time working on it. And
> what I really
> wanted to know is how to create an exit that is only usable when you are in
> a certain
> position.
>
> Sorry about not posting sooner, our internet died.
>
>  
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: Exits

Kevin Morgan
Writing the functions to assign a socket to another object is something not
going to be easily discussed here unless someone just wants to tackle it.
Using a snoop concept control via Python is much much easier.



I am going to be very general, but I have created this type of system for
LPC systems before to make user spells since I found that switching the
socket to the object was too powerful -- we will call the ability
"ghosting" and assume it's admin level but you can do what you want.



Create a command called ghost, when the ghost <user> command is called have
it generate a temporary variable on the user called "ghosted_by" with the
name of the ghoster (user taking over) in it. Also have it set a var on the
ghoster called "ghosting" with the name of the user being ghosted.


Now, create a hook for process_outbound_data (text?), for an example of
this look at colour.py -- you could just restructure, have the hook called
"pre_process_data" and have it call the colour processing and ghosting
functions, or whatever. For this discussion we'll just build it into the
colour processing section:



In that hook check the ghosted_by variable, and if the ghoster is logged
in, then add "{RGHOST>{n " to the beginning of that data and sent it to the
ghoster, continue (right here you could end out of the function and keep
the ghosted user blind, or continue the function and allow them to see). If
the ghoster is not online, clear ghosted_by.



 Create a hook for the command parser, this will require a tiny bit of
tweaking C code to create the hook, I can't be certain -- but what you want
is to hook the command parser and check if the user has ghosted_by set.. if
they do, then whenever they type a command ignore it. If the user has
"ghosting" set then check if the ghosted person has "ghosted_by" set, if
they don't clear "ghosting" and continue. If they do, then force the
command to that user.



Now create one more command called "exorcise" or whatever and have it
remove the "ghosted_by" variable off the user. Since a user with
"ghosted_by" set cannot type commands they won't be able to do it, and
since the hook for the command parser checks that before forcing commands,
this will cause the ghoster to stop ghosting.



This will leave the ghoster in their original position, unable to move
while quasi-inhabiting another player. The ghoster will see their own
information and the screen input of the ghosted.



GHOST> Donna says: Whassup?

Jake says: Anybody home?

> say I'm here!!

GHOST> You say: I'm here!!

GHOST> Donna says: Huh?

Jake says: Hello?



Interesting addons:



1. Move the player to a safe-room silently while they are ghosting and
return them to their spot upon unghosting.

2. Error checking. You don't want to ghost a ghoster.. this could be an
endless recursion and mass confusion.

3. Timers for ghosting.



Hope that gets your creative juices flowing.





Create a variable on the user





> ----- Original Message -----
> From: Mat Allen
> Sent: 09/17/08 08:31 am
> To: [hidden email]
> Subject: Re: [nakedmud] Re: Exits
>
> Still, checking out ROM's snoop command would be a good start.  It shows
> routing output that normally goes to just one player to go to other
> players as well.  It's important that you distinguish between characters
> (the players in the game) and descriptors (the player's
> socket/connection).  A character is essentially a souped-up mob, with a
> descriptor attached so that when something happens to the character it
> gets sent to the descriptor (the socket; i.e. over the network).  When
> you send something to character Bob, it basically goes, "is Bob a
> character and not a mobile?"; if yes: "does Bob have a descriptor?" (this
> would be a no if, for example, Bob was linkdead); if yes, send that
> output to that descriptor.  You basically want to add in: "if anyone
> else is configured to receive this character's output, send it to them
> too".  So each character might want to have a list of "snoopers" (other
> descriptors) in addition to their primary descriptor.
>
> Rerouting input: In this case check out ROM's switch command (I think
> it's switch...).  In ROM, switch detaches the descriptor from the player
> using it and attaches it to a mob (who, before this, has no
> descriptor).  Basically the mob is an empty shell, and the player hooks
> their I/O (their descriptor) to the mob, leaving their character body as
> an empty shell, like a mob.  ROM doesn't allow messing around with
> active players' descriptors, you can't switch into a player, so your idea
> is a bit different.  But, since you only want to switch input from one
> character to another (no one player sending input to multiple chars/mobs
> in the game), essentially what you want to do is swap character A's
> descriptor with character B's descriptor so they are controlling one
> another's character.
>
> As for the exits... be brave, change some stuff around, keep backups in
> case you mess something up.  Sometimes the simplest answer is best... if
> you want to be able to say a room is flying only or no flying, do what he
> said, add flags for FLY_ONLY and NO_FLY that rooms can have, and in the
> functions that run when you try to move, add in a check for those
> things.  For exits that only appear if you're flying you'd maybe want to
> add a (separate) FLY_ONLY flag for exits, then find the function that
> shows the list of exits, and only add the FLY_ONLY exits to the list if
> the character is flying.  It's hard for us to answer questions very
> specifically, otherwise we'd be doing the coding for you.  Every case is
> different so you'll have to try your own solutions.
>
> Try coding more stuff in C and python, from scratch, just toy projects,
> anything you want. It will hone your problem solving skills so answers
> seem more obvious in the future.
>
> Vaz
>
> On Tue, Sep 16, 2008 at 8:55 PM, pizza29965 <[hidden email]> wrote:
>
> >                
> > --- In [hidden email], Jon Whitehouse <jon@...> wrote:
> > >
> > >
> > >
> > > > how I would go about rerouting all output to go to multiple
> > people   
> > > > and input to change to
> > > > someone else, it is essentially like making one person become the
> > other one.
> > >
> > >    This sounds like what ROM uses via snoop. However, being able to  
> > > control someone elses character.. hrm. Take a look at snoop on ROM
> > and  
> > > maybe it will give you some ideas on how to accomplish that.
> > That isn't what I want, the florgan is not unlimited really, there is
> > only a limited amount,
> > and I just want to know my way around the I/O interface of NakedMud
> >
> > >
> > >    > On the flying, I want an eventual result of being able to fly 
> > > > outside but maybe not in the
> > > > store or blacksmith, and when flying in a room being able to fly   
> > > > upwards, but only when
> > > > flying.  Also, I would like a semi reversed capability of not
> > being   
> > > > able to land when up in a
> > > > room above ground, unless on the clouds, or something like that, 
> > >
> > >    This one is easy. I'd just create room flags (FLY_ONLY and  
> > > NO_FLYING)  then when the character IS_AFFECTED by flying check the  
> > > room and for when not affected, have the condition checked before a  
> > > character enters a room. I did this in ROM and it was pretty simple.  
> > > Shouldn't be too difficult to implement in nakedmud.
> > >
> > That is the easy part, I already know how to really, I was really just
> > looking for more exact
> > instructions so I wouldn't have to spend as much time working on it.  
> > And what I really
> > wanted to know is how to create an exit that is only usable when you
> > are in a certain
> > position.
> >
> > Sorry about not posting sooner, our internet died.
> >
> >          
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Re: Exits

Geoff Hollis
In reply to this post by pizza29965
On Sep 16, 2008, at 7:55 PM, pizza29965 wrote:

> And what I really
> wanted to know is how to create an exit that is only usable when  
> you are in a certain
> position.


def chk_exit_pos(ch, cmd):
     # check constraints here,
     # probably status info about the current or destination room and  
your position

     if not constraints_are_met:
         ch.send("Some kind of warning message.")
         return False

for cmd in ["north", "west", "east", "south", "up", "down", "northwest",
             "northeast", "southwest", "southeast", "nw", "ne", "sw",  
"se"]:
     add_cmd_check(cmd, chk_exit_pos)

If it's a relatively weird check that will probably only matter for  
one or two rooms (e.g., my MUD only allows Archmasters into the 8th  
floor of the mage tower) you can design a scripted, interactive  
object (e.g., a glowing orb you have to "touch"), or simply overload  
the direction in the room's generation script and, if all the checks  
pass, redirect the input to the "real" direction command.

Reply | Threaded
Open this post in threaded view
|

Re: Exits

pizza29965
--- In [hidden email], Geoff Hollis <hollis@...> wrote:

>
> On Sep 16, 2008, at 7:55 PM, pizza29965 wrote:
>
> > And what I really
> > wanted to know is how to create an exit that is only usable when  
> > you are in a certain
> > position.
>
>
> def chk_exit_pos(ch, cmd):
>      # check constraints here,
>      # probably status info about the current or destination room and  
> your position
>
>      if not constraints_are_met:
>          ch.send("Some kind of warning message.")
>          return False
>
> for cmd in ["north", "west", "east", "south", "up", "down", "northwest",
>              "northeast", "southwest", "southeast", "nw", "ne", "sw",  
> "se"]:
>      add_cmd_check(cmd, chk_exit_pos)
>
> If it's a relatively weird check that will probably only matter for  
> one or two rooms (e.g., my MUD only allows Archmasters into the 8th  
> floor of the mage tower) you can design a scripted, interactive  
> object (e.g., a glowing orb you have to "touch"), or simply overload  
> the direction in the room's generation script and, if all the checks  
> pass, redirect the input to the "real" direction command.
>

Thanks you guys, I will have to try all your suggestions, I have been working in NakedMud
with Abyll for somewhere around between one, and one and a half years, and I know a lot
about the C and some of the Python by now, but Abyll loves Python and knows enough for
the both of us.

It is interesting, because we already have part of the control command implemented, you
control them, but you still control yourself, and you can't see what they see.  One really
cool intentional thing is that you can control mobs, and enemies, some of which will have
slightly unique commands.  Now I just need to know where the input and output are
handled in the C files and then I am good to go, all I needed was a starting point.

You may remember Abyll, he posted a while back about the pcedit command, we have the
Dungeon Valley mud.  It is interesting, because we have no domain linked to it, it
automatically finds the IP address required to connect, and uploads it to the NeeJean
website.  Then it is in a picture and a text file where a flash telnet client can automatically
connect and check the text file to see what the IP address is at that time.

The flying will be mostly in Python, and then I will use it as the starting point to implement
swimming for a different race.  I was going to have digging as well, but we decided against
it.  We have humans, and then three unique races I made up.  They are the Oshnak
(pronounced sort of like Ozjhnak) the Zutobu (we want to rename them, but we have to
think of a similar name that sounds cooler) and the Kidori (pronounced kee door ee).  The
Oshnak are the swimmers, the Zutobu are the flyers, and the Kidori are the diggers
(although they won't have a dig command, they will still have tunnels around the valley).

I think forums would be good, you should try invisionfree.com.  It is free and they are
pretty good.  I have forums there for the NeeJean.