Intercepting character position

[jumpjack]

Can I "intercept" character position before it's actually updated, to prevent its updating upon my own conditions?
I see that DestinationX/Y only contain final destination for mouse control, not for keyboard control.

[eri0o]

AGS doesn't provide keyboard controls, so you can do this yourself in your own script, by just updating the position later.

Are you using a script for this? Can you share the script code?

If you want to do this with the pathfinder that is part of the Walk functions, the best way is to use a dummy character and move the character you want to move later based on this dummy character position.

[Crimson Wizard]

I do not understand full situation here, but may mention this article about order of game events and script callbacks:
https://adventuregamestudio.github.io/ags-manual/GameEventsOrder.html

Perhaps it will help to know when to do, after you find out what to do.

[eri0o]

CW, do you think mentioning in that article that rep exec and other calls from script also happens top to bottom from the script list?

Edit: also, I never could understand how the KeyboardControl module should work (it comes with some templates I believe), I have a script module called Controlz, I use it instead.

[jumpjack]

I found that the demo game included in AGS has a keyboard management script which I can edit at wish.

What about the pathfinder algorithm? I need to check not just the final destination, but also the path: the embedded nonwalkable area method is not enough, I need to manually monitor character positions not just by one pixel on his feet, but by an area around his feet, which shall not overlap nonwalkable areas.

In other words, the non walkable area surrounding player's feet, currently used to avoid collisions with other characters, should be used also to avoid collisions with nonwalkable areas.

I wonder if I can build my 10x10 tiles room by "pasting" 100 invisible characters above the 100 tiles I already pasted to build the room, so I can "cheat" and let the engine make the player avoid the forbidden tiles...

[eri0o]

I don't really understand what you are trying to accomplish here. You want the movement to be tiled too? If that's the case you can just "round" the x,y destination points to be in the middle of your tiles and I think it would accomplish what you want.

Do you have a game that you are trying to emulate the movement that you could share a video?

[Crimson Wizard]

In other words, the non walkable area surrounding player's feet, currently used to avoid collisions with other characters, should be used also to avoid collisions with nonwalkable areas.

Cannot you make the non-walkable areas wider, giving them the extra "outline", so that the character walks at certain distance from the forbidden tiles?

[jumpjack]

Player can move freely inside its tile, but can't go to adiacent tile if it contains something.

Click on "start emulator with demo game" to see the game I am trying to implement:
https://jumpjack.github.io/oricutronJS/oricutron.html

[Snarky]

In other words, the non walkable area surrounding player's feet, currently used to avoid collisions with other characters, should be used also to avoid collisions with nonwalkable areas.

That cannot be done.

Cannot you make the non-walkable areas wider, giving them the extra "outline", so that the character walks at certain distance from the forbidden tiles?

... But this could be a workaround.

IOW, instead of extending the character's position coordinate e.g. 10 pixels in each direction, you contract the room's walkable area 10 pixels in each direction, and the end result is (more or less) the same.

None of what you have said provides an argument for why this solution is not workable.

[jumpjack]

I can't find any example or explanation about sprites collisions management, any suggestion? I see I can monitor collision of objects and characters, but nothing specific about sprites (more specifically: dynamic sprites).

Are dynamic sprites the only AGS items I can programmatically create? no objects neither characters?

And, as I already asked above: can I access/customize the pathfinder algorithm from a script?

[jumpjack]

I see these 3 functions in the editor 3.6.0RC3:

• AreCharactersColliding
• AreCharObjColliding
• AreThingsOverlapping

But only one is documented both in offline and online help, "AreThingsOverlapping". Maybe the others have been deprecated in 3.6.0? I see that there are Character.IsCollidingWithChar , Character.IsCollidingWithObject, Object.IsCollidingWithObject  , maybe they replace the missing global functions?

But I don't understand if I can create objects and characters at runtime.

[Khris]

Afaik objects and characters cannot be created dynamically, no. A dynamic sprite is just a bunch of pixels, it doesn't have a position for instance. That's why a sprite collision usually only makes sense in the context of assigning the sprite to an object or character.

One way to solve this is to create you own entity instance, an array of struct based objects that have a sprite and a position. Now you can get the surface of the sprite and iterate over its pixels, then add the position and collide the result with another entity.
In a 2.5D Iso game you usually only need to collide the footprint, and it gets even simpler if you only need circle vs. circle or circle vs. line.

Re the pathfinder: no, you cannot customize the algorithm in any way. However direct character control doesn't require pathfinding at all; the character will simply move in a direction until they hit something.
AGS supports this by providing a Character.WalkStraight() function. Keyboard modules usually send off the character like player.WalkStraight(player.x + 10000, player.y);

[Crimson Wizard]

I can't find any example or explanation about sprites collisions management, any suggestion? I see I can monitor collision of objects and characters, but nothing specific about sprites (more specifically: dynamic sprites).

The collisions in AGS may be misleading if not confusing at first; primarily because they were meant to emulate some old adventure games and also assume a side-view game.

