Advanced Scripting - Theory and Application

Now that I've run out of threads to reply to...

Are there any Hamster Speak Masters out there?

Let's talk about the new nightly features, what is possible, what you're trying to do or would like to see happen.

Free Movement - Arbitrary Frame Count

Walking around based on pixels, with more than 2 frames of animation, with acceleration, and not aligned to tiles. Like Chrono Trigger.

I recently went about this with the new nightly. Thanks to James' "walk tall" demonsration, I was able to figure out how to use more than 2 frames. Essentially, making use of slice lookup / replacing hero graphic every game tick, over-riding the default animation.

Issues:

- Is there a way to suspend the player's input for walking? Otherwise, whatever speed controls you use, it's on top of the hero's default walking speed. The way around this was to use 'suspend player' but this leads to another issue...

- If you have to suspend the player to implement free movement, you can no longer take advantage of the built in catapillar hero following. My idea here is to save previous lead-hero x/y positions and directions, but that's a lot of extra work for something that's already present otherwise. If you don't suspend the player, it works like a charm here.

- Using 'put hero' as the position updating command, my thinking was: I'm still using the 20x20 walkabout except it's invisible, so I can continue to use all the great built-in stuff for obstruction-detection and cut-scenes.

For the most part, yes. Besides having to do an obstruction check before 'put hero', I noticed NPC detection is off. Since I assume it's based on the hero's tile x/y, if you put a hero 1 pixel high on a tile, it assumes the hero is on the next tile up, and it looks messy for the NPC to walk through him.

Is there a way to re-align the hero's slice to correct this? Or a hero-only foot offset?

Yes, "suspend player" is the best way to do this.



Yes, that is unfortunate. If you want pixel-movement, you will have to re-implement the caterpillar party. You can record the hero's position for the last 15 steps, and then set hero 1's position to oldposition 5, hero 2's position to to oldposition 10 and hero 3's position to oldposition 15. That is basically how the built-in caterpillar works.



to figure out which tile a hero is on with pixel-movement, you should get hero pixel x and add 10 pixels. then get hero pixel y and add 20 pixels. Then divide those both by 20.

There's hardly anything more to the builtin caterpillar handling than what James has described. It hasn't quite been carefully crafted to behave intelligently: it breaks in lots of situations. We could do with some script commands for manipulating the remembered hero positions, because very ugly things happen if you start moving caterpillar heroes with scripts and then reenable the caterpillar.

I think you mentioned in IRC that you want NPCs to continue to use (builtin) tile based movement? Well if you really want to attempt this, it would be best to make the lead hero obstruct multiple tiles, not just whichever one they are standing on in the majority. A 7 pixel overlap between walkabouts is quite a bit. So that means obstructing up to 4 tiles. I would just plonk down some invisible NPCs. Something like this:

James / TMC: Thanks again for the help.

Small correction: to handle obstruction checking properly, you actually have to check all four corners of the walkabout or whatever mask, like TMC's example. Oddly enough, it works out with 19s instead of 20s, due to fun begin-with-0 math.

I had to use zones for TMC's example because I found it impossible to tell the difference between npcs on the same tile. In theory it looks totally possible, but don't have time or patience to figure out the obscure plot lexicon.

Would paste the script so far, but it's quite huge. Makes walking around fun again.

EDIT: Hm, suppose if you delete all npc(0), then check for npcs, then place them afterward, it would work out. Will try that later.

Ah yes, using zones is a good way to avoid messing around with overlapping NPCs. However, the idea was that if the copies of NPC 0 exclude all other NPCs, then you would never need to worry about overlapping NPCs in the first place, assuming that all the NPCs use tile-based movement (still not clear on this), and there are no bugs in your obstruction checking, so the hero never ends up overlapping any NPCs.

By the way, this is how you would check whether there is an NPC with ID other than 0 at a tile:

All NPCs use tile-based movement, the built-in stuff. And I always reserve NPC 0 as an invisible step-on to control other NPC movement, (so you don't have to wait for NPCs to get out of places where they block you, (SPELLSHARD)).

Thanks for the overlap check code! It's weird putting in all this code to run every step/tick, back in my day, there's no way the buffer could handle this!

The problem with zone1 is, have to set every walking npc to zone1 and place it on every map (minor chore), so I like the NPC 0 method better.

The problem with pixel to tile obstruction check is that it does not work for maps that wrap, (not without extra coding that I don't think is really worth it.)

To solve the annoyance of having to give each NPC ID a zone to keep them out of doorways and other spots, there was a plan to add 'avoidance' and default zones, see http://www.slimesalad.com/forum/viewtopic.php?p=75076#75076. I guess I'll probably go with the second idea, but I'm not convinced.

Oh yeah, wrapping maps, they're an endless source of bugs.

I can see why you're not exactly sold on either. Think the second one works. It's no more a pain than anything else when defining a NPC.

I mean, unless you'd like to add mouse support and keyboard numpad input... can use the mouse instead of arrow keys. Them dos roots hard to hide.