Im not sure what you mean? The red object is not the same as the blue object, also using the player object is not the same as using the family object and im testing towards the enemy object. If I add the enemy to its own family and do a Player LOS to Enemy family where player is not part it still doesn't work.

Problem Description

When using the LOS and families obstacles are ignored.

I have made an example where there is a player unit and an enemy and a green box working as obstacle with a solid behaviour.

When I use the LOS that is added to the player unit it self, it works fine.

Using the one that is added to the family which uses the exact same settings. It doesn't see the green box as an obstacle.

Description of Capx

Check line of sight between 2 objects, using a LOS added to a specific object and one add to a family.

Observed Result

LOS doesn't work when its a family.

Expected Result

That it would be like any other behaviour that is added to a family and can be used by the children.

Affected Browsers

All

Operating System and Service Pack

Windows 7

Construct 2 Version ID

r185

Just wondering how do you know its GC "Pauses" and not something else? Are there anything about the way these lags behave that makes you think its this.

UPDATE:

I modified the program a bit, so it works now. However the solution is not really perfect or optimal I think.

But the idea is to add what I call "Path mesh" in lack of better words. Which is indicated by the red tiles.

Checking where this mesh is placed in relation to the solid target, it can find the correct path to any of the sides, except diagonal as I haven't made that. But in cases where there are mesh in both directions, it rely on the path finding to fail to find a path so it can check the other cell. Which ofc shouldn't really be needed and this way of doing it will require a lot of correctional code to make it work under all possible circumstances I could imagine if it was a bit more complicated setup.

Problem Description

Not sure whether this was a bug or not at first, im now pretty sure that it is not working as intended.

The problem is that the path finder give you wrong results regarding whether a path can be found or not. And that the calculations or way It figures out what cell is the best alternative is not working correctly as it ends up selecting invalid cells even though others are valid.

Here is a short example:

Shows the starting position of the unit. And the big green square is a solid.

If the unit is told to move to either the left or top side it will work fine.

But when told to move to right or bottom side it fails.

Doing some testing it seems to indicate that these two sides have some problems, as moving the starting position doesn't have any effect.

Result in the same problem

It seems to be that a target destination to an empty cell near the original target when its a solid is not found correctly and therefore gives you wrong results.

Using the above example where the unit is starting above the big green square, the possible paths to the destination and the best possible path (indicated by the red square) to the target would be like this, so there should be no reason for it to give you a path not found.

Description of Capx

Will just path find to a selected target. chosen by left mouse button.

Steps to Reproduce Bug

Click any of the solid tiles on the right or bottom side.

Observed Result

Will give you the result that no path could be found.

Expected Result

That it finds a path to the best nearest empty tile that it can reach.

Affected Browsers

All

Operating System and Service Pack

Windows 7

Construct 2 Version ID

r185

Don't think it have anything to do with this version as I believe this problem have been there for a very long time.

It can't find a path to a solid, it can only find a path to an empty cell.

The closest empty cell is within the square.

https://dl.dropboxusercontent.com/u/109 ... reen_3.jpg

Your solution is to find the closest empty cell that is not blocked off.

There are several ways to do that, but the simplest relies on the fact that you know the cells within the square can't be reached.

Which is essentially what you did when you filled the square.

I think we are talking a bit pass each other. The screenshot that you posted is the exact problem that im referring to. Normally or if you selected a tile on the other side or the top it would find a path there, so its not really normal as its failing is just as normal <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">. But at least this is the same as what is stated in the manual.

[quote:1z2qdgtj]If you ask the pathfinding behavior to pathfind to a destination inside an obstacle, it will simply find the nearest clear cell and pathfind to there instead.

The problem is that it doesn't seem to care whether that cell is actually reachable or not, it just select the nearest one. And since the unit is placed at the spot it is in the screenshot, the nearest cell when you select a top tile is also the cell above the selected tile and its the same if you select a tile on the left side. However when you select a tile on the right or bottom side, it find a cell inside the locked off square and then try to path find there. So it based on the units position compared to where it is told to move, so if I moved the unit somewhere below and to the right of the big square it would be able to find a path to a tile on the right side and on the bottom, but then the top and left side would just fail.

My point is that the path finding seems to work in a way , that if you had to travel somewhere for instant with a train and had several train stations from where a train might get you to your destination, just chose the nearest train station and went there to find out that no train could take you to where you wanted to go and then instead of checking the other train station just concluded that then there were no train stations at all that could get you there. But that is concluding something that you don't know and there is a good chance that you are wrong. At least to me it seems to work like that.

