Messages

I think the main issue is that the engine should not go on with an arbitrary value for the sprite: a program should never act "on its own", inventing a pointer!

It's not an "arbitrary value," it's 0, aka null.

[/quote]
If 0 and null are considered "the same", we have a serious problem here.
Anyway I leave the discussion to AGS experts, because I found the solution for my script.

Whatever is happening here (and I don't understand anything yet  ), I think the main issue is that the engine should not go on with an arbitrary value for the sprite: a program should never act "on its own", inventing a pointer!

Possibly this mechanism is a precaution introduced to prevent game from crashing in production, but I think it's mandatory for the editor to warn the developer that there is a serious error (a missing pointer!) not managed by developer. The final user would only see a weird unexpected object on the screen, and the game would not crash, but a wrong item on the screen possibly  could even prevent the user from finishing the game: he would get stuck for unknown reason, and this would make him VERY sad, and he would throw away the game. This could even happen in first room, and the game would never be played.

Opened issue, with screenshots and full code:

https://github.com/adventuregamestudio/ags/issues/1882

Thanks. I already modified the original script, which moved character horizontally and vertically, but I needed diagonal moves.
My character has only 4 directions, unlike the one in the demo, which I am currently still using.

If this is what actually happens, then it of course should be considered an engine bug. I would separate solving the bug and workarounds; and I'm mostly interested in the bug details atm. There's a ticket opened about same problem: https://github.com/adventuregamestudio/ags/issues/1879
Ideally we'd need a walkable mask, and an example of starting position / Walk command arguments which causes character to stuck. This would help to reproduce and diagnose the problem.

Yes, that is MY ticket. :-)
I just attached there the game and the mask.

Issue opened  in github:

https://github.com/adventuregamestudio/ags/issues/1879

Reopening this ancient thread to propose a generic solution.

Adding this statements inside repeatedly_execute() function in global script should fix the issue:

Code: ags

 if (GetWalkableAreaAtRoom(  player.x,  player.y) == 0) {
   cEgo.PlaceOnWalkableArea()
}

This places the player in closest walkable area as soon the player itself is detected as being out of any walkable area.

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.

[deleted]

Sometimes it happens that my character moves to a location where it cannot move away anymore, nor by mouse neither by keyboard. Apparently if walks to a nonwalkable area, and it can't get out anymore.
I don't know how it can get there, but once it happens, how can I unlock it? How can I "undo" the character to previous position upon detecting no further possible moves?

Notes:
- V. 3.6.0 RC4
- character is not at room edge
-  I am not using "adjust speed" or "scaling"
- room is static, not scrolling


edit:
I don't know if this can help, anyway I logged these positions before character getting stuck:
(w and w are walkable area in current screen/room position)

2023/01/04 12:09:21 - x,y,w,w = 164,83,1,1
2023/01/04 12:09:21 - x,y,w,w = 168,85,1,1
2023/01/04 12:09:21 - x,y,w,w = 171,86,1,1
2023/01/04 12:09:21 - x,y,w,w = 174,85,1,1
2023/01/04 12:09:21 - x,y,w,w = 178,83,1,1
2023/01/04 12:09:21 - x,y,w,w = 175,80,0,0

Here I even detected a move inside a non-walkable area:

2023/01/04 12:09:21 - x,y,w,w = 170,86,1,1
2023/01/04 12:09:21 - x,y,w,w = 173,82,1,1
2023/01/04 12:09:21 - x,y,w,w = 177,80,1,1
2023/01/04 12:09:21 - x,y,w,w = 178,79,1,1
2023/01/04 12:09:21 - x,y,w,w = 175,80,0,0
2023/01/04 12:09:21 - x,y,w,w = 171,82,0,0

I implemented this "emergency function" which brings the character back to last valid position while saving debug data previously logged:

Code: ags

   if (GetWalkableAreaAtRoom(  player.x,  player.y) == 0) {
    for (int index=0; index < 1000; index++) {
      //debugPrint(String.Format("x,y,w,w = %d,%d,%d,%d",  prevXarr[index],  prevYarr[index],  prevWarr[index],  prevW2arr[index]), false);
      if (prevWarr[index] !=0) {
        player.x = prevXarr[index];
        player.y = prevYarr[index];
      }
    }
  }

I put it inside repeatedly_execute() in global script: given that in no case the character is allowed to be into a nonwalkable position, as soon this condition is detected, the position is brought back to last valid one. I don't know if this is the best method, or if it would be better to just call cEgo.PlaceOnWalkableArea() upon detecting character on forbidden position, but I wanted to log the positions which led to the wrong position.

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

