Experimental Code: Stop mobs hopping when pathing - FindBestZ tweaks

[Cripp]

did a little more testing.. and i guess my little fix can only disable fixZ for the whole zone because...

float newz = zone->map->FindBestZ(n, dest, NULL, NULL);

...it loads the bestZ for the whole zone not just the mob i guess..


gonna try it with FixZWhenLoading disables and on SendTo/onWayPoints enabled..

might have to add a few more checks in waypoints.cpp too.. ill keep posted.

[Cripp]

ahh found way to make it work..

waypoints.cpp..

--- waypoints.cpp	2007/12/01 18:11:14	1.7
+++ waypoints.cpp	2007/12/19 18:08:40	1.8
@@ -670,7 +670,9 @@
 					newwp.x = atof(row[0]);
 					newwp.y = atof(row[1]);
 					newwp.z = atof(row[2]);

 					if(zone->map != NULL && RuleB(Map, FixPathingZWhenLoading) ) {
 						// Experimental. This code will send any waypoint that is 'in the air' down to ground level.
 	
@@ -685,14 +687,17 @@
 							float newz = zone->map->FindBestZ(n, dest, NULL, NULL);
 							// The following test is a sanity check. 45 is an arbitrary value, chosen during testing
 							// because all the Z co-ordinates of the waypoints in The Grey where <45 units above the ground.
 							if( (newz > -2000) && ABS(newz-dest.z) < RuleR(Map, FixPathingZMaxDeltaLoading)) {
#ifdef CRIPP_Z
 								if (fixz != 0) {
#endif
 								newwp.z = newz+1;
 								// printf("Updated Z for Grid %d, Waypoint %d from %.3f to %.3f\n",  grid, newwp.index,dest.z,newwp.z);
#ifdef CRIPP_Z
 								}
#endif
 							}
 							//else if(newz > -2000) 
 							//	printf("Delta Z %.3f too big for Grid %d, Waypoint %d from %.3f to %.3f\n", ABS(newz-dest.z), grid, newwp.index,dest.z,newz);
 						}
 					}
 
 					newwp.pause = atoi(row[3]);
 					Waypoints.push_back(newwp);

instead of old..



edit: untested as of now... going to test now will edit with results.

edit2: just tested with similar results... gona mess around till i get something working then ill post =D

edit3: kinda stumped :( edited all posts to what im working with currently(changed all boolean to sint, etc.)..

im a noob haxor, someone help me out :P

[narcberry]

This is great work and all but I think it is distracting from what should really be developed, a pathing function. Fixing the z is just a temporary fix. We need proper pathing. When we do we will throw away all these fixes. And throwing away all of those man-hours makes for a lot of these: <insert tear emoticon here (no tear emoticon is maybe even sadder /tear)>

I am working on a couple pathing algorithms and am wondering if anyone has done some work on this already?

I'm using 2 strategies to reduce the complexity of the pathing algorithm:
(1) weighing node paths based on location between point a and b. (2) reducing the data set by pathing between the larger map subspaces then fine tuning the path.

The 3d rendering on page1 shows the triangles in the map to be grouped into larger square regions. You can build paths based on these larger square regions first by drawing a line between persuer and persuant than dropping it onto the map. Then building a path inside each square from entry to exit point.

This is really succesful for maps that dont require much pathing such as the karanas. But it has troubles in dungeons, where pathing is actually needed. I'm still looking at possible ways to break maps up into smaller 3d spaces that make sense as a graph. This will have to be done when a zone loads, since it is sucks the life force from any cpu. The first time a zone loads this 3d map could be generated and saved for future use.

My problem is this next step is like... a lot of work. I'm wondering if it wouldn't be better to just build path maps by hand.

Or be lazy and have zones listen to player movements and mutate pathing maps from those coordinates.



Either way, this is problem #1 in the emulator and should get more attention.