When we use switch to switch into a mob, we don't see all of the things we do when we are ourselves.  I heard it had something to do with putting a check for a descriptor or something.  I need someone to explain everything in detail for me.  Thanks.

[karlan]

What codebase are you asking about (although I imagine most handle this the same - just a guess)

My understanding of how circleMUD handles it is:
do_swicth (the actual command run) only transfers the descriptor to the targeted mob, none of the other information is copied across (flags, prompt, prefs...) this is done for simplicity, you could copy all these accross, OR have any of the checks (Look for an IS_NPC check) test if for a NPC, and if it is then test if it has the pointer to the original character, then use those settings. and that is all too much work.

does that help?

[jornel]

Mobs just don't enjoy the same quality of life as players.   Here are some of the major differences:

1) mobs don't receive ansi color
  Color is stripped out to make mprog trigger checks easier.

2) mobs don't autolook when they walk into a new room.
  In most games, mobs move around all the time. To send full room descriptions to all mobs moving every time is a lot of 'internal spam' that raises CPU usage needlessly - since mostly, mobs can't do anything with the info they would receive in a room description.

3) mobs don't receive player-based global channels (ex: ooc, auction)
  Again, same reason.  Mobs aren't known to bid on auctioned items, nor do they offer any items for sale.  And you almost never hear them participate in chat.

4) mobs don't even have the same 'SCORE'
  You don't believe me?  Switch into a mob and type SCORE.  Most of the personal stats that players see are kept in a structure called pcdata that mobs just don't have - which explains why you always see all these tests in the code involving IS_NPC(ch)


Hope this sheds some light.

[markizs]

Hmm. Switch to a mob. sounds interesting. Could do it by simply mobe_object(find_object(this_player(),"soul"),find _object(mob_name)) or somthing like that, LPC differs from mud to mud. And ofc mobs dont get ansi color cos its usualy coded in player.c they can still hear shouts and stuff ofc, becouse they are global. and ofc mobs get the same SCORE as players :)

well maybe you werent talking about lpmud at all, maybe you again forgot that there is somthing besides ur favored codebase :)

oh well :P

As you said, depends on the code. On most MudOS ran muds you can use the efun exec():

[code] exec(object to, object from);[/quote]

Which should handle that for you, of course you'll want a few checks for admin =) I'm not sure if I remember but Amylaar and LD drivers can use exec() as well. Makes it a whole lot easier to do things. Of course it sucks if you don't put checks on the command that calls it and exec() into a hammer object.

*chuckle*
b.t.w I put any color parsing data in simulefuns instead of in the objects =)

I am using ROM2.4b6, with color. But what I am talking about is that when we use switch, we don't see anything that goes on, no full descriptions, nothing that happens in the mud, the fights, nothing. It's just a prompt, and the room title. I read part of the FAQ at the ROM site, but it didn't help.

[karlan]

I Imagine ROM handles it in a fairly standard fashion, in those functions/sections there is probably a check something like IS_NPC(ch) or IS_MOB(ch) or something like this, if the condition (not really the right word) that indicates if a character is based on an index, or identitiy number then you are a mob regardless of if switched or not, if the check is based on the presence of a descriptor then switching into a mob would in effect turn that mob into a player (YES! I know there are other issues like the presence of pcdata/mobdata structures internal to it, but this is a simplified explanation)

For example - most of the colour handling routines I have seen have a check [code] if(!IS_NPC(ch)) {
  // parse the colour codes
} else {
  // strip the colour codes <-- really a parse too
}[/quote]
this is a trivial example, but if that check "IS_NPC" only checks for the condition/index/id/BIG_SIGN/whatever that marks it as a mob it will always strip the codes. If IS_NPC checks for a descriptor then it would parse the codes, BUT then you get issues with having to copy prefernecs and so on <- see earlier post.

[markizs]

i suggest you to read code instead of faq.
how can u code a mud without knowing inner stuff of it.
*ponders*

[karlan]

I don't imagine even a lot of coders look at ALL of the minutae of ALL of the functions, I had the same question as Verboden and so I looked into do_switch, but for some of the other functions, they work, I have changed nothing so far that affects them, so I do not care how they work at this stage.