Moving another mob

ID:140758
 
Sep 22 2009, 4:45 am
Code:
mob
    var
        controller 

client
    Move()
        if(usr.controller == null)
            usr.controller = src
        if(usr.controller == src)
            ..()
        else
            Move(usr.controller)


Problem description:
Basically i click a mob and on the click it becomes my controller but when i try to move it get alot of error's.

Sep 22 2009, 5:55 am
 
client
  var/mob/controlling
  Click(var/mob/M)
    if(ismob(M))
      if(M == controlling)
        controlling = M
      else
        controlling = null

  Move(NewLoc, Dir)
    //move the mob we are controlling if we have one
    if(controlling)
      return controlling.Move(NewLoc, Dir)
    //otherwise perform the default move action
    else
      return ..()
Sep 22 2009, 10:34 am
In response to Garthor
Garthor wrote:
client
>   Click(var/mob/M)
>     if(ismob(M))
>       if(M == controlling)
>         controlling = M
>       else
>         controlling = null


That's a little backwards in 2 ways. Fixed: 
mob/Click()
   if(usr.client.controlling == M)
      usr.client.controlling = null
   else
      usr.client.controlling = M
//(could be compacted with the ? operator)
Sep 22 2009, 10:55 am (Edited on Sep 24 2009, 8:14 pm)
In response to Kaioken
Kaioken wrote:
That's a little backwards in 2 ways. Fixed:
> mob/Click()
>    if(usr.client.controlling == M)
>       usr.client.controlling = null
>    else
>       usr.client.controlling = M
> //(could be compacted with the ? operator)


Just to show what Kaioken by compacting it with the '?' operator.

mob/Click() 
    usr.client.controlling = ( (usr.client.controllling == M) ? null : M)
Sep 22 2009, 12:44 pm
In response to Kaioken
Kaioken wrote:
That's a little backwards in 2 ways.


No, that's backwards. Fixed:
client
  var/mob/controlling
  Click(var/mob/M)
    if(ismob(M))
      if(M == controlling)
        controlling = M
      else
        controlling = null

  Move(NewLoc, Dir)
    //move the mob we are controlling if we have one
    if(controlling)
      return controlling.Move(NewLoc, Dir)
    //otherwise perform the default move action
    return ..()
Sep 22 2009, 5:08 pm
In response to Crashed
Though I just remembered I did make a mistake, and client/Move() should be:

client/Move(NewLoc, Dir)
  if(controlling)
    return step(controlling, get_dir(mob, NewLoc))
  return ..()
Sep 23 2009, 8:05 am
In response to Crashed
Crashed wrote:
Fixed:
>       if(M == controlling)
>         controlling = M
        [...]


Because surely, that makes sense and would make selecting a mob to control actually work.
And the using of mob/Click() instead of client/Click() is a better choice because you only want the code to process when a mob is clicked and not for all clicks, and the atom/Click() solution is there for you just for that purpose (nevermind that it's also more object oriented). Overriding client/Click() and doing a type check when you already have per-type procs is of course as silly as overriding an object proc at the base level and checking src's type, instead of just overriding the proc at the type you want.
Sep 23 2009, 10:58 am
In response to Kaioken
That was just another mistake I made. Wrote == instead of != (or put one body where the other should've been, who knows). So, it should've been:

if(M == controlling)
  controlling = null
else
  controlling = M


I got very little sleep the night before.

As for my reasoning for making it client/Click() instead of mob/Click(), I felt that it was part of the basic interface, and so belongs there. However, it can really go either way.
Sep 24 2009, 4:28 am
In response to Garthor
Garthor wrote:
That was just another mistake I made. Wrote == instead of != (or put one body where the other should've been, who knows)

Yeah, I figured that out - happens. That first sentence was there simply because Crashed claimed otherwise, indicating he failed to actually read the code first.

However, it can really go either way.

Yes, it can go either way, it's just that atom/Click() was specifically made for using it in this manner and skipping the type check by being object-oriented, so not using it also seems like a little of a waste. :P
Sep 24 2009, 12:24 pm
In response to Haywire
this is a good example of a person who dosn't click preveiw before posting