ez_path -- for alpha testing! Simple Pathfinding.

Could you make anothher version of the DLL that works with A5?

I don't think it's good for a rts. Speed is okay but don't forget that you have a lot of troops out there. I develop my pf for a turnbased strategy game with all its needs (and that is a lot more than rts needs) thus being slower than other pf.

Hello!

Bird, the location of the next node in the path is placed in the following skill slots:

// my._PF_NEXT_NODE_X = x coordinate of the next node to follow
// my._PF_NEXT_NODE_Y = y coordinate of the next node to follow
// my._PF_NEXT_NODE_Z = z coordinate of the next node to follow

(these are defined as...)

DEFINE _PF_NEXT_NODE_X, skill91;
DEFINE _PF_NEXT_NODE_Y, skill92;
DEFINE _PF_NEXT_NODE_Z, skill93;

Also, I haven't tested out the speed of my algorithm, but it should be fast.
Here's the C++ code that traverses the nodes. (This is my own code.)

Code:

---

// This function contains a recursive call, which makes it particulary
// difficult to document.  However, the general idea is to visit each node,
// all the while keeping track of the distance travelled.  If the destination
// node is found, then that distance is returned.  Otherwise, max distance
// is returned.

// while the nodes are being traversed, their "visited" flag is set so that
// nodes are not traversed twice (which would result in an infinite recursion)


int pf_next_node_ex(pf_node *node, pf_node *end_node, int dist)
{
	pf_node *neighbor;
	int path_length;
	int shortest_path_length = 1000;
	int t;

	if (node == end_node) { return(dist); }	
	if (node->visited_flag == 1) { return(1000); }

	node->visited_flag = 1;
	dist++;

	// Foreach path available from this node, find the path's length.  Store
	// the shortest length.  

	for (t=0; t<4; t++)
	{
		neighbor = node->pfp_neighbors[t];

		if (neighbor != NULL)
		{
			path_length = pf_next_node_ex(neighbor, end_node, dist);

			// A path length of 0 indicates that there's no route to the 
			// destination.			

			if ((path_length > 0) && (path_length < shortest_path_length))
			{
				shortest_path_length = path_length;
			}
		}
	}

	node->visited_flag = 0;

	return (shortest_path_length);
}

---

But in all honesty, it's not the pathfinding that's going to slow you down... it's the helper code that you write that's involved in walking the path. It can get pretty tricky. My code handles a lot of that irritating code, like choosing the proper "first node" to take, behind the scenes. Hopefully that extra code didn't slow things down too much!

- Bret

Looks like Dijkstra's algorithm.
However it is completely different to my pf.

Very Nice great job. Looked over the documentation breifly seems to be very well explained as well. I have a quick question . Would it be possible to have different target entitys for differnt models? ex.. I would like to be able to have Guy A go to point A and Guy B to point B. Then could i change that during runtime? so guy A goes to B and vice versa? also is it possible to use this to make two seperate paths included into one level? So for example one path set for vehicles and another path for pedestrians. Sorry for all the questions just curious. It really looks good . Thanks alot.

FeiHongJr,

It should be possible to have 10 entities with 10 different targets... some of which can be the other entities! I haven't tested that yet, and if anyone wants to give it a shot, be my guest! You can change targets at runtime, no problem.

The future version should allow you to move to a target position instead of an entity. The future version should also allow you to put a cap on the maximum path distance, in case your level contains a lot of nodes.

Let me give some thought to the "multiple paths" problem. It sounds possible, but it's not currently supported by the code.

Thanks for the feedback!
- Bret

Might wanna give it an A* version, would add even more to the performance and make it ideal for huge maps, although the dijikstra method you do here works too ; A* just has the hueristic in it. Any chance you'll release the full source? it would be good grounds to develop more onto.

-Rhuarc

Hi Rhuarc,

I'm considering having a free, fully functional "lite" version, and a more full featured version for $10. Because of that, I probably won't be releasing the full source. However, if there are sections of it that would be helpful to other people, I'd be happy to share!

- Bret

Cany check it out, it keeps telling me "no valid acknex dll."
Any idea whats happening here ?

Thanks for seeing what you can do.

regards


p.s.: i know that feeling

well I think that are too much nodes:

the engine freezes at the position on the picture

here you can download the level: CLICK HERE

Hi Samb!

Ouch!!! Well, thanks for running that test! I'll download the level and test it over the weekend. I owe you one!!

