Post new topic    
Send private message
Layered Walkabout / Visible Equippment / Could use a hand 
 PostSat Mar 07, 2020 3:41 pm
Send private message Reply with quote

I know I read about this somewhere, but can't seem to find it right now, so sorry for asking again an old question Zombie

Basically, I want my player to be able to customize his hero, which would end up in having the player walkabout being comprised of 4 layers:

Basesprite (m/f)
Clothes / Armour

The basesprite and haircut would be chosen at start, clothes and weapon would be dependant on the equipped armour and weapon.
All layers are walkabouts sized the same (to keep things simpler).
(Btw, the character creation menu is not the problem, this works well ;) )

Right now I would change the walkabout to be my basesprite dependent on player choice, no sweat there.
Storing which walkabout has been chosen for the other layers is no problem either (e.g. global variables, for the quickest way, same for the palettes).

Additionally I use the three-frame walking script, and here my dilemma begins.
Right now, it is a tad above my level, but I feel there must be an 'easy' way to simply 'stamp' the other walkabouts atop...

Any suggestions?
Liquid Metal Slime
Send private message
 PostSat Mar 07, 2020 5:22 pm
Send private message Reply with quote
The easy part is loading the additional layers. You can use load walkabout sprite() to make the sprite appear, and then set parent(handle, getHeroSlice(me)) to make it follow the hero's position. (You will likely need to adjust the specific positioning of the sprite with the set horiz/vert align/anchor.)

Animating the sprite is another story. You might be able to simplify it by setting each sprite's frame (hair, clothes, etc.) to the base sprite's frame every tick. I'm not sure what complications that may add, especially with 3 frame walking.
Ps. I love my wife
Slime Knight
Send private message
 PostMon Mar 09, 2020 2:13 pm
Send private message Reply with quote
Oh! Witch2.rpg used it beautifully. Have a look.
Metal King Slime
Send private message
 PostMon Mar 09, 2020 4:33 pm
Send private message Reply with quote
Actually, you should write "set parent(slice, getHeroSprite(me))" instead of "set parent(slice, getHeroSlice(me))", so that it will work if there is a foot-offset on the map or if the hero Z changes (eg riding an airship). Those change the position of the hero walkabout sprite relative to its parent, the walkabout container slice.

In order to make the overlays animate, you could write a script that every tick updates the overlaid sprites so that they have the same frame as the base sprite. You will want to make this script loop using timers instead of a while loop, so that it doesn't get paused if other scripts run:

define constant(1, timer: overlays)
script, update overlays, begin
  set sprite frame (..., get sprite frame(get hero sprite(me)))

  set timer(timer:overlays, 0, 1, @update overlays)  # Run this script again next next

But there's a problem. The script doesn't run until the tick after the sprite frame has changed, due to the order in which things are run each frame. Try it and see whether it annoys you. (Increasing the frame rate might make it less noticable). It is possible to work around that problem, using something derived from this script, but it's quite complex.

If you use three-frame walking then you could also make the overlay sprites use more three frames too. If you don't then they will simply use two frames, but everything I wrote above is still true. Find the line in the three-frame script: "set spriteset number(slice, current spriteset)", and add some logic to change the spritesets of the overlay slices too.

The three-frame walking script is going to be obsolete very soon.
Send private message
 PostMon Mar 09, 2020 9:11 pm
Send private message Reply with quote
@kylekrack: Thanks, you did kickstart me here Grin
@bird: Wow. This is helpful, thank you!

Actually, my biggest problems at the moment are nomenclature and slices.
Once I replaced all variable names in the three-frame-walk script (e.g. 'current spriteset' to 'current bodySet') I had less problems.
Not knowing what words are keywords and which are functions/commands isn't exactly helpful, especially while trying to wrap my head around slices and learning the language V

(On a side question, is hamsterscript related to / derived from any other language? Right now I use python syntax highlighting, which makes the scripts by far more readable, but maybe there is something other my editor might know about?)

Right now my script works and puts everything nicely together, but seems to suddenly change the overlayed walkabout from #9 to #1 for some reason...
For the tick problem I just made the hero sprite set in the editor transparent and used the script for the body too. This way, it all was nicely in sync. The miniscule delay on turning around didn't bother me too much (yet).

The three-frame walking script is going to be obsolete very soon.

Might I ask if we talk about a palatable timeframe here, say two to three months or something like that?
If yes I am perfectly happy to let this rest for now 'till I can do without it, as I don't want to use unnecessary code, and guess it might lead to a cleaner implementation for the layers as well.

Oh, and a first look at the character creation menu Smile

Metal King Slime
Send private message
 PostTue Mar 10, 2020 3:34 pm
Send private message Reply with quote
That's a beautiful menu!

The syntax of HamsterSpeak is highly unusual; unfortunately you probably won't find any other language supported by your code editor of choice that is whitespace-insensitive. One solution is to write all names in your scripts in camelCase, like other languages. I wrote a HS mode for emacs myself. Syntax highlighting is very nice to have. There's a language definition for Notepad++ available, and I think some people in Discord also created their own for... VSCode? Sublime Text? I can't remember. Or you can use Hamster Whisper, which has a help key to show the documentation for the command under the cursor; very helpful.

Ah! Making the walkabout sprite (body sprite) invisible is a clever workaround.

I want to switch to the new sprite animation system this month, in time for the next release. That will then mean that I can expose the ability to add more frames to spritesets (it's already implemented but disabled, because the builtin animations wouldn't use the new frames, and thescript commands haven't been updated yet).

In fact, I also wanted to have builtin support for automatically changing the frames of walkabout overlay sprites, so that they match the direction/frame of the base sprite. It's a common thing to want to do. But that will take me longer; it might still be a long time away.
Display posts from previous: