ID:273551
 
What actions, proc, etc on the mob cause the sprite it is currently using to restart from the first frame? I'm in the process of attempting to incorporate pixel movement into a game, but the relocation of the mob by adjusting the x and y based on pixel changes keeps restarting the frames. What other procs cause this so I can see if I can work around it?

I really don't want to have to have every single frame separate and manually change it. At that point, forget it lol.
when it comes to Forum_account's pixel movement the movement setting for icon states is useless.

instead you can do this: make a variable called "m" When moving m is set to "m" (m="m") when ot moving or when you release the movement key: m="".
Then, at the end of the movement loop,before it calls the setpos() proc add this line: src.icon_state="[m]"

This will make a normal state appear to move. In order to add direction you can also have the keys set a "lastdir" variable.
so when pressing right: lastdir="east" and it should be added to the state update making it: icon_state="[lastdir][m]"

now, all-though this separates up all your directions and it seems somewhat improper, it's actually very easy to manage in comparison to some of the other solutions I've found.

For me, I have a bunch of variables which change the icon, all of which can be applied simultaneously as such, my state update is: icon_state="[lock][crouched][inair][lastdir][look][m]"

an extra check of vel_x can help the response time of the movement state. just make sure to throw a check in there before the state update such as if(vel_x==0) m=""

It was a lot of iconning work, but the results are fantastic and they leave my icons open for a lot of new features.


if this wasn't the system you were using or this post doesn't help then I'm sorry -__-

EDIT: make sure to set the states as non-movement states! As you won't actually be using twe Move() procedure the states won't appear.
In response to Bravo1
Oh yea I know movement states are useless if you're not using BYONDs build in directions and such. I'm actually using Cody123100's pixel movement and collision stuff and its working just fine, save for this one thing. None of the icon states are movement at all, they're just regular icons. My dilemma is that the icon that is currently playing, so to speak, keeps restarting when the loc is changed. I need to know if it actually is due to the loc changing, or if there is something(s) that is causing it.

Imagine taking all of these sprites in the file:
http://a.imageshack.us/img834/2294/file1.png

And having this many states in a single sprite:
http://a.imageshack.us/img834/3285/file2.png

And having to take all of those sprites, make a file for each one, and loop through them all. For each character, it'll take a really long time. At the same time, it could make for some really cool effects I could do later, but I'm trying to avoid doing that right now because it's more time than I have. Hence the question.
In response to Pyro_dragons
Ive used both forum_accounts and cody's pixel movement libraries and they both handle icons and collision in similar ways (while cody's is a more indepth version and forum_accounts is a bare bones) Have you done any modification to the code to fit your game, and if so could you post it, my guess is somewhere in your movement proc or where you call the pixel move you are changing the icon, and its getting called everytime you call pixel move, if this is the case a simple relocation of where you change the iconstate would fix this or a simple check of the the status before changing. but some post of how your code is handling this would help
In response to NightJumper88
If you change the icon_state to the same state, it doesn't effect it, by the way. So a repeated call wouldn't effect it.

It is a slightly modified code from the original, and 'm certain the issue lies with the relocation. Since the attack I'm working on is still a WIP, when it bumps up against another mob, it plays the animation just fine and doesn't move anywhere.

Demonstration:
http://www.youtube.com/watch?v=2yUmhIYabSY
Still working on this thing, so bugs are aplenty. But the collision one's aren't my main problem I'm worrying about right now.

Code:
atom/proc
C_Pixel_Move(atom/movable/a,x_move,y_move)
var/mob/M
if(istype(a, /mob/fighter))
M = a
var/final_direction //stores what the icon's final direction will be
if(x_move>0&&y_move>0) //if the x and y axis are both increased then the new direction is northeast
final_direction=NORTHEAST
if(x_move>0&&y_move==0) //if only the x axis is increased the direction is east
final_direction=EAST
if(x_move>0&&y_move<0) //if the x axis is increased and the y axis is decreased then the direction is southeast
final_direction=SOUTHEAST
if(x_move<0&&y_move>0) //if the x axis is decreased and the y axis is increased the new direction is northwest
final_direction=NORTHWEST
if(x_move<0&&y_move==0) //if only the x axis is decreased the direction is west
final_direction=WEST
if(x_move<0&&y_move<0) //if both the x and y axis are decreased the direction is southwest
final_direction=SOUTHWEST
if(x_move==0&&y_move>0) //if the x axis is unchanged and the y axis is increased the direction is North
final_direction=NORTH
if(x_move==0&&y_move<0) //if only the y axis is decreased the direction is south
final_direction=SOUTH
if(M && M.icon_state == "idle")
a.dir=final_direction //set the direction of the atom to the value of the placeholder "final_direction"
var/new_x=a.pixel_x+x_move //calculate the shift of the atom's icon by x_move pixels on the x-axis
var/new_y=a.pixel_y+y_move //calculate the shift the atom's icon by y_move pixels on the y-axis
a.x_min=(a.x_min+x_move) //calculate and set the new position of the left edge of the bounding box
a.x_max=(a.x_max+x_move) //calculate and set the new position of the right edge of the bounding box
a.y_max=(a.y_max+y_move) //calculate and set the new position of the top edge of the bounding box
a.y_min=(a.y_min+y_move) //calculate and set the new position of the bottom edge of the bounding box
C_Pixel_Collision_Handling(a) //check for collisions up ahead
C_Pixel_Map_Check(a) //check to make sure you don't move off the map
if(a && a.can_move) //if there is no collision
a.pixel_x=new_x //adjust the pixel-x of the atom's icon
a.pixel_y=new_y //adjust the pixel-y of the atom's icon
a.x_shifts+=x_move //add up the x-shifts for mob handling
a.y_shifts+=y_move //add up the y-shifts for mob handling
if(istype(a,/mob/))
C_Camera_Handling(a,x_move,y_move)
C_Pixel_Mob_Handling(a) //pass the procedure on to mob handling
else
if(a)
a.can_move=1
a.x_min=(a.x_min-x_move) //this portion of code resets the bounding box position if there is failed movement
a.x_max=(a.x_max-x_move)
a.y_max=(a.y_max-y_move)
a.y_min=(a.y_min-y_move)

C_Pixel_Mob_Handling(atom/movable/a) //shifts your mob as necessary
if(a.x_shifts>=32) //if the x-axis shifts are greater than the specified number (32 since the standard BYOND atom is 32x32px and this is moving that atom)
a.loc=locate(a.x+1,a.y,a.z) //shift the mob to the right the specified number of steps
a.x_shifts-=32 //reset the x_shifts so this can be repeated
a.pixel_x=0 //adjust the icon's x value pixel offset
if(a.x_shifts<=-32) //this next chunk is the same as above but for negative movement on the x-axis
a.loc=locate(a.x-1,a.y,a.z)
a.x_shifts+=32
a.pixel_x=0
if(a.y_shifts>=32) //if the y-axis shifts are greater than the specified number
a.loc=locate(a.x,a.y+1,a.z) //shift the mob up
a.y_shifts-=32 //reset y-shifts
a.pixel_y=0 //adjust the icon's y value pixel offset
if(a.y_shifts<=-32) //this next chunk is the same as above but for negative movement on the y-axis
a.loc=locate(a.x,a.y-1,a.z)
a.y_shifts+=32
a.pixel_y=0


These are the 2 procs that handle movement.
In response to Pyro_dragons
Since you're using another system I have to get used to understanding it in order to modify it. I've downloaded it and am looking it over, but until I figure it out I can't really help you. Very nice Game premise though! Perhaps a Mugen-style game could be created with this? EX: Everyone code is preset (basic attacks only of course) and then a Character.DM file and a character.dmi file can be added to basically put another player into the game.

And you think it might need adjustment pre-runtime in the main DM. Instead you could use world.New() and reiterate it in every file to add on that character to the character select screen. Just a thought. =P Regardless, really great work so far! But I can't help at the moment.
In response to Bravo1
Well there's much more to it then that if you looked at the other videos on my channel there, I'm just trying out a pixel version instead of tile based. Either way, I still gotta figure this out so I can continue.
In response to Pyro_dragons
I'm still unsure. In my non pixel version, using step as a relocation method doesn't reset the sprite. Yet, whether I manually relocate or use step, it resets the sprite. Any ideas?