Register
I would like to know the simplest way to make a walking animation for my characters outside the 2-frame default of the engine.
For example, I'd like my character to cycle through 2 frames while walking. The first frame will be 'left foot forward' and the second frame will be 'right foot forward.' But once the corresponding key is released and the character stops walking, I'd like the character to appear as a third frame: 'at rest with both feet touching the ground.'
Also I should note that this solution will have to work for caterpillar party as I'll want all characters to rest at the same time, cycle through a walk animation at the same time, etc...
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
What is the simplest way to create my own walking animation?
Sat Jan 11, 2014 12:39 am 
Sat Jan 11, 2014 12:50 am
Well, I don't know about easiest, but the way I would do it is to have a script check to see if the character is standing still and have a slice appear on top of them with the "STanding Still" frame for that direction if they are. Give me say... two hours to fiddle around and come up with some specifics.
Sat Jan 11, 2014 12:52 am
The easiest way to do that? Probably an "each step" script like this:
For the caterpillar party, you'll need to change pictures and frames for each member individually, but the script should still fundamentally work, since everyone walks at the same time.
Mega Tact v1.1
Super Penguin Chef
Wizard Blocks
Code:
plotscript, each step, begin
set hero picture(me, 1) # "walking" walkabout set
set hero frame(me, 0)
wait(1)
set hero frame(me, 1)
wait(1)
set hero frame(me, 0)
wait(1)
set hero frame(me, 1)
wait(1)
set hero frame(me, 0)
wait(1)
set hero picture(me, 0) # "standing" walkabout set
end
set hero picture(me, 1) # "walking" walkabout set
set hero frame(me, 0)
wait(1)
set hero frame(me, 1)
wait(1)
set hero frame(me, 0)
wait(1)
set hero frame(me, 1)
wait(1)
set hero frame(me, 0)
wait(1)
set hero picture(me, 0) # "standing" walkabout set
end
For the caterpillar party, you'll need to change pictures and frames for each member individually, but the script should still fundamentally work, since everyone walks at the same time.
Mega Tact v1.1
Super Penguin Chef
Wizard Blocks
Sat Jan 11, 2014 1:08 am
Gizmog wrote:
Well, I don't know about easiest, but the way I would do it is to have a script check to see if the character is standing still and have a slice appear on top of them with the "STanding Still" frame for that direction if they are. Give me say... two hours to fiddle around and come up with some specifics.
Thanks. I'll probably go with Mogri's post since it should probably work in to my script quite well. Though your whole slice idea does give me another idea. Perhaps I can do as you said and place a slice over top of my character at a given time. That way I could make puzzles in which the hero picks up items (slices) and places them on weighted levers in order to complete said puzzle. In fact this gives me tons of ideas so I'm glad you mentioned it.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Sat Jan 11, 2014 1:10 am
Mogri wrote:
The easiest way to do that? Probably an "each step" script like this:
For the caterpillar party, you'll need to change pictures and frames for each member individually, but the script should still fundamentally work, since everyone walks at the same time.
Code:
plotscript, each step, begin
set hero picture(me, 1) # "walking" walkabout set
set hero frame(me, 0)
wait(1)
set hero frame(me, 1)
wait(1)
set hero frame(me, 0)
wait(1)
set hero frame(me, 1)
wait(1)
set hero frame(me, 0)
wait(1)
set hero picture(me, 0) # "standing" walkabout set
end
set hero picture(me, 1) # "walking" walkabout set
set hero frame(me, 0)
wait(1)
set hero frame(me, 1)
wait(1)
set hero frame(me, 0)
wait(1)
set hero frame(me, 1)
wait(1)
set hero frame(me, 0)
wait(1)
set hero picture(me, 0) # "standing" walkabout set
end
For the caterpillar party, you'll need to change pictures and frames for each member individually, but the script should still fundamentally work, since everyone walks at the same time.
That sounds like it should do great to me. I also can spiff it up a bit to check whether my character is running thus allowing me to use alternate running sprites and so on. Thank you.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Sat Jan 11, 2014 1:59 am
Yeah, Moogle's way is WAAAAAAAAY easier than mine. For the sake of comparison, a "what not to do" kind of thing, here is my version:
Code:
include, plotscr.hsd
#These will be the handles for the idle frame.
#Note that the first hero in the party is 0 rather than 1, so these numbers are always going to be one higher than the hero they refer to.
globalvariable (1,Hero1Idle)
globalvariable (2,Hero2Idle)
globalvariable (3,Hero3Idle)
globalvariable (4,Hero4Idle)
#Fair warning, this script assumes there's four characters in the party at all times. You should probably include a check to see if there's not.
#Double fair warning: You're gonna need to set a tag on and off every time you enable/disable the party caterpillar. Apparently, the other heroes in the party aren't actually "walking" as per
#the command.
plotscript,ThreeFrames,begin
#Adds the rest of the party.
addhero (1)
addhero (2)
addhero (3)
#Loads 4 walkabout slices, setting the above variables to their handles.
#The GetHeroPicture thing assumes that every other set of walkabouts is the appropriate idles for the set before. IE: Set 0 would be Edgar's Walking around, Set 1 would be Edgar's idles
Hero1Idle := loadwalkaboutsprite (GetHeroPicture (0,OutsideBattle)+1,GetHeroPalette (0,OutsideBattle))
Hero2Idle := loadwalkaboutsprite (GetHeroPicture (1,OutsideBattle)+1,GetHeroPalette (1,OutsideBattle))
Hero3Idle := loadwalkaboutsprite (GetHeroPicture (2,OutsideBattle)+1,GetHeroPalette (2,OutsideBattle))
Hero4Idle := loadwalkaboutsprite (GetHeroPicture (3,OutsideBattle)+1,GetHeroPalette (3,OutsideBattle))
#Now, we parent them to the appropriate hero.
setparent (Hero1Idle,GetHeroSlice (0))
setparent (Hero2Idle,GetHeroSlice (1))
setparent (Hero3Idle,GetHeroSlice (2))
setparent (Hero4Idle,GetHeroSlice (3))
#And make them invisible, for now.
setspritevisible (Hero1Idle,off)
setspritevisible (Hero2Idle,off)
setspritevisible (Hero3Idle,off)
setspritevisible (Hero4Idle,off)
#Calls the IdleLoop script and ends this one.
IdleLoop
end
#Cycles through the commands in the do block forever. This could be obnoxious and interfere with complicated script stuff later, so ideally you should have a conditional to it, but whatever.
script,IdleLoop,begin
while (true)
do (
#Calls the Idle Direction function, defined below, to make sure everyone faces the right direction.
IdleDirection
#Checks to see if the catapillar is enabled or not.
If (CheckTag (3)) then (
#Checks each hero to see if they're walking and sets their idle sprite to visible or invisible accordingly.
if (HeroIsWalking (0))
then (setspritevisible (Hero1Idle,off))
else (setspritevisible (Hero1Idle,on))
if (HeroIsWalking (1))
then (setspritevisible (Hero2Idle,off))
else (setspritevisible (Hero2Idle,on))
if (HeroIsWalking (2))
then (setspritevisible (Hero3Idle,off))
else (setspritevisible (Hero3Idle,on))
if (HeroIsWalking (3))
then (setspritevisible (Hero4Idle,off))
else (setspritevisible (Hero4Idle,on))
)
else (
if (HeroIsWalking (0))
then (
setspritevisible (Hero1Idle,off)
setspritevisible (Hero2Idle,off)
setspritevisible (Hero3Idle,off)
setspritevisible (Hero4Idle,off)
)
else (
setspritevisible (Hero1Idle,on)
setspritevisible (Hero2Idle,on)
setspritevisible (Hero3Idle,on)
setspritevisible (Hero4Idle,on)
)
)
#Mandatory wait (1) for this kind of while loop
wait (1)
)
end
script,IdleDirection,begin
#Updates the idle sprite to make sure it's facing the correct direction.
variable (IdleD)
#Hero direction returns 0 for north, 1 for east, two for south, three for west.
#Since there's two frames for every direction, we have to multiply. IE: If the hero is facing west, 3, we want to use frame SIX which faces west.
IdleD := HeroDirection (0)*2
SetSpriteFrame (Hero1Idle,IdleD)
#And repeat for each hero.
IdleD := HeroDirection (1)*2
SetSpriteFrame (Hero2Idle,IdleD)
IdleD := HeroDirection (2)*2
SetSpriteFrame (Hero3Idle,IdleD)
IdleD := HeroDirection (3)*2
SetSpriteFrame (Hero4Idle,IdleD)
end
include, plotscr.hsd
#These will be the handles for the idle frame.
#Note that the first hero in the party is 0 rather than 1, so these numbers are always going to be one higher than the hero they refer to.
globalvariable (1,Hero1Idle)
globalvariable (2,Hero2Idle)
globalvariable (3,Hero3Idle)
globalvariable (4,Hero4Idle)
#Fair warning, this script assumes there's four characters in the party at all times. You should probably include a check to see if there's not.
#Double fair warning: You're gonna need to set a tag on and off every time you enable/disable the party caterpillar. Apparently, the other heroes in the party aren't actually "walking" as per
#the command.
plotscript,ThreeFrames,begin
#Adds the rest of the party.
addhero (1)
addhero (2)
addhero (3)
#Loads 4 walkabout slices, setting the above variables to their handles.
#The GetHeroPicture thing assumes that every other set of walkabouts is the appropriate idles for the set before. IE: Set 0 would be Edgar's Walking around, Set 1 would be Edgar's idles
Hero1Idle := loadwalkaboutsprite (GetHeroPicture (0,OutsideBattle)+1,GetHeroPalette (0,OutsideBattle))
Hero2Idle := loadwalkaboutsprite (GetHeroPicture (1,OutsideBattle)+1,GetHeroPalette (1,OutsideBattle))
Hero3Idle := loadwalkaboutsprite (GetHeroPicture (2,OutsideBattle)+1,GetHeroPalette (2,OutsideBattle))
Hero4Idle := loadwalkaboutsprite (GetHeroPicture (3,OutsideBattle)+1,GetHeroPalette (3,OutsideBattle))
#Now, we parent them to the appropriate hero.
setparent (Hero1Idle,GetHeroSlice (0))
setparent (Hero2Idle,GetHeroSlice (1))
setparent (Hero3Idle,GetHeroSlice (2))
setparent (Hero4Idle,GetHeroSlice (3))
#And make them invisible, for now.
setspritevisible (Hero1Idle,off)
setspritevisible (Hero2Idle,off)
setspritevisible (Hero3Idle,off)
setspritevisible (Hero4Idle,off)
#Calls the IdleLoop script and ends this one.
IdleLoop
end
#Cycles through the commands in the do block forever. This could be obnoxious and interfere with complicated script stuff later, so ideally you should have a conditional to it, but whatever.
script,IdleLoop,begin
while (true)
do (
#Calls the Idle Direction function, defined below, to make sure everyone faces the right direction.
IdleDirection
#Checks to see if the catapillar is enabled or not.
If (CheckTag (3)) then (
#Checks each hero to see if they're walking and sets their idle sprite to visible or invisible accordingly.
if (HeroIsWalking (0))
then (setspritevisible (Hero1Idle,off))
else (setspritevisible (Hero1Idle,on))
if (HeroIsWalking (1))
then (setspritevisible (Hero2Idle,off))
else (setspritevisible (Hero2Idle,on))
if (HeroIsWalking (2))
then (setspritevisible (Hero3Idle,off))
else (setspritevisible (Hero3Idle,on))
if (HeroIsWalking (3))
then (setspritevisible (Hero4Idle,off))
else (setspritevisible (Hero4Idle,on))
)
else (
if (HeroIsWalking (0))
then (
setspritevisible (Hero1Idle,off)
setspritevisible (Hero2Idle,off)
setspritevisible (Hero3Idle,off)
setspritevisible (Hero4Idle,off)
)
else (
setspritevisible (Hero1Idle,on)
setspritevisible (Hero2Idle,on)
setspritevisible (Hero3Idle,on)
setspritevisible (Hero4Idle,on)
)
)
#Mandatory wait (1) for this kind of while loop
wait (1)
)
end
script,IdleDirection,begin
#Updates the idle sprite to make sure it's facing the correct direction.
variable (IdleD)
#Hero direction returns 0 for north, 1 for east, two for south, three for west.
#Since there's two frames for every direction, we have to multiply. IE: If the hero is facing west, 3, we want to use frame SIX which faces west.
IdleD := HeroDirection (0)*2
SetSpriteFrame (Hero1Idle,IdleD)
#And repeat for each hero.
IdleD := HeroDirection (1)*2
SetSpriteFrame (Hero2Idle,IdleD)
IdleD := HeroDirection (2)*2
SetSpriteFrame (Hero3Idle,IdleD)
IdleD := HeroDirection (3)*2
SetSpriteFrame (Hero4Idle,IdleD)
end
Sat Jan 11, 2014 3:39 am
The only thing you should be careful about with Mogri's script is that using waits for an "each step" script could slow your movement way down, since the script won't terminate until it's finished, and waits obviously imply a clear passage of time before it can move on. You might be okay since there are no instances of suspending player in his script, but if your character does appear to stop and temporarily freeze after every tile (producing a jerking motion), then change your "waits" to a timer to keep things moving smoothly.
Place Obligatory Signature Here
Place Obligatory Signature Here
Sat Jan 11, 2014 9:47 am
Actually, Moogle's script wouldn't work because each-step scripts are triggered after you finish walking to a new tile, not when you start. Also, each frame of the built-in walking animation lasts 2 ticks, not 1. And since the 0 frame would be shown twice in a row, you'd see some judder in the animation. In fact, there's no need to set the frame at all; just like the builtin animation work.
Likewise, I would not use slices to show a standing still animation. That results in two sprites overlapping each other. Instead, just use "set hero picture".
What's this about? "hero is walking" is meant to work correctly for all heroes regardless of whether the caterpillar party is enabled.
However, there is a big gotcha in the "hero is walking" command that affects scripts like this. After a hero (or NPC) finishes moving one tile, "hero is walking" will report false for one tick even if the player has a key held down so the hero is about to take another step. This problem arises because scripts run before the engine processes player input.
So here is my attempt: use both an on-keypress script to switch to the walking sprite, and an each step script to go back. I've tested this, it works (but you'll have to adapt it to support more than 1 hero). The heros should start in the standing still pose. Hmm, actually, that'll prevent the walking animation in the Quit and hero picker menus. You can work around that if desired.
That's a set of scripts I've been meaning to write for quite a while...
EDIT: made some improvements. Also, I've put a copy here:
http://rpg.hamsterrepublic.com/ohrrpgce/Scripts:Change_hero_sprite_when_standing_still
Also, I'd like to add "hero will move" as a builtin command which correctly handles all edge cases. But the real ways to solve this problem in the future will be to either use "each frame" scripts to perform animations without having to guess the future state of the game, or to just define walkabout sprite animations (both unimplemented, obviously).
Likewise, I would not use slices to show a standing still animation. That results in two sprites overlapping each other. Instead, just use "set hero picture".
Quote:
#Double fair warning: You're gonna need to set a tag on and off every time you enable/disable the party caterpillar. Apparently, the other heroes in the party aren't actually "walking" as per
#the command.
#the command.
What's this about? "hero is walking" is meant to work correctly for all heroes regardless of whether the caterpillar party is enabled.
However, there is a big gotcha in the "hero is walking" command that affects scripts like this. After a hero (or NPC) finishes moving one tile, "hero is walking" will report false for one tick even if the player has a key held down so the hero is about to take another step. This problem arises because scripts run before the engine processes player input.
So here is my attempt: use both an on-keypress script to switch to the walking sprite, and an each step script to go back. I've tested this, it works (but you'll have to adapt it to support more than 1 hero). The heros should start in the standing still pose. Hmm, actually, that'll prevent the walking animation in the Quit and hero picker menus. You can work around that if desired.
Code:
script, dir X, dir, begin
switch (dir) do (
case (up, down) do (return (0))
case (right) do (return (1))
case (left) do (return (-1))
)
end
script, dir Y, dir, begin
switch (dir) do (
case (left, right) do (return (0))
case (down) do (return (1))
case (up) do (return (-1))
)
end
script, trying to move direction, begin
return (-1)
if (key is pressed(key:left)) then (return (left))
if (key is pressed(key:right)) then (return (right))
if (key is pressed(key:up)) then (return (up))
if (key is pressed(key:down)) then (return (down))
end
# Return true if "suspend player" is active
script, player is suspended, begin
return ((read general(44), and, 2) <> 0)
end
# This will return true if hero 0 will start a new step
# this tick because of player input. There are no commands
# that can tell you that directly: you have to figure it out
# by checking keypresses and for obstructions.
# Note: this doesn't handle all edge cases, like multiple NPCs
# on one tile, NPCs over the edge of the map, 'suspend player'
# in force, or the hero already in motion.
script, hero will move, begin
variable (dir, npc)
# If a textbox is up or player is suspended, the hero can't move
if (current textbox > -1 || player is suspended) then (exit returning (false))
# Check for player input
dir := trying to move direction
if (dir == -1) then (exit returning (false))
# If there's a wall in the way, nothing will happen (unless walls are suspended...)
if (check hero wall(0, dir)) then (exit returning (false))
# Check for an NPC (this isn't correct either if obstruction is suspended,
# or other edge cases)
npc := npc at spot (hero x(0) + dir x(dir), hero y(0) + dir y(dir))
if (npc && readNPC(npc,NPCstat:activation) <> NPCactivation:stepon) then (exit returning (false))
# OK, you will start walking in this direction
return (true)
end
plotscript, walking animation onkeypress, begin
if (hero is walking (0) == false) then (
# Standing on a tile, might start movement
if (hero will move) then (
# Walking spriteset
set hero picture (0, 0, outside battle)
)
)
end
plotscript, walking animation eachstep, begin
if (hero will move == false) then (
set hero picture (0, 3, outside battle)
)
end
script, dir X, dir, begin
switch (dir) do (
case (up, down) do (return (0))
case (right) do (return (1))
case (left) do (return (-1))
)
end
script, dir Y, dir, begin
switch (dir) do (
case (left, right) do (return (0))
case (down) do (return (1))
case (up) do (return (-1))
)
end
script, trying to move direction, begin
return (-1)
if (key is pressed(key:left)) then (return (left))
if (key is pressed(key:right)) then (return (right))
if (key is pressed(key:up)) then (return (up))
if (key is pressed(key:down)) then (return (down))
end
# Return true if "suspend player" is active
script, player is suspended, begin
return ((read general(44), and, 2) <> 0)
end
# This will return true if hero 0 will start a new step
# this tick because of player input. There are no commands
# that can tell you that directly: you have to figure it out
# by checking keypresses and for obstructions.
# Note: this doesn't handle all edge cases, like multiple NPCs
# on one tile, NPCs over the edge of the map, 'suspend player'
# in force, or the hero already in motion.
script, hero will move, begin
variable (dir, npc)
# If a textbox is up or player is suspended, the hero can't move
if (current textbox > -1 || player is suspended) then (exit returning (false))
# Check for player input
dir := trying to move direction
if (dir == -1) then (exit returning (false))
# If there's a wall in the way, nothing will happen (unless walls are suspended...)
if (check hero wall(0, dir)) then (exit returning (false))
# Check for an NPC (this isn't correct either if obstruction is suspended,
# or other edge cases)
npc := npc at spot (hero x(0) + dir x(dir), hero y(0) + dir y(dir))
if (npc && readNPC(npc,NPCstat:activation) <> NPCactivation:stepon) then (exit returning (false))
# OK, you will start walking in this direction
return (true)
end
plotscript, walking animation onkeypress, begin
if (hero is walking (0) == false) then (
# Standing on a tile, might start movement
if (hero will move) then (
# Walking spriteset
set hero picture (0, 0, outside battle)
)
)
end
plotscript, walking animation eachstep, begin
if (hero will move == false) then (
set hero picture (0, 3, outside battle)
)
end
That's a set of scripts I've been meaning to write for quite a while...
EDIT: made some improvements. Also, I've put a copy here:
http://rpg.hamsterrepublic.com/ohrrpgce/Scripts:Change_hero_sprite_when_standing_still
Also, I'd like to add "hero will move" as a builtin command which correctly handles all edge cases. But the real ways to solve this problem in the future will be to either use "each frame" scripts to perform animations without having to guess the future state of the game, or to just define walkabout sprite animations (both unimplemented, obviously).
Sat Jan 11, 2014 8:22 pm
What I mean by that, my script worked but only for Hero 1. If I suspend caterpillar, and walk each hero individually, the script worked fine. But just holding down arrow keys and wandering about the map only Hero 1 would flicker, the rest would stay the gray of the "Idle" animation I was using to test.
Sat Jan 11, 2014 9:34 pm
TMC wrote:
Actually, Moogle's script wouldn't work because each-step scripts are triggered after you finish walking to a new tile, not when you start. Also, each frame of the built-in walking animation lasts 2 ticks, not 1. And since the 0 frame would be shown twice in a row, you'd see some judder in the animation. In fact, there's no need to set the frame at all; just like the builtin animation work.
Likewise, I would not use slices to show a standing still animation. That results in two sprites overlapping each other. Instead, just use "set hero picture".
What's this about? "hero is walking" is meant to work correctly for all heroes regardless of whether the caterpillar party is enabled.
However, there is a big gotcha in the "hero is walking" command that affects scripts like this. After a hero (or NPC) finishes moving one tile, "hero is walking" will report false for one tick even if the player has a key held down so the hero is about to take another step. This problem arises because scripts run before the engine processes player input.
So here is my attempt: use both an on-keypress script to switch to the walking sprite, and an each step script to go back. I've tested this, it works (but you'll have to adapt it to support more than 1 hero). The heros should start in the standing still pose. Hmm, actually, that'll prevent the walking animation in the Quit and hero picker menus. You can work around that if desired.
That's a set of scripts I've been meaning to write for quite a while...
EDIT: made some improvements. Also, I've put a copy here:
http://rpg.hamsterrepublic.com/ohrrpgce/Scripts:Change_hero_sprite_when_standing_still
Also, I'd like to add "hero will move" as a builtin command which correctly handles all edge cases. But the real ways to solve this problem in the future will be to either use "each frame" scripts to perform animations without having to guess the future state of the game, or to just define walkabout sprite animations (both unimplemented, obviously).
Likewise, I would not use slices to show a standing still animation. That results in two sprites overlapping each other. Instead, just use "set hero picture".
Quote:
#Double fair warning: You're gonna need to set a tag on and off every time you enable/disable the party caterpillar. Apparently, the other heroes in the party aren't actually "walking" as per
#the command.
#the command.
What's this about? "hero is walking" is meant to work correctly for all heroes regardless of whether the caterpillar party is enabled.
However, there is a big gotcha in the "hero is walking" command that affects scripts like this. After a hero (or NPC) finishes moving one tile, "hero is walking" will report false for one tick even if the player has a key held down so the hero is about to take another step. This problem arises because scripts run before the engine processes player input.
So here is my attempt: use both an on-keypress script to switch to the walking sprite, and an each step script to go back. I've tested this, it works (but you'll have to adapt it to support more than 1 hero). The heros should start in the standing still pose. Hmm, actually, that'll prevent the walking animation in the Quit and hero picker menus. You can work around that if desired.
Code:
script, dir X, dir, begin
switch (dir) do (
case (up, down) do (return (0))
case (right) do (return (1))
case (left) do (return (-1))
)
end
script, dir Y, dir, begin
switch (dir) do (
case (left, right) do (return (0))
case (down) do (return (1))
case (up) do (return (-1))
)
end
script, trying to move direction, begin
return (-1)
if (key is pressed(key:left)) then (return (left))
if (key is pressed(key:right)) then (return (right))
if (key is pressed(key:up)) then (return (up))
if (key is pressed(key:down)) then (return (down))
end
# Return true if "suspend player" is active
script, player is suspended, begin
return ((read general(44), and, 2) <0> -1 || player is suspended) then (exit returning (false))
# Check for player input
dir := trying to move direction
if (dir == -1) then (exit returning (false))
# If there's a wall in the way, nothing will happen (unless walls are suspended...)
if (check hero wall(0, dir)) then (exit returning (false))
# Check for an NPC (this isn't correct either if obstruction is suspended,
# or other edge cases)
npc := npc at spot (hero x(0) + dir x(dir), hero y(0) + dir y(dir))
if (npc && readNPC(npc,NPCstat:activation) <> NPCactivation:stepon) then (exit returning (false))
# OK, you will start walking in this direction
return (true)
end
plotscript, walking animation onkeypress, begin
if (hero is walking (0) == false) then (
# Standing on a tile, might start movement
if (hero will move) then (
# Walking spriteset
set hero picture (0, 0, outside battle)
)
)
end
plotscript, walking animation eachstep, begin
if (hero will move == false) then (
set hero picture (0, 3, outside battle)
)
end
script, dir X, dir, begin
switch (dir) do (
case (up, down) do (return (0))
case (right) do (return (1))
case (left) do (return (-1))
)
end
script, dir Y, dir, begin
switch (dir) do (
case (left, right) do (return (0))
case (down) do (return (1))
case (up) do (return (-1))
)
end
script, trying to move direction, begin
return (-1)
if (key is pressed(key:left)) then (return (left))
if (key is pressed(key:right)) then (return (right))
if (key is pressed(key:up)) then (return (up))
if (key is pressed(key:down)) then (return (down))
end
# Return true if "suspend player" is active
script, player is suspended, begin
return ((read general(44), and, 2) <0> -1 || player is suspended) then (exit returning (false))
# Check for player input
dir := trying to move direction
if (dir == -1) then (exit returning (false))
# If there's a wall in the way, nothing will happen (unless walls are suspended...)
if (check hero wall(0, dir)) then (exit returning (false))
# Check for an NPC (this isn't correct either if obstruction is suspended,
# or other edge cases)
npc := npc at spot (hero x(0) + dir x(dir), hero y(0) + dir y(dir))
if (npc && readNPC(npc,NPCstat:activation) <> NPCactivation:stepon) then (exit returning (false))
# OK, you will start walking in this direction
return (true)
end
plotscript, walking animation onkeypress, begin
if (hero is walking (0) == false) then (
# Standing on a tile, might start movement
if (hero will move) then (
# Walking spriteset
set hero picture (0, 0, outside battle)
)
)
end
plotscript, walking animation eachstep, begin
if (hero will move == false) then (
set hero picture (0, 3, outside battle)
)
end
That's a set of scripts I've been meaning to write for quite a while...
EDIT: made some improvements. Also, I've put a copy here:
http://rpg.hamsterrepublic.com/ohrrpgce/Scripts:Change_hero_sprite_when_standing_still
Also, I'd like to add "hero will move" as a builtin command which correctly handles all edge cases. But the real ways to solve this problem in the future will be to either use "each frame" scripts to perform animations without having to guess the future state of the game, or to just define walkabout sprite animations (both unimplemented, obviously).
Thanks. I'll give that a go. My game has 'tall' character sprites anyways so I was already planning on doing QUIT and ORDER workarounds eventually.
My game will likely not have too much NPC wandering and most of the NPC movement will be scripted to carry out more complex patterns. Because of this I wondered how I'd go about an "NPC will move." Since there is not player control input, what function would I have to use in order for the program to know which way the NPC will move so as to adjust the NPC's sprite accordingly?
It would be wonderful if this did become a built-in feature but of course I don't expect you to put in all that effort just for my sake. I'm not sure if this would be easier but may I suggest that the future version of CUSTOM have a bitset which defaults to the current '2 sprite frames per direction' and when applied it creates a 3rd frame available for a "standing still in that direction" sprite. Of course there's probably a lot more to it and since my game uses the "embiggen heroes" script it would also require more frames to be present in the Hero Graphics section which could be messy. Maybe disregard my idea. I'm sure there's a simpler way haha.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Sat Jan 11, 2014 9:39 pm
Also what do you mean by "Beware that this script will break in lots of edge cases!"
Could you give some brief examples of causes and the corresponding effects?
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Could you give some brief examples of causes and the corresponding effects?
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Sat Jan 11, 2014 11:38 pm
Alright so combining everyones knowledge as well as tinkering with a few things on my own I was able to come up with a very simple solution which has one minor fault which hopefully you can help me out with.
Here's my code:
The first part checks if an arrow key is pressed and then sets my hero picture to the "walking hero picture sprite set."
Then I have an Each-Step script which (as TMC pointed out) executes after the player has landed on the next tile. This script sets the characters sprite set to the "standing set."
Now I'll show you a video of the result, notice that there is a slight fault in which occasionally the character appears to be sliding in to the next tile. It seems to rarely happen so you could easily miss it if you blink at that instance. I think it's a result of me releasing the the arrow key too early. Does anyone think they can fix this? If not, it's something I can live with but do think it could become more noticeable when my characters speed is increased or perhaps decreased (most likely decreased.) I'll have to test that theory.
http://www.youtube.com/watch?v=Y-CR40TQseY
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Here's my code:
The first part checks if an arrow key is pressed and then sets my hero picture to the "walking hero picture sprite set."
Code:
if(key is pressed(key:Up) || key is pressed(key:Down) || key is pressed(key:Left) || key is pressed(key:Right)) then(
set hero picture(me, 37) #Walking
embiggen now
)
if(key is pressed(key:Up) || key is pressed(key:Down) || key is pressed(key:Left) || key is pressed(key:Right)) then(
set hero picture(me, 37) #Walking
embiggen now
)
Then I have an Each-Step script which (as TMC pointed out) executes after the player has landed on the next tile. This script sets the characters sprite set to the "standing set."
Code:
set hero picture(me, 38) #Standing Still Sprite Set
embiggen now
set hero picture(me, 38) #Standing Still Sprite Set
embiggen now
Now I'll show you a video of the result, notice that there is a slight fault in which occasionally the character appears to be sliding in to the next tile. It seems to rarely happen so you could easily miss it if you blink at that instance. I think it's a result of me releasing the the arrow key too early. Does anyone think they can fix this? If not, it's something I can live with but do think it could become more noticeable when my characters speed is increased or perhaps decreased (most likely decreased.) I'll have to test that theory.
http://www.youtube.com/watch?v=Y-CR40TQseY
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Sun Jan 12, 2014 4:14 am
TMC wrote:
What's this about? "hero is walking" is meant to work correctly for all heroes regardless of whether the caterpillar party is enabled.
What's this about? "hero is walking" is meant to work correctly for all heroes regardless of whether the caterpillar party is enabled.
Actually, I am not sure this is true.
It has been a while since I have worked on the caterpillar code, but if I remember correctly, when caterpillar mode is enabled, heroes 1, 2, 3 are not really walking at all, they are just "ghosting" over the history of movements that hero 0 has made in the past 3 steps.
If confirmed to be the case this does seem like a bug, and I think that if caterpillar is enabled it would be most appropriate for all heroes to simultaneously return the same results for "hero is walking"
Sun Jan 12, 2014 5:30 am
Here is my demonstration of the effect: http://www.slimesalad.com/forum/viewgame.php?t=5996
Characters are idling when they are gray and walking when they blink back and forth between blue and red. Comment out the parts of the script marked "Disable for science" taking care to leave the SetTag (3,on) part alone, then recompile and watch the difference as you walk around. The characters dragged behind in the caterpillar will be gray instead of the red and blue they were previously. If it's something I did wrong, I apologize, and I don't mean to be an asshole or anything by posting it, just trying to clarify the situation.
Characters are idling when they are gray and walking when they blink back and forth between blue and red. Comment out the parts of the script marked "Disable for science" taking care to leave the SetTag (3,on) part alone, then recompile and watch the difference as you walk around. The characters dragged behind in the caterpillar will be gray instead of the red and blue they were previously. If it's something I did wrong, I apologize, and I don't mean to be an asshole or anything by posting it, just trying to clarify the situation.
Sun Jan 12, 2014 5:44 am
Ah! Thank you very much for the test-case Giz. I think this proves that there is indeed a bug here, and that it is more complex than I first suspected.