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.
ID:273551
Aug 6 2010, 7:02 pm
|
|
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 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?
|
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.