- Bret

Good job Bret,

I wish I had more time to play around with it. I did find one minor problem. If the moving entity can't see the first node the program crashes. This could be a problem if someone has wondering monsters that might somehow not be able to see the first node in some circumstance or a moveable object blocks the entity's view to the first node. The program really should just not move the entity and return a 0 or something for move not being possible in that case instead of the program crashing. I suppose this could be tested for in C-Script, but it would be better if the dll handled it I think, or maybe not, but your sample program should show how not to have this happen, because it will eventually happen somewhere when people use the dll.

I do like how simple you made it to use. Very nice.

Loco

Locoweed - Ah yes! You're correct! I fixed the issue and it'll be included in the next update.

Samb - You tripped upon a pretty crafty issue. It will definitely take me a few days to solve your issue. Here's what I think is happening. Each node can have a maxium of 4 neighbors. During the initialization stage, the nodes try to link to their neighbors. In fact, they try to link to ALL of their neighbors. The problem is that nodes don't necessarily know who their neighbors are. They just accept the first ones they can find, which may not be necessarily the closest ones. Once all 4 neighbor slots are full, the rest are ignored.

I need to improve the initialization routine so that it prefers closer neighbors over ones that are farther away. That change will have to wait for the weekend.

Thanks for the bug reports!! I'll get 'em all cleaned up as soon as possible!
- Bret

well I hope you can fix it
then I make a little pacman clon
but very good work
the easiest pathfinding I'd ever seen here

Samb,

This problem turns out to be VERY difficult to solve. I woke up numerous times last night thinking about a solution, and most of them weren't adequate.



The question is, how do you know which neighbors you should connect to? "All of them" isn't always a good idea. Check out this example:



The green lines represent neighbors connected to our source node. The red lines represent a possible path that could be choosen to reach the goal. I might be able to fix this by following closer neighbor nodes first. Yeah... maybe that's the ticket. It would require sorting the neighbor nodes by distance, which might slow down the initialization a bit...

I'll keep thinking on it.

- Bret

Ah...

Sorry for thinking out loud, but I wanted to correct a flaw I made. In the last example that I had posted with the red path.... that path would not have been choosen as the final path. The correct path still would have been used.

I won't go into details, but sorting the neighbor nodes by distance still seems like a great solution. I'll code it once I have a chance. I could leave them unsorted, but sorting them during the initialization stage will potentially save time during the actual pathfinding.

Cheers!
- Bret

Ok!! I think that I ironed out some of those bugs. Download the new version at the same url:
http://www.gamebeep.com/freebies/ez_path_src.zip

There are a few changes, but the most important ones are:

1) The function pf_to_ent() doesn't crash if there's no start node in sight. Instead, it returns "1" if everything is ok and "0" otherwise. It'll return 0 if there's no available start node.

2) After some intense programming, I fixed the "neighbor" problem that was causing some issues. It's ready for round #2 of testing!!


I also added these .dll functions:

DLLFUNC long pf_set_node_collision_distance(var dist)
An entity will reach a node when they get a certain distance to it. This method can set that distance, which defaults to 20 quants.

DLLFUNC long pf_set_max_path(var dist)
Defines the maximum path search distance.

DLLFUNC long pf_set_ent_collision_distance(var dist)
Defines the distance that an entity has to be within its target to trigger the my._PF_REACHED_TARGET flag. Defaults to 10 quants.

I'll write more about these functions later once I update the documentation.

Have fun!!
- Bret

Oh, one other thing. Samb, your pacman level should work with the new .dll. It works for me now!!

And whats about an A5 version of the DLL?

I know i can bee very penetrating

Hi Michael!

An A5 version is still unlikely in the near future. Sorry!!

hey clone
can I set pf_set_ent_collision_distance(var dist) to zero so the enemy wouldn't go directly to the target if he find it?

Samb,

I guess that one of the benefits in helping test out is that you get your wish! I've added the ability to turn off the "line of sight" portion of the pathfinding. I can't imagine many times you'd want to turn this off, but a pacman game is a good example!

Here's how to turn it off:

pf_use_los(0);

Here's an example:

Code:

---

