Although all the events, zones and nonplayer entities are set on tile coordinates. (movescript is tilebased too), the player entity can stop walking anywhere between two tiles.

Suppose I want to make an area of the game so that the player's hotspot butt can only stop exactly on tiles? Like in FF4,FF5,FF6,Lufia2 etc.

I tried the following:
Hookkey(some key,"moveright");

void moveright()
{
Playermove("r1");
unpress(some key);
}
and similar stuff for left, up and down.
But Hookkey doesn't work with the 'up','down' etc, variables and even if it did, it doesn't really give me what I want.

Eehmm ..... help..please?

I would really, really like an easy solution to this as well. I remember asking about it when pixel-based movement was first announced, and then I forgot about it. Doh.

Ok, I`m gonna try that, thanks.

I hope enough people will bug vecna about this :)
Anyway, how tough can it be to implement? (but what do I know?) Wasn't V1 tile based?

Blue Z's suggestion will either hang verge when you move into obsructions, or walk straight through them, depending on the entity.obstruct and entity.obstructable for the entity. Son in adition to that, you'll need to add your own collision detection for map and entities. The Hotspot doc might help here, but I have full code for it somewhere too. Not too hard, use if (GetObs()) don't move. Bug me for more. I respond to bugging.

Zip

[Edit: ehehe, who forgot to close their <a> As a physic side note, I predict Omni's next post will be talking pants. However he will afterwards redeem himself, and prove me to be a fool]

Okay, I've just written a library that will do this...

Unfortunately, there are two problems.

1) EntityMove will not loop an Entity's animation when called consecutively--thus the animation is disjointed.
2) For some reason, the entity.obstruct flag in my Verge build always returns 0, so there's no way to tell if an entity is obstructable or not in the engine... SOLUTION: all entities are currently assumed to be obstructing. EDIT: The reason it is zero is because I don't think Maped3 is saving the value......so I assign it myself.

So, it works fine, collision and movement wise, but the animation is kinda screwed up. It loops through the entity's frames for a single tile and starts over.

I didn't predict that he would so spectacularly redeem himself though. Maybe I should go back and do so...
Looks good, though I might point out you've basically done exactly what I said, bar the fact you didn't confuse GetObs() with GetTile like I did. :P

if (GetObs(tx, ty) > 0)	return 1;

Suggestions for fixes to current problems:
2) Yeah, it's just that you need to set runtime.
1) Rather than the current 'is movescript done' check, do a 'is movescript ABOUT to be done (with tile based you could do this by checking the entity.hot(x/y)[] % 16 value), and then get the current render string and add one to the number.

Zip

Another good example of me meaning one thing and saying the other. Add one to the MOVEstring value, so:

int ent = your_entity_number;


string direction = left(entity.script[ent]);


int distance = val(GetToken(entity.script[ent], "udlr", 0));


EntityStop(ent); // Possibly... possibly not


// We want to override the current string


EntityMove(ent, direction + str(1+distance));

Make sense? (as always, I have not tested this)

And people let me write the faq...

Zip

I've been kind of banking on proper tile-based movement happening at some point... so I hope it does, or my game's going to be pretty nasty in certain places, like the scripted entities continuing to arse things up, like I mentioned in another thread, and difficult navigation through tightly packed obstructions. Although I also want to use pixel movement on the overworld map, so optional tile movement (for all entities rather than just the player) would be a most wonderful and welcome addition to V3.

Your idea is better. Try it. (Need to schedual the stop right to be bang on with pixels though)

Zip

[Edit: What might help with with either versions is using pixel acurate movement "PM16" and adjusting based on the coord % 16]

Right, well, I've altered the library to use longer loopcodes that allow for more animation.

But for some reason completely unknown to me, sometimes the MoveCode will stop after going just a few tiles. I don't know why, but the entity will just cease to move, and entity.movecode goes back to zero.

So, I've made a few workarounds that let everything run smoothly, but the fact that movecodes are ending and restarting means that even though animation works almost flawlessly, there _will_ be occasional glitches.

The final problem is that currently you cannot interact with zones or entities. Since EntityMove doesn't take into account zones.

I'll add Zone and Entity detection soon. It really is a much simpler version of a pixel-system...it requires you to reprogram nearly everything. Good thing it's simpler.

And, also, by reprogramming everything in pixel coordinates instead of tiles like Zip said, I might eliminate a skipping glitch or two in EntityMove. Unfortunately...all the detection runs on tile coordinates, and I'm not sure I feel like redoing it all now.

Zone Adjacent activation is probably out, though, because the engine can't tell me in VC whether a zone is adjacently activated or not. It can't even tell me the chance...