Two objects with Pathfinding not working correctly. Bug?

0 favourites
  • 14 posts
From the Asset Store
Units do not overlap each other and use different ways if there are several free ways.
  • This is really weird.. I'm not sure if this is a bug or maybe there is some logic to it. See this file:

    For some reason both arrows move the same, although they have different obstacles..

    If you set "Obstacles: Solids" on the green arrow, both arrows move through both boxes! If you delete the green arrow, then the blue arrow begins to move correctly.

  • To avoid wasting memory by creating loads of duplicate maps, the Pathfinding behavior shares maps between all instances. So you can only really have one set of obstacles, you can't have per-object obstacles.

  • Ashley, Thanks for the quick answer. Then why is it working in C2?

    And what should I do if I need two pathfinding objects with different obstacles?

    PS: Sorry, I logged a bug before I saw your answer here.

  • I'm afraid it's not supported. As far as I remember, it never was in C2 either.

  • Ashley, It definitely works in C2. I made that project in C2, tested to make sure it works, then opened it in C3.

    Is there any workaround to use two obstacles maps? Clear and re-add obstacles between each "Find path" call?

    By the way, do I need to execute "regenerate obstacle map" after "Add obstacle" action?

    EDIT: What if I add two Pathfinding behaviors to the same sprite? They still will be using the same one map?

    EDIT2: This is a very odd limitation. Say, you are making a top-down game with many enemy types. Some enemies can't open doors, others can walk through doors, flying enemy can fly across water, ghost enemies can fly through almost everything.. How do you manage all their pathfinding needs with just one obstacle map?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • C3 uses the same runtime as C2 did when you import a C2 project, which has largely unaltered code, so any differences would be unusual. Can you share projects demonstrating the difference?

  • Ashley Well, I was about to face this problem then because this is a really common feature in any rpg game, or in any game at all. Got goosebumps right now =[. So when we have an enemy that must have different obstacle map what would we do? Edit: The only thing I can think of is to re-add obstacles and wait for the next tick to find the path for this object. The problem is that it has a good probability to create glitches as others could use the wrong obstacle map.

  • The pathfinding behavior has been around for years and seems to be working fine for most people. If you have suggestions for new improvements it's probably best to post them to the feature suggestion platform.

  • Ashley Because most people make mario-like games or others that doesn't need a deeply use of Pathfinding. With a more advanced AI, still pretty basic though, we would need this feature.

    For flying enemies I think using some workarounds and bullet behavior should do the job, but it seams a bad way to go.

  • Ashley

    I spent several hours yesterday trying to figure out the problem, so I don't remember exactly what I did to capx file in C3, but at one point it stopped working.

    I tried it again just now -

    capx file in C2 works fine.

    capx file in C3 works fine.

    If I create a new c3p project and copy everything over from capx file - it still works fine.

    But when I re-create the same file in C3 from scratch - it doesn't work.

    So there are definitely inconsistent results...

    Here are two files, they look identical, but if you open both in C3, one works and the other one doesn't:

  • It seems to work if both objects have different values for "Cell border" in Pathfind properties. With the same values for both objects it does not work, no matter in which project. Looks strange to me.

  • kriand, You are right, different cell border seems to work. But then it doesn't make sense, since Ashley says there is only one obstacle map in C3. Maybe this is a bug after all?

  • So it seems like there is one obstacle map per each "cell size+cell border" combination. (not per "cell size+cell border+obstacles type" as logic would dictate). And it actually works the same way in both C2 and C3.

    Anyway, setting different values makes it possible to use separate maps for different objects, which is good. Even if this is a bug, fixing it will cause incompatibility issues for many existing projects, so better leave it as it is.

  • Yes, well, if you change the cell size it has to generate another map, because it can't share an existing map with a different cell size. It's kind of a hack to rely on that though, and if you're not careful you'll end up with dozens of copies of the pathfinding map in memory, which could degrade performance.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)