function main()
{
	warn_level = 0; // This is necessary!

	// Open the pathfinding .dll.  Do this before the level loads so that entities
	// can reference the pathfinding .dll in their actions.  Otherwise, the entity
	// actions can start running before the pathfinding .dll has loaded, resulting
	// in an error.

	pathfind_handle 	= dll_open("pathfind.dll");

	wait(3);
	level_load(level_str);
	wait(2);

	pf_use_los(0); // turn off LOS pathfinding step

	// Initialized pathfinding nodes.  Do this after the level loads.  The
	// .dll function pf_initialized() returns 1 when the pathfinding has completed
	// initialization.

	pf_init_nodes();

}

---

Also, I updated ez_path.wdl to contain the new .dll function prototypes.
You can get the new package at
http://www.gamebeep.com/freebies/ez_path_src.zip

Enjoy!
- Bret

Hello again!

If I have time in the future, I might attempt to add some optional dynamic A* pathfinding into the ez_path package. Basically, the logic would be:

Code:

---

if (path blocked)
{
   switch to a* pathfinding to reach next destination
}

---

However, this would require that TONS of little pathfinding entities be added to the level. That's the only easy way I could think of implementing it. On the bright side, you wouldn't need to configure the nodes. Also, I'd use a radius of A* nodes in respect the player's position, which could keep the computations down to a reasonable amount.

For really basic levels, it would be possible to assume there's a flat 2d grid that A* could use. But for complicated levels (think Tomb Raider), I can't think of a way that the A* nodes could be determined at runtime. They would require manual placement.


(The node placement might not need to be this dense.)


Any feedback? Do you think this would be a good feature to add?

Thanks!!
- Bret

Hi clone45,
I resolved the 'no acknex dll' prob.
I have versions 22 and 31.4 but .22 opens files bydefault when I click on them.
Manually opening in 31.4 opens and plays your demo with no probs.
Looks cool and simple and hopefully, usable for the likes of me.
Thanks.

thanks clone
three things:
1. the engine freezes at start. if I reduce the node the engine doesn't freeze
2. If I move the target, the following guy is confused and go some werid ways
3. the engine can't find the new function

here's the level with a really simpel and useless movement script
http://www.sinn-los.de/level2.zip

Thanks for the feedback. Ok, I'm working on it!! It's possible that I didn't include the most up-to-date .dll. I think I did. But maybe I screwed up. In any case, even in the most recent version, you're bug #2 still exists:

2. If I move the target, the following guy is confused and go some werid ways

I'll work on this over the next day or two. Hopefully I'll be able to post a solution shortly. In the meantime, I've updated the .zip file to ensure it contains the new .dll.

One again, that's at: http://www.gamebeep.com/freebies/ez_path_src.zip

Sorry about the bugs. I didn't have the freezing issue on my machine. I'll try to figure out what's going on with that.

- Bret

Great news!!

Ok, I found two major bugs in the pathfinding routine and cleaned them up. The bugs were:

1. I was forgetting to clear one of the node "visited" flags, which caused the pathfinding to break down over time.

2. I had to introduce a more reasonable default for "maximum path search depth", as the nearly infinite search depth took a huge amount of time. The maximum search depth is now 9 nodes. This should speed things up considerably. It can be changed like this:

pf_set_max_path(15);

(Samb, I would suggest putting your search depth at around 16 for the pacman game.)

3. I simplified the routine that finds the "closes first node". I might have to revisit this portion of the code again later.

OK!! The new file is in place and ready for download! Again, sorry for all the bugs, but you know what they say: "Never let a coder test their own code." Let me say, too, if I ever sell a "professional version", everyone who's helping me out will get a free copy.

http://www.gamebeep.com/freebies/ez_path_src.zip

Cheers!
- Bret

ok the engine don't crash but it can't finde the use_lost function again
at some start points the searching guy can't find the path
he go to a node and then go trough a node
then he hits a wall stands there

That's very strange. Could you download the .dll one last time? I added a version number to make sure we're running the same thing. This time, I packaged just the .dll up for you without all of the other clutter.

http://www.gamebeep.com/freebies/ez_path_update.zip

Run your game with the -diag flag and look in the log file. You should see a line that says:

-=-=- ez_path version 0.400000-=-=-

Also, look in your ez_path.wdl file. It should contain the line:
Code:

---

dllfunction pf_use_los(flag);

---

If it doesn't then you're using an outdated version.

Cool! Thanks for sticking in there!!
- Bret

aaahhhh I had a old version in the plugin folder but the new one in the project folder
now It works and it's perfect

