I am trying to update the playmaker bindings for this framework to work with the new 3.4 version however there are a few changes which I am a bit unsure how to re-factor going forward.
- *Graph.nodes is no longer accessible
This one was the first one I came across, I noticed the GetNodes method which seems to take a predicate as an argument however predicates are normally readonly in nature. So am I right to assume this is not actually a predicate and instead a Func-GraphNode- (cannot use angle brackets) as far as the actual usage for it goes? So I can just get each node, do something with it, then return true?
The other issue is that a lot of existing functions within here use the nodes like an array lookup and just hop around the indexes which is no longer possible anymore as we do not know the order of the nodes being passed back, just that they are going to be passed back in some sequential manner, so is there some recommended pattern to using the underlying nodes in this way?
- NodeRunData has vanished
From a quick look around it seems like this has now become PathHandler, is this correct?
- AstarPath.active.DataUpdate() has vanished
I am not really sure what should be the stand in for this method, could anyone advise?
- CreateNodes(count) no longer returns created nodes
This is fine by itself, however as you can only seemingly get each node individually I am not sure how to best get the created nodes after they have been created, I am hoping the solution to the first question will help solve this one.
That is it for now, hopefully I am just being an idiot and everything is simply changed over, however I tried the documents and change logs but nothing stands out as an answer to the above questions in there…
GetNodes takes a delegate which has a GraphNode as parameter and returns a bool (if it should continue to pass nodes).
So var doStuff = delegate (GraphNode node) { node.Penalty += 5000; }; myGraph.GetNodes (doStuff);
Also note that some graphs, such as GridGraph, PointGraph and NavMeshGraph still have the nodes array since they represent their graphs the same way as before.
Yes, it has been replaced with PathHandler.
CreateNodes is somewhat deprecated now, there were so many cases where the graphs were required to create just a single node instance instead of an array.
I guess I can add another method analogous to CreateNodes, but for a single node in this case. Is it extensively used by you?
Kiriri is still the main guy behind it, I just came onboard to do some refactors from JS to C# for my own project, but hes a bit busy at the moment.
I am currently using PointGraphs for example as a strongly typed graph however it tells me the nodes array is inaccessible (private) so I cannot actually do anything with it.
Might really just be me, but I use CreateNodes all the time If an alternative would be able to save performance on mass creation it would be a nice thing to have If not, it wouldn’t be much of a bother for those people who needed it to just loop single the node creation.
The point graph update is very appreciated btw. It will make things so much easier
Main question for me is still around the nodes array, as you mention above that it is still available but doesn’t seem to be exposed, but no rush I am working on another project at the moment anyway.
Ah, I hadn’t made it public. That was bad of me.
I will make it public in the next release.
You can replace the definitions of PointGraph.nodes and PointGraph.nodeCount with
`/** All nodes in this graph.
Note that only the first #nodeCount will be non-null.
You can also use the GetNodes method to get all nodes.
*/
public PointNode[] nodes;
/** Number of nodes in this graph.
*
\warning Do not edit directly
*/
public int nodeCount;`
How are you using CreateNodes?
The primary reason it was there was to enable creation of node types for a specific graph without knowing the exact type of it, as well as being able to override that method to change the node type easily. The code for it is just a for-loop creating new nodes.
I will let Kiriri answer the CreateNodes question as he has more context than me in that area. Will make the changes to the library locally for now then to allow access to the underlying nodes.
If an alternative would be able to save performance on mass creation it would be a nice thing to have 
If not, it wouldn’t be much of a bother for those people who needed it to just loop single the node creation.