1. Characters and Objects have Solid property. If this property is set, they actually paint "holes" inside walkable area mask, and update these "holes" as they move. These are rectangular holes positioned around their "feet", and this is what you may see on a walkable debug overlay. These extra holes prevent other character from walking over, so it looks like a collision test. The sizes of these "holes" are determined by BlockingWidth and BlockingHeight properties.
Painting over a walkable mask yourself (as you already do) would give precisely same result.

2. The "IsColliding" functions. Their behavior depends on the kind of object.

Character.IsCollidingWithChar, Character.IsCollidingWithObject functions are special, because they are testing against some rectangular areas at their feet; but I cannot remember if it's exactly the same area as BlockingWidth/Height or some arbitrary one; knowing AGS it could even be some hardcoded factors.

Object.IsCollidingWithObject tests full bounding rectangles of two object sprites.

AreThingsOverlapping also tests full bounding rectangles of two sprites (characters or objects).

But only one is documented both in offline and online help, "AreThingsOverlapping". Maybe the others have been deprecated in 3.6.0? I see that there are Character.IsCollidingWithChar , Character.IsCollidingWithObject, Object.IsCollidingWithObject  , maybe they replace the missing global functions?

There's a table of deprecated functions and their suggested replacements:
https://adventuregamestudio.github.io/ags-manual/ObsoleteScriptAPI.html

[eri0o]

Here's a way to do isometric movement

- divide the walkable area instead of a tile, in quarters, so a corner gets only a quarter of a tile, a border half tile and inner regions get full tile.

- divide the rest of the map in two layers, background and foreground. Split wall and wall-like tiles in the middle, the upper half goes to the foreground, the bottle half goes to the background.

This way there should be no overlapping - IIRC this is how things were done when sorting was too expensive, or not possible in game consoles.

[Snarky]

I suppose the pathfinder might be relevant for NPCs, but it's still not clear why you would need to customize it.

[jumpjack]

I can't find any example or explanation about sprites collisions management, any suggestion? I see I can monitor collision of objects and characters, but nothing specific about sprites (more specifically: dynamic sprites).

The collisions in AGS may be misleading if not confusing at first; primarily because they were meant to emulate some old adventure games and also assume a side-view game.

1. Characters and Objects have Solid property. If this property is set, they actually paint "holes" inside walkable area mask, and update these "holes" as they move. These are rectangular holes positioned around their "feet", and this is what you may see on a walkable debug overlay. These extra holes prevent other character from walking over, so it looks like a collision test. The sizes of these "holes" are determined by BlockingWidth and BlockingHeight properties.
Painting over a walkable mask yourself (as you already do) would give precisely same result.[...]

I suppose the pathfinder might be relevant for NPCs, but it's still not clear why you would need to customize it.

Looking at how character move with debug mode enabled to show walkable area, apparently it seems that check is performed on single pixel on foot of the character versus edges of nonwalkable area. In other words, the "nonwalkable hole" around character's feet can overlap the nonwalkable area, as long as the single pixel at (playerwidth/2 , playerheight) is out of the area.

Can this be considered a bug? (I opened an issue, if it's not a bug it will be closed, but it will remain as useful information for posterity).

[Crimson Wizard]

Looking at how character move with debug mode enabled to show walkable area, apparently it seems that check is performed on single pixel on foot of the character versus edges of nonwalkable area. In other words, the "nonwalkable hole" around character's feet can overlap the nonwalkable area, as long as the single pixel at (playerwidth/2 , playerheight) is out of the area.

Can this be considered a bug?

No, this is not a bug, this is an intended behavior of AGS. I tried to explain above, that this "hole" is used only to prevent other characters from walking too close to the "solid" character.

Yes, like you say, when calculating a path, the check is only performed against a single pixel on foot of a character, and not the area around it.
IIRC, this particular character's "hole" is edited out while calculating the path, so it does not block itself.

[jumpjack]

I tried to explain above, that this "hole" is used only to prevent other characters from walking too close to the "solid" character.

Yes, this is why it looks like a bug: because the character nonwalkable area behaves differently depending on what touches it: a solid body can't cross it, a solid wall can cross it.
Anyway I'll disable mouse and use only keyboard control to override this behaviour.

[Crimson Wizard]

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?

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.

[Snarky]

Yes, this is why it looks like a bug: because the character nonwalkable area behaves differently depending on what touches it: a solid body can't cross it, a solid wall can cross it.

It's not a bug, it's perfectly consistent behavior. Characters have a position coordinate. Walkable areas define where characters can walk, i.e. their valid position coordinates. The blocking rectangle has nothing to do with it; it is strictly about how close other characters can get to the character, and this is very clearly documented.

It is not a matter of collisions, as you seem to take it. For example, two characters' blocking rectangles can intersect without problem—no "solid body collision check" is made. It's just that their positions can't enter inside the other character's blocking rectangle (while walking normally).