Register
You could use NPCs, but it would be very messy. And yeah, mari's right, slices would be a much better option. Unfortunately, my expertise goes far enough to know that slices are the way to go, but not far enough to be able to tell you how you should go about it. I'm sure one of the gurus here will have a better answer for you.
Being from the third world, I reserve the right to speak in the third person.
Using Editor version wip 20170527 gfx_sdl+fb music_sdl
Fri May 24, 2013 12:03 pm 
Sat May 25, 2013 12:20 am
If the slice you want to draw on top of your hero doesn't change depending on their direction, then this is actually very easy! You just create the slice once and you're done. But I'm assuming that you do want to give it different directions.
I can give you some help with that, but I'm warning you that there are lots of things that could go wrong. The following script only updates the direction when the player presses a key, so it's not updated due to direction changes caused by "set hero direction" and "walk hero". And it only works for the party leader. Caterpillar parties are hard to support because it's hard to compute what direction a hero will be facing next tick. Also, this is untested.
Lets assume you drew the armour as a walkabout sprite. Each of the two frames of the four directions should be the same (again, it's annoying to compute the correct frame, so I assume they are the same).
First you need to create a slice and parent it to the hero walkabout slice. Also you're responsible for updating this if the party changes:
Then you need to set this onkeypress script:
Hmm, we need an article about the slice tree and how to perform tricks using it. It's completely undocumented, though you can discover it all yourself using the slice debugger.
I can give you some help with that, but I'm warning you that there are lots of things that could go wrong. The following script only updates the direction when the player presses a key, so it's not updated due to direction changes caused by "set hero direction" and "walk hero". And it only works for the party leader. Caterpillar parties are hard to support because it's hard to compute what direction a hero will be facing next tick. Also, this is untested.
Lets assume you drew the armour as a walkabout sprite. Each of the two frames of the four directions should be the same (again, it's annoying to compute the correct frame, so I assume they are the same).
First you need to create a slice and parent it to the hero walkabout slice. Also you're responsible for updating this if the party changes:
Code:
global variable (1, armour slice)
plotscript, add armour slice, begin
armour slice := load walkabout sprite(4) # sprite set 4, default palette
set parent (armour slice, get hero slice(me))
# the armour slice is now the last child of the walkabout container slice, so will be drawn on top
end
plotscript, add armour slice, begin
armour slice := load walkabout sprite(4) # sprite set 4, default palette
set parent (armour slice, get hero slice(me))
# the armour slice is now the last child of the walkabout container slice, so will be drawn on top
end
Then you need to set this onkeypress script:
Code:
plotscript, on keypress script, begin
# Only update the slice if it exists
if (armour slice) then (
variable (dir)
dir := -1 #-1 to indicate none of the direction keys are pressed
if (key is pressed (key:up)) then (dir := up)
if (key is pressed (key:down)) then (dir := down)
if (key is pressed (key:left)) then (dir := left)
if (key is pressed (key:right)) then (dir := right)
if (dir > -1) then (
# dir*2 is the frame number, as seen in the spriteset editor
# (walkabout sets have frames 0 to 7)
set sprite frame (armour slice, dir * 2)
)
)
end
# Only update the slice if it exists
if (armour slice) then (
variable (dir)
dir := -1 #-1 to indicate none of the direction keys are pressed
if (key is pressed (key:up)) then (dir := up)
if (key is pressed (key:down)) then (dir := down)
if (key is pressed (key:left)) then (dir := left)
if (key is pressed (key:right)) then (dir := right)
if (dir > -1) then (
# dir*2 is the frame number, as seen in the spriteset editor
# (walkabout sets have frames 0 to 7)
set sprite frame (armour slice, dir * 2)
)
)
end
Hmm, we need an article about the slice tree and how to perform tricks using it. It's completely undocumented, though you can discover it all yourself using the slice debugger.
Fri May 31, 2013 7:10 pm
Awesome. I was able to get this working nicely, save for a problem that occurs if multiple directional keys are pressed at once. This will display the armor in the direction of all directions pressed. For example, if I happen to be holding 'right' and without depressing it I hit 'down' I see both the down and right armor directions layered over the hero.
I assume the solution here will be either very simple or very convoluted.
edit: confusing sentences..
I assume the solution here will be either very simple or very convoluted.
edit: confusing sentences..
Sat Jun 01, 2013 3:00 am
Well, that indicates that you modified my script, which won't suffer that problem. You should post the scripts you're actually using.
Sat Jun 01, 2013 5:45 am
Code:
include, plotscr.hsd
include, thirty.hsi
include, scancode.hsi
global variable (1, armour slice)
plotscript, add armour slice, begin
armour slice := load walkabout sprite(17)
set parent (armour slice, get hero slice(me))
# the armour slice is now the last child of the walkabout container slice, so will be drawn on top
end
plotscript, on keypress script, begin
# Only update the slice if it exists
if (armour slice) then (
variable (dir)
dir := -1 #-1 to indicate none of the direction keys are pressed
if (key is pressed (key:up)) then (dir := up)
if (key is pressed (key:down)) then (dir := down)
if (key is pressed (key:left)) then (dir := left)
if (key is pressed (key:right)) then (dir := right)
if (dir >> -1) then (
# dir*2 is the frame number, as seen in the spriteset editor
# (walkabout sets have frames 0 to 7)
set sprite frame (armour slice, dir * 2)
)
)
end
include, thirty.hsi
include, scancode.hsi
global variable (1, armour slice)
plotscript, add armour slice, begin
armour slice := load walkabout sprite(17)
set parent (armour slice, get hero slice(me))
# the armour slice is now the last child of the walkabout container slice, so will be drawn on top
end
plotscript, on keypress script, begin
# Only update the slice if it exists
if (armour slice) then (
variable (dir)
dir := -1 #-1 to indicate none of the direction keys are pressed
if (key is pressed (key:up)) then (dir := up)
if (key is pressed (key:down)) then (dir := down)
if (key is pressed (key:left)) then (dir := left)
if (key is pressed (key:right)) then (dir := right)
if (dir >> -1) then (
# dir*2 is the frame number, as seen in the spriteset editor
# (walkabout sets have frames 0 to 7)
set sprite frame (armour slice, dir * 2)
)
)
end
I believe I only modified the walkabout set used and changed the '>' to '>>'.
Sat Jun 01, 2013 6:39 am
Hmm. Well if it shows two armour slices with different directions at once, then that means that there are two armour slices, and it should have nothing to do with how many buttons you're pressing. So it seems that you called the "add armour slice" script more than once. Best would be to call it from the newgame and loadgame scripts. If the hero's armour changes, delete the old slice with "free slice" before adding a new one.
Is there any particular reason you're not using Beelzebufo?
Is there any particular reason you're not using Beelzebufo?
Sat Jun 01, 2013 5:42 pm
I just did a crappy job explaining the problem. Looking at the issue again, it doesn't seem to layer the armor slices, it just displays the incorrect one. If I hold 'down', and then tap 'left', the left armor is displayed momentarily while the hero continues to move down. Interestingly enough if I am holding 'left' and then proceed to tap 'down' I get a comparable error except the engine seems to take priority of the 'down' and will move me down despite me still holding 'left' and having pressed it first. As for Beelzebufo, I had no idea it was available. What exactly gave that away? Thanks again!
Sun Jun 02, 2013 7:05 am
Ah, ok. That's easy to fix by preventing the direction from changing while the hero is in motion (it should only be changed when a keypress actually causes a new moment): I added hero is walking(0) == false
Beelzebufo allows using < and > instead of << and >>
Code:
plotscript, on keypress script, begin
# Only update the slice if it exists
if (armour slice && hero is walking(0) == false) then (
variable (dir)
dir := -1 #-1 to indicate none of the direction keys are pressed
if (key is pressed (key:up)) then (dir := up)
if (key is pressed (key:down)) then (dir := down)
if (key is pressed (key:left)) then (dir := left)
if (key is pressed (key:right)) then (dir := right)
if (dir > -1) then (
# dir*2 is the frame number, as seen in the spriteset editor
# (walkabout sets have frames 0 to 7)
set sprite frame (armour slice, dir * 2)
)
)
end
# Only update the slice if it exists
if (armour slice && hero is walking(0) == false) then (
variable (dir)
dir := -1 #-1 to indicate none of the direction keys are pressed
if (key is pressed (key:up)) then (dir := up)
if (key is pressed (key:down)) then (dir := down)
if (key is pressed (key:left)) then (dir := left)
if (key is pressed (key:right)) then (dir := right)
if (dir > -1) then (
# dir*2 is the frame number, as seen in the spriteset editor
# (walkabout sets have frames 0 to 7)
set sprite frame (armour slice, dir * 2)
)
)
end
Beelzebufo allows using < and > instead of << and >>