You only have star collision conditions for when Up <= 0 or Up > 1. What about when Up == 1?

In other words, if you miss one mushroom then Up will equal 1 and colliding with the star won't do anything.

Yes, sounds like a good idea. Maybe in combination with the current method. If the cell is blocked, choose the nearest empty cell (because that would be much faster in many scenarios). If A* can't reach that one then get the nearest reachable cell (cell with the lowest H value from the closed list?).

[quote:3qld29iy]I bet if you took away the purple squares and just told it to find a path to the nearest green, it would be trying to move to a square on the inside.

Yeah that would work as well, but then I could also just remove all the solids and then it would be able to find a path to the blue square. I don't say that to provoke you , but merely point out the initial problem.

I wasn't offering that as a solution. Just a test you could do to see where it's trying to find a path to. If it's trying to get to the inside then that would explain why it won't move when the wall is there.

[quote:3qld29iy]

1. The path calculated shouldnt place the nearest empty cell the furthest away from the unit using the pathfinding behavior. Based on the A* algorithm it seems to be wrong, as the cost to move there would be higher than the tile nearest to the unit with pathfinding behavior. And the fact that the pathfinding unit cant even reach that tile, so makes little sense why it then marks this as being the cell to go to.

It chooses the empty cell closest to the destination. It's not going to use A* to find which empty cell is closest to the player because then it would have to pathfind to every cell on the map and that would take forever. And even that would be no use because the cell right next to the player would be the nearest.

If you tell it to go to a green square, it can't because they are solid. So it looks for an empty square beside the green square. Now that empty square might be inside the box or it might be outside. In your first screenshot it's probably inside so there's no way to get to it.

I bet if you took away the purple squares and just told it to find a path to the nearest green, it would be trying to move to a square on the inside.

[attachment=1:34y6gp0c][/attachment:34y6gp0c]

[attachment=0:34y6gp0c][/attachment:34y6gp0c]

That should still work. Units.UID will give you the object's UID. There's no "family UID".

No, you have to use a loop.

There's also int("string") and float("string").

You can have the condition "Bulbasaur: Pick instance with UID Pokemon.UID" which is kind of like saying "if this Pokemon is a Bulbasaur".

Set the angle to 180.

You'll have to implement your own movement. You can use the expressions Sprite.Pathfinding.NodeXAt(Index) and Sprite.Pathfinding.NodeYAt(Index) to get the next x,y coordinates to move to. And Sprite.Pathfinding.NodeCount will give you the number of nodes in the path.

Yeah it doesn't seem right.

[quote:2yalq32w]The problem with that is that the "for each: ordered" (which I tried using UID as test) is an event structure, not an action, so it is not triggered by a button or any other event but it keeps running all the time (useful for update collections of entities inside the game loop, I suspect). If I could do this as a triggered event after a click, It would be perfect.

Sounds like you haven't discovered... sub-events!

[attachment=0:2yalq32w][/attachment:2yalq32w]