Click() + images problem

ID:264399
 
May 11 2009, 3:55 am
Code:
atom/movable/Click()
    var/mob/player/p = usr
    var/image/i = image('Targeted.dmi',src)
    if(ismob(src) && src != p && src != p.target)
        p.client.images -= i
        p.target = src
        p<<"You have targeted [src]"
        p.client.images += i //also used 'p<<i' but they are the same


Problem description:
For some reason, the "F1 in Dream Maker" reference lies to me :( It says I can use 'object.client.images -= image_object', but when I clearly use it in my Click() proc above, it does not do its job. Only through using 'object.client.images = null' will it remove the image_object. However, I do not wish to do it that way. Any reason why it's not working as intended? I hope it's a minor mistake on my part :\
May 11 2009, 4:20 am (Edited on May 11 2009, 4:28 am)
 
mob/player
    var/image/i
    New()
        ..()
        i=image('Targeted.dmi')
    Login()
        ..()
        src << i
mob/Click()
    var/mob/player/p = usr
    if( src != p && src != p.target)
        p.target = src
        p<<"You have targeted [src]"
        p.i.loc=src

You're creating a new instance of an image everytime. You would have to remove the old one to not see if it anymore, but since it's a targeted system you can just have one created and move it around.
May 11 2009, 4:53 am
Out if curiosity, why are you doing an ismob() check instead of just placing it in mob/Click() ?
May 11 2009, 4:06 pm
In response to Mysame
Are mobs the only movable atoms? No.
May 11 2009, 4:59 pm
In response to Spunky_Girl
No. But you can define the stuff that happens just for mobs under mobs. If you add more code to happen under atom as well you can call ..() in it too.

mob/click()
    usr << "Clicking that mob.
    ..()

obj/Click()
    usr << "Clicking that obj.
    ..()
    
atom/movable/Click()
    usr << "Movable enaged."


You can put ..() at the top or the bottom to make the atom code or local code run first too.

May 13 2009, 4:33 pm
In response to T3h P3ngu1n
Not only are you going off-topic, but you're repeating what Mysame said. And my response remains the same. I am fully aware of the method you're attempting to "show me as if I never knew that".
May 13 2009, 4:38 pm
In response to Spunky_Girl
Well the fact that you put ismob() in the click instead of using mob/Click() because you say that mob's aren't the only movables would mean that you want code in it to run for both mobs' and obj's. So I one would have to think that you didn't know it was possible to do that without slamming all the code into one Click with type checks. Because who would if they knew they didn't have to?
May 13 2009, 4:40 pm
In response to Spunky_Girl
He repeated it because you didn't get it, as was evident from your reply about objs. When done right, you should probably never need to do a type check on src. That beats the point of using the object-oriented atom proc, really; might as well override client/Click() to do the type checks, you'd go through one proc less.
Overriding the wanted types is more efficient as you won't go through type checks at all (in contrast to on every object). Also, in such a case src will of course already be defined as the right type for you.
That's why they suggested doing the mob stuff on a mob override. Take it or leave it.
Also, it isn't off-topic seeing as it concerns the code posted in the initial post of this topic... and the original problem was solved/answered anyway.
May 13 2009, 5:03 pm
In response to Kaioken
Kaioken wrote:
Also, it isn't off-topic seeing as it concerns the code posted in the initial post of this topic... and the original problem was solved/answered anyway.

I disagree. My original question was about images. Whether my image problem was just for the one proc, or for all procs, it doesn't matter. The topic was "removing a certain image". It just so happened to be in one of my Click() overrides.

I would have gone to Design Philosophy if I wanted constructive criticism on my Click() override. Since this is in Code Problems, and my Click() override design is not the problem (my method of image definition was), it has nothing to do with the overall structure of the Click() override.

Therefore, off-topic. And so is this reply, the one before it, and any made after.
May 14 2009, 3:41 am
In response to Spunky_Girl
Spunky_Girl wrote:
I disagree.

You're free to, but it doesn't change that while you can call it off-topic, he didn't bring up anything new and unrelated to this topic.

I would have gone to Design Philosophy if I wanted constructive criticism on my Click() override. Since this is in Code Problems, [...]

If you can't take some criticism about your [code/creation/ANYTHING], you shouldn't ever discuss it publicly, because then it's bound to be criticized at some point, whether legitimately or not; people won't always agree with you. 'Nuff said, known fact of the world.