I'm not understanding how the Bump proc works.

ID:155249
 
Aug 11 2011, 8:30 am
The definition says that Bump is applied when movement is stopped by something solid. The format says, 'Bump(atom/Obstacle)', but whenever I attempt to apply a mob to this, it says that I need a variable.

I'm attempting to do a procedure for a battle starting, which when touching an enemy, you would be teleported to the battle map.

mob
proc
BattleStart(M as mob in oview(1))
if (usr.Bump(M))
usr.Move(locate(1,1,2))
Aug 11 2011, 9:18 am
 
mob
    Bump(mob/enemy/enemy)
        if(istype(enemy))//if the enemy is the type that was casted on it
            src.Move(locate(1,1,2))//move to arena
        ///battle stuff
                .=..()//do the default stuff so you don't cause problems

You have to overwrite the default bump proc
Aug 11 2011, 9:40 am
In response to Ill Im
Could you explain what you're doing here a little bit more? I don't quite understand two things.

One; In mob/enemy/enemy, one is the variable and one is the name of the enemy, right?

Two; Why did you make the . operator equal the .. proc? DM is saying that I can't put a proc inside of a proc because of it.

Aug 11 2011, 9:57 am
In response to Pinnacle
You copy pasted didn't you?

. = ..() //This line was indented too far in.

Tells the game to return the value of the parent proc, in this case Bump(), should it get to that point.

mob/enemy is the type path of the mob you want it to affect, /enemy is how it will be referred to in the proc, when referenced.
Aug 11 2011, 10:14 am
In response to Robertbanks2
I copied, but not copy pasted. All right, I think I see. I thought you had to use 'as' to make something as a reference in the proc. You use the '/' operator for when you make your own term of reference?
Aug 11 2011, 10:44 am
In response to Pinnacle
Not necessarily.

/mob/enemy/enemy doesn't DEFINE anything, it simultaneously typecasts and provides a label for its associated parameter. It tells Bump() that /atom/Obstacle is in fact, a mob, of the type "mob/enemy", and that it should be referred to as "enemy".

A better way than using "as" for something that isn't already being passed is var/mob/enemy/E, as opposed to E as mob. They both work in their own instances, but the var/etc method is more flexible. "as" should generally be used for defining specific variable types, such as text, list, num, etc.

"/" provides the equivalent to indenting one further, as such:

mob/enemy/hi/there/you/guys

is the same as:

mob
enemy
hi
there
you
guys

Obviously, you can't put the latter in a single line if() statement or use it for the parameters in a proc, so you use / instead.
Aug 11 2011, 10:52 am
In response to Robertbanks2
Ah. Thanks for explaining.
Aug 27 2011, 6:37 am
In response to Pinnacle
I've just been circling around this problem, and I can't fully comprehend what's wrong. I redefine Bump(), then allow the original definition to return after the procedure is done.

Bump(mob/enemy/M)
if(istype(M))
M.Move(locate(1,1,2))
usr.Move(locate(2,2,2))
..()

I'm sorry; I just don't understand what I'm doing wrong here. DM says that there is still the duplicate definition.

Could someone please give me some insight on what I'm doing wrong?
Aug 27 2011, 8:47 am
In response to Pinnacle
Use <dm> </dm> tags to enclose code blocks.

Don't use usr there. Use src. (Try not to use usr in procs. If you are using usr, think for a second and ask if src would work. If so, then use src.)

If the compiler is giving you a duplicate definition error, likely it will tell you where the first definition is and where the new one is. If not, please copy and paste the full error so we can help you better.
Aug 27 2011, 10:31 am
In response to Complex Robot
Thanks for telling me how to designate code blocks. Here's the whole code in it's entirety.

    Bump(mob/enemy/M)
            if(istype(M))
                M.Move(locate(1,1,2))
                src.Move(locate(2,2,2))
                ..()


I was trying to make it so that if an enemy was touched, the player and the enemy would be transferred to the battlefield. After redefining the Bump proc, I attempted to return the parent definition and it didn't work.
Aug 27 2011, 12:40 pm
In response to Pinnacle
The Bump proc is called when movement is denied as the result of a dense object attempting to move to a location of one or more dense objects. (Specifically, Bump is called if the Enter proc disallows entrance.)

Are you sure you are attempting to move into the location of a dense /mob/enemy object? (And that you are also dense?)

Also, by calling the parent procedure, you mean mob/Bump, correct?
Aug 27 2011, 1:53 pm
In response to Complex Robot
Yes, I'm sure that both the player and the enemy are dense. By parent procedure, I mean the original definition of the Bump proc. I redefined it and want it to return the normal effect (meaning that when enemies are touched, it sends them to the battlefield).
Aug 27 2011, 2:01 pm
In response to Pinnacle
The default action of Bump (from the reference):
If the obstacle is a mob in the src's group, swap their positions.
Aug 27 2011, 2:16 pm
In response to Complex Robot
Complex Robot wrote:
The default action of Bump (from the reference):
If the obstacle is a mob in the src's group, swap their positions.

Ah, I see. But I didn't specify the player and the enemy to be in the same group. Isn't Bump() also called when a moving object is stopped due to dense blockage? If so, that's what I want it to do.
Aug 27 2011, 2:21 pm
In response to Pinnacle
The default action doesn't affect what causes the proc to be called.