While bumping (Pixel movement)

ID:2105261
 
Jun 24 2016, 12:02 am
I'm essentially trying to make a "pushing" system for my game, and I want the player to have the "push" icon_state while they're bumping into a pushable obj, and then go back to idle when they stop moving toward the obj. I initially tried flicking the icon state on each call of Bump() but that led to wonky animations. What simple and concise method am I overlooking?
Jun 24 2016, 5:55 pm
could you not just change the icon state to push and hold your old icon state in a variable then switch your icon state to that variable when youre done pushing
Jun 24 2016, 9:40 pm
In response to Zagros5000
Zagros5000 wrote:
could you not just change the icon state to push and hold your old icon state in a variable then switch your icon state to that variable when youre done pushing

Not really sure what you mean. An example would be nice


Also I managed to achieve the desired result with the following code, but I feel like it's in a very [inefficient?] way. A better way would be nice

mob
    Bump(atom/A)
        if(A.isPushable)
            step(A,src.dir)
            src.icon_state = "push"
            src.isPushing = TRUE
            spawn(1) src.isPushing = FALSE
    Move()
        if(!src.isPushing)
            src.icon_state = ""
        ..()
Jun 24 2016, 9:45 pm
 
mob
    Bump(atom/A)
        if(A.isPushable)
            if(step(A,src.dir)) // not sure if your allowed to do this but if it is;checks if the step can happen
                src.icon_state="push"
            else
                src.icon_state=""

this might work the same
edit: my bad u shudnt step again
Jun 24 2016, 10:09 pm
btw not really related but you shouldnt be creating procs like that then using the supercall, it's better to just have one long proc - if its for the same type. Not sure why but the more you have the longer it takes for the proc to run as i noticed in the profiler:
move()
a
..()
move()
..()
b
move()
..()
c
would takes three times as long run as:
move
a
b
c
Jun 25 2016, 2:30 pm
Zagros5000 said:
Not sure why but the more you have the longer it takes for the proc to run as i noticed in the profiler

Proc call overhead is a factor.



Bear with me as this is just a rough, untested thought. What I'm thinking involves something similar to this:

atom/movable
    proc/on_move()
        set waitfor = 0
        // insert pre-movement checks...
        return 1

mob
    on_move()
        . = ..()

        if(push_dir && dir != push_dir)
            push_dir = 0
            icon_state = ""

been_bumped(atom/movable/bumping)
    set waitfor = 0
    if(pushable)
        bumping.push_dir = bumping.dir
        bumping.icon_state = "push"
        step(src, bumping.dir)


With this, the idea is that once you bump a pushable object, the icon_state of the mover is set along with the direction they are pushing via push_dir. Then, once the mover attempts a movement, their dir and push_dir are checked for consistency. If they are not consistent, we reset their icon_state and set push_dir to 0, indicating they are no longer pushing anything. There is no need to reset the icon_state every movement using this.

This is in no way perfect, and again, it is untested; consider it an example of concept that you may or may not learn something from.

Also, your Move() proc expects a number to be returned. If you do not fix this, you will have a broken game in the future. It wouldn't hurt if you checked out how movement works either.
Jun 26 2016, 9:10 pm
In response to FKI
FKI wrote:
Also, your Move() proc expects a number to be returned. If you do not fix this, you will have a broken game in the future. It wouldn't hurt if you checked out how movement works either.

How does my Move() proc expect a number to be returned??? It's just a simple 2 line override.
Jun 26 2016, 9:39 pm
In response to SolarOblivion
The DM reference:



Pulled from here.
Jun 27 2016, 9:00 am
In response to FKI
FKI wrote:
The DM reference:



Pulled from here.

Oh right but that's as simple as ..(1), no?
Jun 27 2016, 2:30 pm
You'd actually want "return ..()" in this instance. Doing "..(1)" would be like calling "Move(1)".