ID:2105261
 
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?
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
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 = ""
..()
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
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
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.
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.
In response to SolarOblivion
The DM reference:



Pulled from here.
In response to FKI
FKI wrote:
The DM reference:



Pulled from here.

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