Intercepting character position

[jumpjack]

I honestly still do not understand why cannot you make the non-walking area further from their tiles to compensate for character's sprite width? I think that would be the first thing I'd try, if I were experimenting with such setup. Would not the result look approximately as if the character's "blocking area" was working the way you implied? Is there anything that prevents using this method?

Available walking areas are already quite small, anyway I'll give it a try.

Anyway I'll disable mouse and use only keyboard control to override this behaviour.

I might mention that mouse or keyboard (as an input method) do not enforce walking behavior. It's all in the script, how the script reacts to the player's input, which functions it uses. It's possible to call same functions in both cases.

Isn't pathfinder algorithm hardcoded?

[Crimson Wizard]

Anyway I'll disable mouse and use only keyboard control to override this behaviour.

I might mention that mouse or keyboard (as an input method) do not enforce walking behavior. It's all in the script, how the script reacts to the player's input, which functions it uses. It's possible to call same functions in both cases.

Isn't pathfinder algorithm hardcoded?

The pathfinder is hardcoded, but the reaction to player's input is not. Everything that happens on mouse clicks or keyboard presses is in the game script and may be changed.

If there's a difference in how character walks after mouse click and key press, this means that the game script issues different commands depending on the input event. And it should be possible to alter the script, making them both to produce similar behavior.

What I am trying to say, is that you don't have to drop an input device support only because the original game script causes it to do something that you do not like.

At the moment I do not fully know which walking behavior you are trying to achieve, so I am merely speculating.
If I remember correctly, in the default game template keyboard controls call WalkStraight function, passing relative coordinates instead of absolute ones (like, player.x + X, player.y + Y). It is possible, for example, to do similar thing with the mouse, by converting absolute mouse coords into relative ones.

This is only to clarify existing opportunities.

[jumpjack]

At the moment I do not fully know which walking behavior you are trying to achieve,

You can see here the game I wouold like to port to AGS:

https://jumpjack.github.io/oricutronJS/oricutron.html

Click on START button adiacent to "Start emulator with demo disk (to create filesystem)" to load the game in the emulator.

M = Move forward
B = Move Backward
S = turn left
X = turn right

[Khris]

That link doesn't work for me; go here instead: https://jumpjack.github.io/oricutronJS/
Then click the link at the top (space1999-en.dsk).

[jumpjack]

I honestly still do not understand why cannot you make the non-walking area further from their tiles to compensate for character's sprite width? I think that would be the first thing I'd try, if I were experimenting with such setup. Would not the result look approximately as if the character's "blocking area" was working the way you implied? Is there anything that prevents using this method?

Available walking areas are already quite small, anyway I'll give it a try.

I gave it the try. :-)
I had to reverse the logic: rather than manually drawing walkable tiles, I had to make whole room walkable and "drill" nonwalkable tiles in it; else, by reducing size of walkable tiles resulted in many walkbale areas separated by some pixels...
So, rather than reducing walkable areas I extend non walkable areas.
Note: apparenly it's better, for isometric games, not to extend the nonwalkable areas/tiles in all directions, but only downwards.

[Crimson Wizard]

I had to reverse the logic: rather than manually drawing walkable tiles, I had to make whole room walkable and "drill" nonwalkable tiles in it

Ahh, actually I thought this is what you're doing from the start; I had a wrong idea all this time.

Note: apparenly it's better, for isometric games, not to extend the nonwalkable areas/tiles in all directions, but only downwards.

This makes perfect sense, that amount of "outline" may be different depending on direction. I'm bit concerned about the horizontal corners too, but that's something one may find out by testing.