Epic's Pathfinidng Pack

Oh well that is good to know. That will eliminate the dynamic node from appearing in the list.

In the meantime, if anyone figures out why it still isn't finding any actors, or a fix is added, let me know. It isn't imperative that it be done immediately. This was a side project I have been contemplating for many months now.

You just need to change the callback function from this -

Code: [Select]

private function onActorPick(a:Actor):void
To this:

Code: [Select]

private function onActorPick(a:Actor, point:V2, normal:V2, fraction:Number):void
To fix the error on a single click issue, check if the points are equal (x1==x2 && y1==y2) and just quit without doing the check.

I will certainly give it a try, thanks a lot for the help! Once I get the pathfinding classes to work without the need for XML Documents and everything else implemented, I will put up an example game showing it off.

Lets hope everything goes according to plan!

Edit: It Works! Well, now I just have to get everything tied together and make my modifications and I will update later on if I have any issues or if it is complete.

Thanks again!

OK I am getting implicit coercion errors and I cannot figure out for the life of me why.

This is the error: Implicit coercion of a value with static type Object to a possibly unrelated type Array.

The data is passed several times between classes before getting to the point in which the error occurs. However, I have traced through everything, and at no point does the data go from an Array to an Object, or vice-verse.

If someone could take a look at this, that would be great! Once I get past this part and I can generate paths that actors can follow, I will begin the implementation of the dynamic nodes.

I am attaching a copy of the game for someone to look at as there is too much code to post.

The behaviors to pay attention to are "Create Grid" and "Path"

Edit: Weird, if I cast the Custom Block code itself as an array and set my list equal to that using code mode, then It compiles great! However, if I strictly return the array without the cast, then I get the implicit coercion error. Could someone explain why that is the case?

whoops I realized I forgot to attach the zip file lol

Can you post a screenshot of the behavior in question?  I have a tough time visualizing things like this without being able to see them for myself. 

edit: nevermind I see the zip file now.

Maybe we should add block for raycast? It would make things like this easier.

Actually, I like Alexin's Solution the best as it does exactly what I need it to do. Plus the fact that I receive a list of actors allows me to filter out certain objects that may block the raycast but should not block the path.

Maybe we should add block for raycast? It would make things like this easier.

It's kind of a specialized and more advanced feature, so I think it would be better served as a custom behavior and potentially custom block. 

I have been contemplating on this for a little while now. I can get the code to work in a code block by casting the Custom Block as an Array. I have also been trying to make this as plug and play as possible.

However, I am now realizing that because we don't have custom type attributes, though I suppose it is in a sense possible to do with more custom blocks, code blocks would still need to be used to obtain the individual nodes in the path. Especially since their x and y values need to be obtained in order to have actors follow the path.

I am considering going with that option for now and making the first version of the Pathfinding pack for advanced users only. There are some areas where I think the code can be optimized a bit to look better and possibly use fewer classes/behaviors. Basically I would try to do a second or third run through on the pack to clean everything up as well as try and set it up so there are more DM/Custom Blocks being used as this would make it easier for not so advanced users to work with.

Anyway, until these minor bugs/kinks are worked out, I will continue working and see where this goes.

I'm sure this doesn't look like much, but basically it is an early example of the Pathfinding pack.

So far I have 5 classes/behaviors. 3 of which do not get added to any scene or actor, they just have to exist.

Then there is a Scene Behavior that adds all nodes and creates the "Grid" and has access to all the functions you would need such as adding/removing nodes, adding neighbors for nodes, and of course finding the best path possible.

Finally, the last behavior gets attached to the actors that move along the path, it need a lot more work before it is done, but it does what it's supposed to right now.

The primary goal of this pack is that it is supposed to be used for Top-Down Shooters. So eventually you should only need to designate the Static Nodes for each scene you want the pathfinding to occur on and attach any relevant behaviors. Because of its design focus, everything will be automated, meaning that your enemies will always be moving towards their designated target. They will attack when in range and that is all. Any additional features, will have to come later. Such as the starting and stopping of actors in a turn-based game.

I have rambled far long enough to show off something that may not look so impressive at first glance. So here you go:

http://www.stencyl.com/v10/game/play/2127

P.s This game is finding the best path among 6 different nodes, The lines are drawn from each of the nodes. I will try to get one that shows a more complex layout later on.

OK So I have spent a number of hours between yesterday and today, trying to get a really good complex example going for you guys. Plus it will help me make sure that everything works as it should.

This is no where near the stage of adding in Dynamic nodes, but This is probably one of the most complex grid layouts a user would face. I created a 10x10 grid, and there are 71 different nodes. The most tedious part of this was having to manually enter in the neighbor of every node individually.

Unless making complex mazes like this, there should be no reason to have this many, or more, nodes in a level. That is why the Dynamic node would be put in place. It will allow the path finding algorithm to use the dynamic node as the start node at all times.

I am foreseeing several possible bugs and kinks that will eventually need to be ironed out. Also, because there is a lack of custom type attributes, it will be very hard to make this as user friendly as DM. I plan to document the hell out of it though, so that anyone using it would know what to do.

And here is your game. Click on any white square to move the player to that square. I have only noticed a bug once, and was unable to reproduce it, where the player kept moving and went off screen.

http://www.stencyl.com/v10/game/play/2127

Very cool!  Nice work!

Is this using the A* algorithm?  I'm not completely familiar with it, but is it always supposed to find the optimal route, or just the majority of the time?

To the best of my knowledge this is an A* Algorithm. I am using the classes from this website: http://lassieadventurestudio.wordpress.com/2008/12/09/a-star-pathfinding/

I have made heavy mods to the classes in order to access some data, as well as some corrections to the classes. It should always find the most optimal route. It does this by calculating the length of the paths.

Edit: I can post the game on forge, so someone else who wants to play with it and make modifications can do so. However If I post it, I highly recommend that only Advanced users attempt to work with it. Preferably programmers. In its current state there is little documentation, so it may be hard to follow, but perhaps someone can look at it and point out any areas that could use some optimization.

OK I posted the game on forge. Again, only programmers should attempt to work with it. It is Called "Pathfinding"

Edit: Minor Update, there was an issue where the coordinate of a particular node was incorrect. It has been corrected, so if it appeared it was taking a slightly longer path in some cases, that was why.