When the A* path finding tries to find a path, at least to the best of my knowledge it assign/calculate a path cost for each node or cell and based on these, it finds the best path to the destination. The reason I think or are uncertain whether its a bug or not is because in the situations like the one you posted as well, there are a path to the selected tile, its just that it for some reason when it calculate the path ignore the solid obstacles in the map or it just before it even tries to calculate a path have already selected the destination cell without taking into account whether that is even a reachable cell or not, something could suggest based on the quote that it just pre-select a destination cell if a solid is selected, without actually finding the best nearest cell. But im not sure if this is the case or maybe something else. But regardless of what it is, it for some reason think that the empty tile closest to the unit is just the best tile to go to. And that is what I don't understand, because as with the train stations example above, the purpose of path finding is to find something that is unknown not just assuming that something is just better than something else, and when that fails just conclude that then everything else must be even worse and that seems wrong to me.

This is from a site explaining how A* works, im not an expert in how it works, so there might be other ways that I don't know about. but this explain it quite good I think.

(In this case he is trying to find a path from the green square to the red.)

[quote:1z2qdgtj]Summary of the A* Method

Okay, now that you have gone through the explanation, let’s lay out the step-by-step method all in one place:

1) Add the starting square (or node) to the open list.

2) Repeat the following:

a) Look for the lowest F cost square on the open list. We refer to this as the current square.

b) Switch it to the closed list.

c) For each of the 8 squares adjacent to this current square …

•

If it is not walkable or if it is on the closed list, ignore it. Otherwise do the following.

•

If it isn’t on the open list, add it to the open list. Make the current square the parent of this square. Record the F, G, and H costs of the square.

•

If it is on the open list already, check to see if this path to that square is better, using G cost as the measure. A lower G cost means that this is a better path. If so, change the parent of the square to the current square, and recalculate the G and F scores of the square. If you are keeping your open list sorted by F score, you may need to resort the list to account for the change.

d) Stop when you:

•Add the target square to the closed list, in which case the path has been found (see note below), or

•Fail to find the target square, and the open list is empty. In this case, there is no path.

3) Save the path. Working backwards from the target square, go from each square to its parent square until you reach the starting square. That is your path.

What is interesting here is that he starts from the green square and values are calculated from here until it reach the red square and then Step 3, working backwards from the target square until it reach the starting square. But in "our" case it seems to never reach the target square so it wont be able to work backwards to find the path obviously. But how it even calculate the value of the tiles inside the Green square and decide that one of these are the best one, I don't understand according to what this guy is doing, if its the same approach that are used ofc, as he never calculate the solid (Blue squares), so if he had a box like in my example, the path finding would never add these tiles to the open list as he calls it.

You can read the whole thing in depth here if you want to know it in details. But hope that make my question a bit more clear <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Path finding A*

http://www.policyalmanac.org/games/aStarTutorial.htm

Its the behavior.

You want a grid type response, but its not a grid type movement.

On top of that you're asking it to find a path to a solid, rather than an empty cell.

Also, changing the tilemap at the same time is probably going to mess things up as well.

I don't necessarily want it to be a grid type response, not that it should matter, you could build the same shape with sprites if you wanted and it would end up having the same problem.

There are nothing wrong in telling it to move to a solid, it will just move as close to it as it can, if i fill the whole square with solid tiles and press in the middle of the square the unit will still try to move there and stop when it reach the solid.

Like this:

Changing the tilemap wont have any effect and i could paint it whatever color i liked as long as i don't regenerate the collision map, it stay as it was when it was last generated which was at the start of layout.

There are nothing wrong in what im doing in the program it self, it rely totally on the path finding behaviour to find a path to there it is told.

It would be best to provide a simplified capx that shows what you are doing.

As is there isn't enough information, and we can only guess.

Didn't really think about it, as its really simple. But I understand what you mean. This is all the code and as you can see nothing special going on, just a standard path finding setup.

CAPX:

https://dl.dropboxusercontent.com/u/109921357/Path%20problem/Path_problem.capx

Im aware that it topic is a bit weird as im not sure if it would be considered a bug or just a problem that should be solved, but its an issue that keeps coming back to annoy me, because I cant find a good way to solve it, and also i find it a weird way for the path finding behaviour to work.

I made a very simple program to illustrate the problem.

The Green square is a unit with path finding and the big green square are the collision map (Tilemap). The Idea is to press any of the green squares on the tilemap and get the unit to move there.

So if i press the left side it finds a path and move there like it should. (Purple square is just a cursor)