but... I need a new function for a pacman game
the searching guy can't turn around in a pac man game
is it possible to put it in the dll that he cant turn around?

Yes! I can do that! I'll try to get it done tonight. I'll need to use one more of the entities skill slots to store the "previous node" to avoid backtracking. However, I'm 99% sure I can do it.

- Bret

ok
and what about a random way for the searching one?
and if he see the player he begin to follow him

think that would be good for ego shooters

Ok Samb! I've completed your requests. Here's the update for you.
For everyone else... I'll create a new complete download package soon.

http://www.gamebeep.com/freebies/ez_path_update.zip


Here's a summary of the changes:

1. I've added a .dll function called pf_set_backtracking(). Backtracking defaults to ON, but using this function, you can set it to OFF. For example:

pf_set_backtracking(off); // do not allow backtracking

2. I've created a new function called fp_get_random_node() which returns a random pathfinding node. An example to move an actor to a random node might look something like this:

Code:

---

	// Fetch the entity * of a random node

	dst_ent = pf_get_random_node();

	// Calculate path to node

	pf_to_ent(my, dst_ent);

	// Face actor to the correct directon

	my.pan  = my._PF_PAN_TO_TARGET;

	// Move actor

	move_mode = IGNORE_YOU + IGNORE_PASSABLE + IGNORE_PUSH + ACTIVATE_TRIGGER + GLIDE;
	ent_move(vector(time * 10,0,0), nullvector);

---

Don't forget that you can use my._PF_REACHED_TARGET to test to see if the target node has been reached. Also remember to test the return value of pf_to_ent. If it's 0, then there's no clear path to the target. (I skipped this step in my example.)

Cool beans! I hope this helps out!
- Bret

One word:

Brilliant.

For those who are interested, I fixed one last small bug and updated the entire package at:

http://www.gamebeep.com/freebies/ez_path_src.zip

This new package contains updated documentation, too.

Enjoy!
- Bret

I will testing it tommorow
today is guild wars day

Oh... bad news indeed.

My main hard drive crashed yesterday. Luckly, I'm pretty careful about backing up my files. Most everything I have is on CD. Also, the drive is now in the hands of a data recovery expert, so if it's possible for me to retrieve my files, I will.

The source code for the pathfinding .dll was on the hard drive and wasn't backed up. If the data recovery guy fails to get any information, then sadly the pathfinding code might be lost. I'm optimistic that I'll get the files back.

In any case, it may be a few days before I'm back up and running. I'll need to buy a new drive, install windows, and basically get my environment back up and running. If you don't hear from me in a while, you'll know why!!

[By the way, this won't affect Game Beep, which is completely backed up and also mirrored on the server.]

Cheers!
- Bret

really bad news
but what you have done in a in the few days was wonderful and if you don't get the code back you are genius enough to make the code new. I'm sure in that

Thanks Samb! Some good news: At the very least, I still have the "core" of the pathfinding code on a backup disk. It's a backup of the original system I used for Legendary Sword. Other good news:

1. There's still a good chance that the .cpp and .h files will be recovered from the busted hard drive.

2. I'm back up and running with a completey new hard drive already.

I'm waiting for the data recovery process to complete before I do much else. Besides the .cpp and .h files, I need my Game Studio registration information too. Mental note: Print out important information in the future. Ha ha ha.

Ok, I'm off to reinstall Visual C++ .Net. I'll post an update when possible!

- Bret

Good news! After numerous hours using a hex editor, I've been able to restore the pathfinding .dll code!! Keep your eyes out for updates in the near future.

Michael - I need to stabilize the A6 version of the .dll, otherwise I'll be developing on two versions simultaneously. It's going to be a long while before I can work on an A5 version (no promises!).

Cheers!
- Bret

Back up your stuff! :-)

Hello everyone!

I just added a nice feature to the pathfinding package: movement smoothing. The .dll can now handle turning your entity for you, and will smooth out the turning radius so it looks more natural.

The new download package contains a demo of this functionality.
http://www.gamebeep.com/freebies/ez_path_src.zip

ALSO NOTE!! The new package prints out a "TRIAL VERSION" message on your screen. The inexpensive ($10??) non-trial version will be spam-free.

In short, here's how the smoothing works:

Code:

---

// Call pf_to_ent.  This pathfinding routine takes two entity pointers as
// arguments.  They are the source and target entity.  The routine calculates
// the shortest path to the target, and sets the direction that the source 
// entity needs to go in order to reach it's target.
// (See documentation for more information)

