Is there a design/architectural reason why connections don’t have tags, and ITraversalProvider doesn’t have functions for CanTraverse and such that take a Connection?
This is one of many modifications we’ve added to our older modified version of the library, but it seems like a significant oversight that the core plugin doesn’t treat connections as discretely tagged elements of the graph, suitable to pathing capability filtering.
Jump/Climb/Door/Break/etc type traversals are functional characteristics of the connection between nodes, and most of the time, it doesn’t make sense that any of these aspects are associated with the destination node itself, but rather the connection between nodes.
It was easy enough to add support for multiple connections to another node, but my worry is that there might be some hidden gotcha with allowing multiple connections between 2 graph nodes. My modification here was a simple addition of including a tag match in the AddConnection in addition to the node equality test.
We’re using layered grid, but connection level tagging is important for navmesh too, so I’m unclear on why this has been left out, and whether I’m missing something else that provides this functionality.
I see a 14 year old post about it being worked on, and as far as I can tell, it’s still not present.
My initial thought is that anything that I’d want to do with the Connection having a tag I could do with finding the tag of the next/current node. I saw in your other post you’re using an older version, how old of a version are we talking here?
I think this is down to a very individual use case really. I can definitely see some use cases where having Connections be tagged (tbh I don’t even know how it would work. Would it hold all relevant tags or something?) may be useful, but in most scenarios I can imagine programmatically checking the adjacent nodes tags may work well enough if not better.
What’s your specific use case for wanting Connections with tags though? I’m very curious
Tags on nodes are completely inadequate for most types of traversals.
Nodes are areas you can stand and move freely within, A connection describes how to go from a node to another. They are different concepts, spatially, and navigationally.
Examples
jump/climb - to move from one node to another via a jump is a characteristic of the connection between the nodes, not the destination node or the source node. Putting a jump tag on either node gives ambiguous meaning to that node, and interjects jump contexts into AI that might simply be walking around on a rooftop. The source/destination doesn’t require jumping in any other context than taking that connection. This isn’t really preference, it’s just not achievable properly without navigation context on the connections themself, because data that lives on the node is ambiguous. All the nodes on that rooftop are navigable with the simplest of units. To be able to jump from one area to another is an entirely different piece of navigation data that should be tagged independently, and exist independently for situations where it may need to hold additional metadata associated with that traversal.
Doors - doors are often a planar boundary between nodes, not a node itself. In fact, it’s problematic to mark off an entire node as a door, for the same reason it isn’t a good representation for jumps. Only 1 of the 4 directions(ie connections) of a door node involve the need to interact with the door, so naturally it makes more sense for that context to live on the connection, where an AI that can’t utilize doors isn’t bizarrely prevented from using the door node, when all you really intend is for the AI not to be able to use the door connection, ie, the planar barrier between nodes that requires opening a door to navigate.
I have expanded the library for our use to facilitate tagged connections with metadata. I asked about it because even as I took a look at the newest version of the library to try and get an idea whether we should update, I was surprised to see such a fundamental element of navigation still missing from the core library.
Here’s an example of what my modifications to the library have gotten us. Tags on connections are crucial for representing most traversal types. I’ve also needed to relax the 1-1 connection limitation the library assumes. Some of our units can operate doors. Others would have to break through them.
Putting a door tag on either of these nodes is a broken substitute for having it on the connections. This is pretty self evident. The presence of the door has no bearing on the navigability of that node outside the specific circumstance of going in 1 of 4 directions. And you certainly don’t want someone who can’t operate doors to be unable to path through that node in all those other directions that don’t require taking the connection through the door.
Fundamentally, a custom connection is meant to facilitate a special action that can be taken to connect one location of the navigation to the other.
Plus, you have to remember that there could be many different ways to jump/climb into a node, just as a single node can have multiple doors connecting into it, but you wouldn’t tag the node as a door, because the door context is only relevant if needing to traverse one of those door borders.
For what it’s worth both jumps and doors are two of the primary examples of how Offmesh Links can be used. Tagging is, typically, for swathes of areas of a map while individual behaviors like walking through a door aren’t really for the connection between graph nodes.
I say typically though, because your solution is also 100% valid and may work better in some folks use cases. Should you feel like contributing it, you’re free and encouraged to package your changes to a repo where others can use them should they want the same funcitonality! That is, given you want to spend the time doing such. (If you do be sure to strip out the Astar package ofc!)
Yes good point. Unfortunately, in the old version of the library we’re using, NodeLink2 is just a wrapper around AddConnection, with no support for a tag like more recent versions. No hidden internal nodes that act as proxies for the connections tag, or the interface to customize the response to it.
I’m not in a position to update the library right now, and when I do have more time, there’s still that open question of whether I will even continue using it at all. I’d like to, I think, for the nice foundation it provides, but I’m going to need to diverge considerably. It sucks bc I need better off mesh connection support, but I’m not in a position to update the core library, but everything I write as a workaround either makes it harder to upgrade later on, or boxes us into reasons not to upgrade at all, which I definately don’t want.
The most recent listing in the changelog.cs for our version is
I think that’s definitely carrying a bit of the weight of this conversation here That’s closer to the 14 year old post than it is today’s date!
Should you want to tackle updating, maybe in a git branch or something of the sort, we’re here to help with that migration. Not sure if it would even be very effective in your case since you already coded your way around your issues. But if you find yourself needing that help, it’s available!
I definitely want to update, we just have a release looming soon that doesn’t allow the time to do it right now. I hope to get time to do it afterward this release,
That’s closer to the 14 year old post than it is today’s date!