Note:
the background.DrawImage statement is there just for debugging, to see if I was doing something wrong with overlay: it draws exactly what the overlay statement should draw (flipped sprite), but it has no real use, because I need the player to pass behind the drawing, hence I need an overlay.

My source is currently a mess :-) , anyway how do I upload a .zip to the forum?

(double post)

[does]

The code snippet I pasted above is taken as-is from my script: all rows are one after the other, all inside the same function; moving the declaration out of the function as first line of the script does not help. The sprite IS drawn and it DOES remain there after function ends... but it's the wrong sprite!

This does not sound normal, I expected Khris's code to work.
If the wrong sprite is one with ID = 0, that's a placeholder, which might mean the dynamic sprite was deleted.
Can you post a code that you tried according to the Khris's advice (and which still did not work)?

It's exactly the code I posted in first message; to be sure, I did split first line in declaration part and assignment part, and moved declaration to first line of script, out from any function, so  I have:

Code: ags

DynamicSprite* flipped;
...
...
other things
...
...
function room_Load(){
...
...
      flipped = DynamicSprite.CreateFromExistingSprite(tileIdNorm,  true); 
      flipped.Flip(eFlipLeftToRight); 
      roomOverlay[overlayIndex] = Overlay.CreateRoomGraphical(screenx - tilewidth/2, screeny - 2*tileheight -3,  flipped.Graphic);
      roomOverlay[overlayIndex].ZOrder = isoX + isoY;
      background.DrawImage(screenx - tilewidth/2, screeny - 2*tileheight -3,  flipped.Graphic);
...
...
}

What is really weird is that flipped.Graphic does contain the right value (65), and slot 65 does exist, because it works fine AFTER overlay.CreateRoomGraphical, in DrawImage.

[nd switches to sprite 0]

When you assign DynamicSprite to an object, it normally is not copied, but referenced by the sprite ID (this is their Graphic property). Like Khris mentioned above, in AGS script dynamic sprites, like overlays, are deleted when the last pointer to them is removed, which happens when the function ends in your case. This is similar to Overlays. As soon as dynamic sprite is destroyed, the game object looses it and switches to sprite 0, which is historically used as a "placeholder".

Can a warning message be added in the editor console? This is an "autonomous behaviour", I would expect a "null pointer error" rather than automatically changing to default pointer, but if the "autonomous behaviour" is designed to prevent game crash, maybe a warning to developer would be enough.

Code: ags

Overlay.CreateRoomGraphical(screenx - tilewidth/2, screeny - 2*tileheight -3,  flipped.Graphic, 0 /*transparency*/, true /*clone*/);

Thanks, it works.

If the first line is inside the function then flipped ceases to exist when the function finishes.
It's news to me that AGS keeps a reference to the original sprite and falls back to it but maybe that's how it works internally.

Anyway, the solution is to add

Code: ags

DynamicSprite* flipped;

above the function, then do

Code: ags

  flipped = DynamicSprite.CreateFromExistingSprite(tileIdNorm,  true);

inside.

The code snippet I pasted above is taken as-is from my script: all rows are one after the other, all inside the same function; moving the declaration out of the function as first line of the script does not help. The sprite IS drawn and it DOES remain there after function ends... but it's the wrong sprite!

[drawImage]

What's wrong with this code?

Code: ags

      DynamicSprite* flipped = DynamicSprite.CreateFromExistingSprite(tileIdNorm,  true); 
      flipped.Flip(eFlipLeftToRight); 
      roomOverlay[overlayIndex] = Overlay.CreateRoomGraphical(screenx - tilewidth/2, screeny - 2*tileheight -3,  flipped.Graphic);
      roomOverlay[overlayIndex].ZOrder = isoX + isoY;
      background.DrawImage(screenx - tilewidth/2, screeny - 2*tileheight -3,  flipped.Graphic);

drawImage properly draws the flipped sprite, but CreateRoomGraphical draws sprite slot n.0, although flipped.Graphic is = 65 , and I have static sprites numbered from 0 to 64.

Documentation:

Code: ags

static Overlay* Overlay.CreateRoomGraphical(int x, int y, int slot, optional bool transparent, optional bool clone)

DrawingSurface.DrawImage(int x, int y, int slot, optional int transparency,
                            optional int width, optional int height,
                            optional int cut_x, optional  int cut_y, 
                            optional int cut_width, optional int cut_height)

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?

[can]

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.

[assume a side-view game]

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).