pf_to_ent(my, dst_ent);

	
// If I weren't using pf_smooth_turn, this is how I would turn my entity to
// face the correct distance:
//
// my.pan  = my._PF_PAN_TO_TARGET;
// my.tilt = my._PF_TILT_TO_TARGET; // <- don't set for first person shooters
// my.roll = my._PF_ROLL_TO_TARGET; // <- don't set for first person shooters

// Call pf_smooth_turn to have the pathfinding .dll turn your entity for you
// in the direction of the next target node (or target entity). If you decide
// to use the pf_smooth_turn feature, you may wish to increase the node
// collision distance by calling pf_set_node_collision_distance(); Increasing
// the node collision distance will result in the actor starting it's turn
// earlier, which is a good idea if the turn takes longer because of the
// smoothing.

turn_speed = 10 * time;

pf_smooth_turn(my, VECTOR(my._PF_PAN_TO_TARGET,0,0), turn_speed);

---

Currently, pf_smooth_turn only works on the .pan of an entity. Future versions will also smooth tilt and roll, which could be helpful in games where 3d movement is possible.

Cheers!
- Bret

Good to hear that you've been able to restore all your code!

This stuff is so ****** amazing !!! I played around with it a bit and the i like it more then i ever liked any other pathfinding system!!!

I only have one question: when/where can i buy it???

Btw, (how) can i load or restart a level without getting the error crash in pf_to_ent?

Hi Toon!

Unfortunately, it's not for sale yet. It still needs some extra features to make it worth while, such as a "pf_to_vec()" function. I also hoped to include "dynamic A*", which will allow your actors to navigate around obstacles and other entities in the level. Plus, it needs more testing! I don't want to sell it until it has been heavily tested!

If you really need the trial version message to go away, PM me and I'll send you a version without that message. Otherwise, rest assured that I'm still making progress on this project!!

Oh, and I'll look into the level load bug today!!

Thanks for the compliment!
- Bret

Hi Toon!

I threw together a quick test level and was able to switch between levels without any crashing. Did you remember to call pf_init_nodes() right after the level change?

Here's the main loop that I added:

Code:

---

	while(1)
	{
		if (key_u)
		{
			level_load("pathfind_level2.WMB");
			wait(1);
			pf_init_nodes();
		}
		wait(1);
	}

---

If you still get the error, run the program with the -diag switch and make sure that your version is up to date. The acklog.txt file should contain:

-=-=- ez_path version 0.440000-=-=-

Enjoy!!
- Bret

i will have a look at this .

Lets assume the target is the player and the example_move is the enemy; can somebody give me a trace example for the enemy? (for shooting)

first screen of "ez_Pac_Man"

okay a new screenshot :]

Hi Toon!

How about something like this?

Code:

---

//
// This code would go near the bottom of example_move.  It is assumed
// that there is an entity* called player.
//


//
// The _PF_TARGET_IN_SIGHT skill of the monster will be set to "on" once there's
// a clear shot at the player.
//

if (my._PF_TARGET_IN_SIGHT)
{
   trace_mode = IGNORE_ME + IGNORE_PASSABLE + USE_BOX;
   trace(my.x, player.x);
}

---

Hello everyone!

Although I haven't posted an update in a long time, I've been working on the pathfinding code on nearly a daily basis. I got A* pathfinding to work -- well -- mostly work. And it's FAST. But, to be honest, I'm a little stuck. I have the node based pathfinding working wonderfully. The A* works great too, although merging them together has been a real problem.

I'm considering making the whole thing open source in hopes that fellow coders will help complete it. It's very close to working, but I'm on the verge of getting a full time job, and I'd like to clear away some projects so I don't feel so overwhelmed. Would anyone be interesting in this offer?

Thanks!
- Bret

Hi clone45

Great work. Your code works very well and its fast. I would like to use the dll in my project. Is it free? Could you serve some more information about using it in more complicated ways?

Hey clone,

I have a few questions about the capabilities of your code.
In my game, when a player (there are multiple players) gets close to an enemy, the enemy will basically start chasing the player. When the enemy is dead it will respawn somewhere and wait untill a player enters its range again, etc. This needs a very dynamic pathfinding algorithm without a maximum amount of entities and an easy way to change the "from" and "to" position. Does your code offer these capabilities?

