When I have two overlapping — or just adjacent — GraphUpdateScene objects, I get inconsistent results on re-scanning the graph. It’s as if they alternate their influence and break the other object around the edges. Here are some screenshots of the setup and results:
(this is all scanning in editor)
Below is the setup on the GraphUpdateScene component.
(These objects have trigger BoxColliders that are not included in the graph scanning)
Is there a way to fix this?
AN ALTERNATE SOLUTION: SCAN FOR TRIGGERS
If I could make the GridGraph scan include triggers, I would not need the GraphUpdateScene objects! I could just put these trigger volumes on the ‘Obstacles’ layers in the GridGraph, which seems intuitive and easy as well!
But since the GridGraph obstacle scan doesn’t include triggers, I need the GraphUpdateScene…
Turning off Update Physics fixed this behavior on my end. If that’s not required you can turn that off and you should be good
I am not 100% sure of the intention of that setting in general or in this use case though if it’s something you need for your project let me know and I’ll tag Aron on this to review if it’s possibly a bug or just something I’m not understanding.
I’m in a thread working on something semi-related so my first thought is, as a test, trying shrinking the collider and see if it still happens? If that fixes it you may want to consider using the list of points. If not let me know!
Of the DynamicObstacle I’m mainly wondering if this happens if neighboring nodes are being caught in the update… but then why would that be clearing thier tag specifically Time to open Unity and investigate
Yeah it grabs the bounds from the collider. Just looked through the code and it’s pretty much just the bounds of the collider from what I’m reading. (As well as the bounds of where it was before to rescan and restore those nodes)
So I’m getting a little closer to a workaround/solution.
Turning off “IsTrigger” on the GraphUpdateScene’s collider fixes the update (preserves tags).
I toggled “IsTrigger” DURING playing.
But then, for this to also work when starting the game (and the initial scan):
the collider’s layer must be included in the scan
the collider must not be a Trigger.
=> Which then causes the grid to be ON TOP of the GraphUpdateScene collider:
It’s kind of weird that GraphUpdateScene works at “initial scan” with a Trigger collider, but when updating the graph it no longer works with a Trigger collider?
EDIT: Actually, nevermind this. I can’t find a combination of these settings at edit or play time that will leave the tags alone without putting the grid on top of the marker collider.
(But I am not familiar with the flow of GraphUpdateScene / DynamicObstacle is… Does a DynamicObstacle trigger a complete re-scan? Are GraphUpdateScenes supposed to re-apply their properties after that? Or is DynamicObstacle actually supposed to leave the tags alone ?)
3) Using Points
So I tried using the points array instead of a collider (which is much less convenient for editing in this scenario, but that aside).
So, verdict: I’m stuck! I tried every combination of settings I could think of! I tried toggling IsTriggerafter scanning the grid at runtime, etc. But nothing gives me the desired behavior of just leaving the tags alone!
Hmm I’m gonna tag @aron_granberg here because it’s feelin’ a little buggy when I play around with it too. For now though, you can keep this from being an issue by scanning affected areas after the DynamicObstacle moves when near it, to have the tags remain. Not an ideal way of doing it, but so long as we rescan to fix the issues that the DynamicObstacle is creating we should be good temporarily
Heya @tealtxgr@aron_granberg ,
I’m still having this issue. I updated to the latest version (5.4.3) hoping that there would be some changes, but I’m still stuck!
Placing a DynamicObstacle removes surrounding tags
Here you see that when I place an object that has a DynamicObstacle on it, it resets the Tags in the adjacent grid squares (near the front of the car).
(Those squares had a ‘NotBuildable’ tag on them, which got removed.)
Scan after every placed object?
This seems to work but I am worried about performance?
This is the first time I’m seeing this game in motion and let me say first, it looks very good! Nice work!
This isn’t too terrible of an option really. Especially if you only scan the surrounding area I can’t imagine this eating too much performance, since it’s not every frame or anything.
What’s happening is that the DynamicObstacle tells the graph: “hey, recalculate nodes completely from scratch, assuming the world changed in this particularregion”. This will require it to recalculate nodes in a slightly larger region than the passed bounds, to ensure it takes all collision settings into account. And recalculating nodes from scratch involves resetting all tags.
There are some workarounds for this:
You can modify the DynamicObstacle script (or make your own copy of it) so that whenever it creates a GraphUpdateObject, you also set guo.resetPenaltyOnPhysics = false;. This will make it try to preserve any penalties and tags on the nodes when they are updated.
Instead of assigning tags using manually graph updates with guo.setTag, you can for example use the Per Layer Modifications rule in the grid graph settings. See Grid Graph Rules - A* Pathfinding Project . This allows you to have colliders in specific layers, that when they occupy a node will cause that node to get a specific tag. This is much more robust, but it does require you to actually have colliders in place. You still need a graph update to make the graph notice the object, but the graph update can just recalculate the nodes from scratch, you don’t have to manually tell it to set the tags, as that will be done automatically.
Btw. Got to agree with @tealtxgr . The game looks really nice
Thanks to both of you! (it’s called GARBAGE COUNTRY, it’s half driving, half Tower Defense). And A* project has been great! I’ve gone from grid to recast and back and it’s great how flexibly it all works! And now I’m even tying the “Can I build here?” logic into A*, through tags, which is also pretty great!
I think this is what I’m doing now!
Setting up rules for that layer plus calling Scan() after each object gives me a working situation! And performance should be fine, as @tealtxgr mentioned, the grid is tiny to small anyway.