Demos???

ID:170425
 
Jan 25 2005, 5:59 pm
is there anything that can help me to understand how i can change verbs into procs so that i can have one proc that does the verb even if it changes...

if that sounds confusing here is an exzample

I want the usr to be able to press .center when near a npc and the npc talks to him...so instead of using a talk verb i want to use .center
Jan 25 2005, 6:10 pm
Erm...
Make a .dms file
Than input this :
macro
    .center return "Talk "

Put this somewhere else:
mob
    NpcThingy
    verb/Talk()
        set hidden = 0
        set src in oview(1)
        alert("You clicked [src]")
        alert("Congradulations, you may now click yourself and go boom.")

Jan 26 2005, 4:26 am
In response to Xeal
set hidden = 1
Jan 26 2005, 4:49 am
Motre wrote:
is there anything that can help me to understand how i can change verbs into procs so that i can have one proc that does the verb even if it changes...

if that sounds confusing here is an exzample

I want the usr to be able to press .center when near a npc and the npc talks to him...so instead of using a talk verb i want to use .center

Well the first thing you need to do is stop saying "the usr". This nasty verbal shortcut puts usr foremost in people's minds so they end up using it in their code in places it has no business--like, for example, procs that used to be verbs. You really mean "the user", which is another way of saying "the player". But actually you mean a player, since BYOND is a multiplayer environment.

On to the question. Just create a mob proc that will do what you want, but in this proc, use src instead of usr. When you call that proc from client/Center(), call it as usr.theproc().
client/Center()
  usr.Talk()


The only real trouble from there is figuring out which NPC you're talking to. Unlike in a verb where you could use "set src in oview(1)" or such, here src is a player and the NPC is something else. So now you have to find the NPC nearby.

You have a few options, including these: 1) You can talk to the one you're facing. 2) You can talk to any NPC within 1 tile.

So here's some code for the facing form:
mob/proc/Talk()
  // loop just in case multiple mobs inhabit the same tile
  // it shouldn't happen, but this way is more robust
  for(var/mob/M in get_step(src, dir))
    // call M.Response() to get a message from the NPC
    src << M.Response()


And now for the form that talks to everyone within 1 tile:
mob/proc/Talk()
  // be sure to use src in oview() here, because usr is the default
  for(var/mob/M in oview(src, 1))
    // call M.Response() to get a message from the NPC
    src << M.Response()


By the way, you're not limited to src<<M.Response() either. You can use something like M.Response(src) so that a Response() proc can do complex things like buying and selling for shopkeepers. For example:
mob/shopkeeper
  // M is a player talking to this NPC
  Response(mob/M)
    if(!M || !M.client) return    // safety check
    var/list/wares = new
    var/obj/O
    for(O in src) wares["\A [O] -- $[O.price]"] = O
    // use M for input() here since usr is the default
    // as null|anything allows Cancel; use it whenever possible
    O = input(M, "Which item would you like to buy?", "Buy") as null|anything in wares
    if(!O || !wares[O]) return    // Cancel or invalid choice
    // the player's actual choice was a string; get the item itself
    O = wares[O]
    if(O.price > M.money)
      M << "<b>[src]:</b> Sorry, but you don't have $[O.price] to pay for \a [O]."
      return
    // buy a copy of the item
    M.money -= O.price
    new O.type(M)
    M << "<b>[src]:</b> Thank you. Enjoy your [O]."


This code should be very robust. Take a look at the if(!O || !wares[O]) test above. The !O test accounts for the player clicking the Cancel button, but !wares[O] is actually there as a redundant safety check. Any non-null choice returned from input() should be a valid one and should have an associated value in this list, but a little extra caution never hurts. These little things, and the if(!M || !M.client) check at the top of the proc, make your code a lot more stable.

Lummox JR