Sorry I hadn't looked at the code closely, but now I have..
All I can say is.. WOW.. Seems like programming AI will be really easy for me now
I will buy the full version for sure when it's out. One thing I'd still like to know, how is the PF_REACHED_TARGET decided? Does the entity have to be on the exact same x,y,z position or is there a range? (Can I set it?)

PF_SET_ENT_COLLISION_DISTANCE.
arrrgh. Sorry, I'm really posting to soon today.

Anyway, great stuff!

BTW, moet je Nederlands leren in Zwitserland?

Hello everyone!

I'm sorry that I hadn't responded sooner to these posts. Let me give you a quick update. I had mentioned before that I was stuck on a few coding issues. Luckily, I'm making headway again!! I'll hopefully continue with the project as planned!

@Excessus - I'm in the process of mixing some very nice A* pathfinding into the .dll. This means that it will be possible for your characters to use node base pathfinding for 90% of their movement, then switch to more complicated pathfinding once their path is blocked. I've been working on this for quite some time, and it's nearing completion. It's *beautiful* too!!!

I'll post updates when I have 'em! I expect a big update within a week.
- Bret

Hi clone45

I am playing around wit EZ_PATH a while now and i like your pathfinding code more and more. Beside it works really great and fast, there is still left one wish. Under some circumstances calling pf_to_ent(...) results in no path. Could you feed us with a flag like _PF_SUCCESS or somthimg like this. It would be helpfull for coding an AI around your pathfinding code.

best regards, Snake67

Sure thing snake! I'll add that feature for the next release. However, have you tried checking the return value of pf_to_ent()? It should return '1' if there's a path and '0' if there isn't. Let me know if that doesn't work for you!


I'm moving slowly but surely on this project. I'm happy to hear that people like it!!

- Bret

sounds like your making some very good progress glad to hear it. Keep it up and cant wait to see it when its all finished

Hi clone45
I tried again. The function pf_to_ent seems to return always "0"...

Hi Snake!

I'll try to look into this and get back to you! I have some other bugs with the A* portion that I really want to clobber first, but rest assured, I'll attempt to address this issue. It could be a while before the next update, and in the meantime if you can work around it, I would suggest it!

Thanks!
- Bret

Thanks a lot. I am looking forward to your next update...

Hey, I had a minor breakthrough today and finally caught a tricky bug. To celebrate, I'm happy to post a small video of my progress. Note that this extra pathfinding took me absolutely NO effort in my c-script. It's all handled within the .dll. Although I'm technically using A* for the complicated movement, you don't need to set up an A* style grid in your level. Very cool. You do still need to place the pathfinding nodes, just like in the original version.

Once I do some more testing, I'll try to make a more impressive video where more of the entities move around.

Here's the video:
http://www.gamebeep.com/temp/pf.avi

Don't get too excited! It's still going to take me a while before testing is done, and there's always a chance that another clever bug awaits me!

Cheers!
- Bret

Hey thanks for all your hard work man... you're making some nice progress here.

Hmmm... what codec do you need to play that video?

Yea, I'd like to know to.. I opened it in winamp and it crashed. When I tried opening winamp again it crashed again probably because the file still was in my playlist so I reinstalled winamp.

u can open it with windows media player 10

It's DIVX encoded... and I apologize for the strange format. I was really trying to keep the size down. Thanks for the note, TripleX !

Hi clone45

Is your pathfinding code going ahead? I am awaiting it eagerly...

Hi Snake!

I'm still stuck on some very nasty bugs when doing the A*. Tell ya what.. I'll try to fix the issue that you had next time I work on it instead of trying to fix the new features. I'll keep you posted!! I recently landed a full time job, so it slowed down development considerably. I'm still on it though!

Cheers!
- Bret

Thanks clone45, good luck!

Hi Clone45
I've tried your ez_Path and it's really nice..
I've done a more or less the same Path finding technique using scripts a couple of months ago, but yet didnt complete it to consider Entity blockage during movement as you did.

I have one comment however after testing your ez_path. If a path is blocked, the algorithm wouldn't find alternative paths, and thus its movement is blocked.

Good contribution, thank you

Hi clone45

How does your code go? If you could only fix that bug (your code is great, even without A*)...

cheers, snake67

Sorry for the stupid post of mine , didnt read the rest of the thread so didnt know you were working on entity blockage!!