However pressing the other side it fails to find a path. Same thing happens when you press a square in the bottom part.

The problem seems to be that it doesn't see the empty spaces inside the green square as being blocked, so it select the closest cell that is not blocked, not taking into account whether it can actually reach it or not and then try to path find here, only to figure out that it cant. And without checking any other cell it conclude that no path could be found, even though there are several others that could be used.

So if i block the white spaces it will work. However this is not a valid solution for me and to be honest im not sure how to solve it, or whether it should be considered a bug. Because as it calculate the best path to the target, it would be logic when it got to the green squares surrounding the inner white spaces that the cost to move through these squares should be impossible or at least a lot higher than if it moved below the target. However the path cost to move through the solids looks like its considered a better path than not to, even though it cant.

So i have tried several things to make it work, but none of them have resulted in anything i would consider a valid solution.

One thing i tried was to do it so if it fails to find a path it will just try another cell near the target. This will work in cases like the above example. But this is ofc not very performance friendly as it could result in having to do up to 9 path finds checks per unit if the first one fails.

Taking into consideration that you cant have more than 1 collision map, are there anyone that have experience this and found a good way to solve it?

Yeah I understand that, but I don't see the logic in what you are saying if I watch either "Est. CPU util" or "Frames per second", not both of them. Then the CPU usage goes from 0-4% to around 54-60% but if both of them are being watched it only jumps to around 17% to 23%. It should be the other way round, if both of them are used it should also be the highest CPU usage increase and not the lowest, as it would have to keep track of more.

But the increase in CPU Usage only happens if "Time", "Wall clock time" and "Tick count" are also being watched. If these are removed, then the CPU goes to 0% when one is used, and to around 3-4% if both are being watched.

Maybe im just misunderstanding you and its not easy to figure it out I think when reading the numbers, But it seems that "Time", "Wall clock time" and "Tick count" uses a lot of resources. And maybe being able to disable these could improve the system tab by a lot.

If I add only one of them "Time", "Wall clock time" or "Tick count" and remove the "Performance" all together, the "Tick counter" for instant will increase the CPU Usage to 25-30% from 0% on its own.

EDIT:

But it will only happen if there are layers being watched as well, if there are none it will hardly use any CPU 1-2% when watching these 3 alone and adding the Performance as well doesn't have a huge impact either. But when layers are being added the CPU Usage with the "Time", "Wall clock time", "Tick count" increases by approx. 3-4% per layer it seems. which seems to fit pretty well with the 25-30% cpu increase when one of these are added with 9 layers.

It's nothing to do with which object is selected, it's just the amount of information being displayed in the tables. The system tab does show a lot of information!

I did some testing just for fun and done know if it useful in anyway. But I added all the system information to the watch.

There are 9 layers.

And this is what it shows:

It jumps between 25% to around 40% CPU

So I tried removing "Time", "Wall clock time" and "Tick count" from the watch and this is what I got.

Here it jumps between 0 and 4%

Another test, if I leave everything on watch, but remove all the things in "Performance" except "Est. CPU untilisation" and "Frames per second" this is what I get:

And it will jump between 17% to around 23%

But if I remove either "Est. Cpu utilisation" or "Frames per second" not both of them but just one. then I get this:

And it will jump around 54% to 60% which is a bit weird.

If I remove the "Time", "Wall clock time" and "Tick count" as well then I get this:

And it will stay at a solid 0%.

Anyway not sure its useful, but it seems that depending on what stuff it is told to keep track of, will lead to significant different results, which ofc makes sense. But if the data it gives you varies so much depending on this, then the information it provide is not really reflecting the performance of your game, but rather that of the web browser, if I understood you correct?. And think that would be a bit sad, if that's the case.

The browser has to do a lot of layout and text rendering as the inspector stays up to date. Note it displays data in real-time and keeps the object list up to date etc. That has quite a big performance impact. AFAIK, the only way to avoid that impact is just to not display it. If you switch to a different tab it should be faster.

That's what puzzles me, because the system tab doesn't really show a lot of information, besides the "Performance", "System", "Current layout" and all the layers. So there are no specific object information here. But if I switch to an object tab, the other objects are still kept up to date, but there are no performance drop. So it just confuses me that the only tab that doesn't show specific object information is the one suffering the performance hit from keeping real time data of something that is not available in that view, but are available in the other tabs with no performance issues. Which I would assume that if the other tabs are also able to keep the data up to date in real time, why wouldn't these tabs suffer a performance hit as well?