Extending (Layer)GridGraph

[nehvaleem]

hi @aron_granberg,
I have one question about extending GridGraph and LevelGridNode to store additional data.

I’ve found several similar topics but they are either unanswered or outdated:

Error when extending GridGraph

Hello, I am new to the forum and A* Pathfinding Project. I am attempting to extend GridGraph to enable custom collision implementation. I am using Rotorz Tile System. I would like to say that A* Pathfinding Project is a great feat of craftsmanship, thank you. I am experiencing an error: NullReferenceException: Object reference not set to an instance of an object Pathfinding.GridGraphEditor.OnSceneGUI (Pathfinding.NavGraph target) (at Assets/AstarPathfindingProject/Editor/GraphEditors/GridGene…

Extending Node class to store extra metadata

Hey there, I’m using a grid graph in my game. I would really like to somehow extend the GridNode class to store more meta-data about the node to support systems within my game. Is there any way to do this? I have currently created a new class that keeps a 1:1 map of node meta-data that corresponds to the GridGraph list of nodes; but using it this way has become cumbersome and error prone. Thoughts?

Adding logic to GridNode

I found this: Extending GridGraph to include my game logic data. Best approach? showing how to extend the GridNode with some custom logic but that approach seems to now be obsolete. What’s the new proper way to accomplish the same thing?

What I’ve done so far is:

1. Created subclass of LayeredGridGraph and LevelGridNode
2. In the LayeredGridGraph constructor I’ve changed the newGridNodeDelegate to return my extended node class.

But quickly skimming through the source of LayeredGridGraph Generator there are 2 or 3 calls to the LevelGridNode constructor explicitly. Should I be worried about them or should I override all the methods that are calling it and replace it with the call to my subclass?

I am asking it because at first glance it seems that my custom graph contains my custom nodes, so everything is looking okay, but I have some doubts because of those direct constructor calls that might lead to some unexpected behavior later on.

[aron_granberg]

Hi

Generally, I would recommend instead keeping a Dictionary<GraphNode, YourDataType> to avoid having to mess with the internals of the pathfinding package. But yes, you can create a subclass and replace the delegate if you want. There are a few cases where I’ve missed to use the delegate (I’ll fix those in the next beta update), but they are only run if you either update the graph using the RecalculateCell method, or save and load a graph to/from a file.

[nehvaleem]

It would be awesome if the delegate was used everywhere.

I totally prefer this approach instead of the dictionary to be honest. Also I am loading/saving the graphs all over the place.

EDIT: Oh, I see it is already fixed in 4.3.78, That’s really awesome.
But I have to ask - why would you recommend the dictionary approach? Isn’t that the delegate meant for such cases? My graph subclass basically only consists of the delegate specification, so it is really minimal and I don’t have to mess with any of the internals at all

[aron_granberg]

@nehvaleem

But I have to ask - why would you recommend the dictionary approach? Isn’t that the delegate meant for such cases? My graph subclass basically only consists of the delegate specification, so it is really minimal and I don’t have to mess with any of the internals at all

It’s mostly that the dictionary approach avoids you having to mess with the internals at all. But if the delegate approach works for you, then that’s totally fine.