Hi snake! I PM'ed you a while ago with a potential fix. I guess you didn't get it?

Well, I have some bad news and some good news. The bad news first. Although I'm making progress on the A* pathfinding additions, it's going VERY slowly. So slow that I fear that it won't get done. The problem is twofold: 1) This stuff is insanely hard to debug, and I must have a doozie of a bug in there. 2) My new programming job is taking up 9+ hours a day, and when I get home, the last thing I want to do is spend more time coding.

But all is not completely lost. I give you >> open box with golden light shining out << The Source!

Yes, it's now open source!! Woo hoo! I apologize profusely that I won't be able to put enough developement time in to finish it myself. However, more good news is that the node based portion of this code is pretty stable, which is cool.

Please spread the word to the community!!
- Bret

Hey, thanks a lot! I will give it a try immediatly...

Oh, where is pathfind.dll? I got no Visual C++ to compile...

Woah thanks clone! You're a pimp! And it even compiles perfectly with VC++.NET!

Hi Snake! Try the original link. I believe I simply updated the .zip file and the new version of the .dll should be what you want. In other words, pf_to_ent() should return 0 if there's no path:

www.gamebeep.com/freebies/ez_path_src.zip

Cheers!
- Bret

Hey, thanks a lot!

Hey I'm sorry to bump such an old topic but now that this is open source is there any way to remove the trial version text. I'm assuming that this is now free?

Wow thanks it is greatly appreciated Quick question sorry to go off topic what would you suggest I use to compile it with... Dont have no C+ development tools. Anything thats decent and free that ya know of that will get the job done. Thanks again.

I tried compiling it with Bloodshed Dev-C++ and got a ton of error messages. Can anyone compile this with the trial version text removed assuming clone45 has released this as freeware and we're allowed to remove it.

Sorry! Sorry!

I didn't mean to drop off the face of the earth! Consider this community property now! Feel free to strip out the trial version text! I'll try to get around to compiling a new version without the trial text and post it up for everyone. This should compile with Visual C++ .net.

Sorry that I have to keep it short for now. Time's been pretty limited since I got my job. I'll see what I can do about the trial text.

Cheers!
- Bret

Thanks very much Clone 45 that's greatly appreciated

Ok! I uploaded the most recent build of the .dll here:
Download Here
(http://www.gamebeep.com/freebies/ez_path_dll_only.zip)

This should be a good working version with the node based pathfinding and no trial version text! You'll still want to have the other .zip file handy for the documentation.

Cheers!
- Bret

Hello I replaced the old DLL with your new one but now when I start the demo it displays the error message crash_in_pf_smooth_turn.

Hey I´ve had the same error but if I copied it into another directoerie it workes!!??
No idea why.

TheGameMaker

Hello I've encountered another problem . After some testing it seams that the pathfinding routine ignores static models. This is bad because all my levels are made out of static models. Is there anyway to bypass this?

EDIT: Hello I did find a workaround by using blocks with their faces set to none but this is far from ideal.

Sorry,

You're correct. The EZ-Path initialization routines ignore models when linking together the nodes. I'm afraid that if your level is built out of static models, it's not going to work. I also apologize for not having the time to persue changes to the code at the moment. I'm simply too busy!!

Sorry again,
- Bret

Dont worry about it I'll just use my workaround.

Hey Bret,
Did they fire you from that job yet so you can get back to this plug-in?
Seriously, this is brilliant, I hope you or someone with some programming know-how continues to refine this plug-in (or work it into the IntenseAI being developed).

Has anybody figured out how to get the 6-25-05 release to not error out on pf_smooth_turn? I think the solution above (moving the plugin) was simply falling back to the old demo dll within the directory. Have function names changed in the new version or is there a bug in the latest compile?

Thanks for any help!!!!!

i tryed it and i got DLL errors all over the place when i start so i could not play it

Hello!

I've gotten a few questions about the pf_smooth error. I've been super busy, but I'm going to write myself a big huge note to get it fixed! I'm happy that people are still interested in the plug-in!

- Bret

If anybody's been getting the smooth_turn error, it's now fixed, just a little problem in the script file:

//comment this out
//pf_smooth_turn(my, VECTOR(my._PF_PAN_TO_TARGET,0,0), turn_speed);

//new version
pf_smooth_turn(my, turn_speed,VECTOR(my._PF_PAN_TO_TARGET,0,0));