Pathfinding

[Fedora]

I noticed that, expecially on big monitors, a click on the visible terrain don't lead to character movement unless it's very close to the character. I searched through the code but cant find a check about clicked coords (something like an allowed walking area/radius). Instead it seems that after a click the coords are sent to the server that calculates a path only if the click it's not far away (just figuring things, not sure).

 

On the other hand when we click on the 2d map the client calculates a path and follows it (in synch with the server).

 

Now, why dont we use the pathfinder for 3d map too? This way all visible tiles would be reachable. Needed changes are easy (use pf_find_path instead of move_to).

 

 

Second issue with pathfinder is that when you are walking and click on a door/npc/resource which is too far to be used, you stop walking. This is because in click_game_handler (gamewin.c, line 580) we call pf_destroy_path. Is there a reason or we can remove it and let the char keep walking? (or just stop it if the action is successful).

 

I can provide a patch if you find the above issues meaningful.

[Alia]

1. Standard perspective is about 0.15 in which case almost all visible tiles are clickable.

If you play with perpective 0.80 it is up to you, but game was not designed to work properly

with such options

 

But useing pf in this case could be added as on option (configurable).

 

2. If you click on the door while walking, doesn't it mean that you changed your mind and

decided to go to a different place? It would be annoying if I click on the door near me,

but char will continue going to a different location :/

[Entropy]

What Alia said

[Fedora]

ok. Patch submitted for issue 1. (option is under the controls tab)

[Entropy]

Ok, can someone test the patch? If it works, it should be merged.

[bluap]

Ok, can someone test the patch? If it works, it should be merged.

THis is working nicely so far. I'll commit it soon.

[Learner]

Ok, can someone test the patch? If it works, it should be merged.

THis is working nicely so far. I'll commit it soon.

Make sure you also test it on large maps that have unreachable areas as well. I'd hate for a bug to creep back in that used to disconnect/resync people with slow machines when tryinh=g click to unreachable areas on the Tab map.

[bluap]

Make sure you also test it on large maps that have unreachable areas as well. I'd hate for a bug to creep back in that used to disconnect/resync people with slow machines when tryinh=g click to unreachable areas on the Tab map.

OK, will do. Was there some particular conditions other than what you describe? This new patch is using the same pf_find_path() function used by the tab map clicks so if that works.... In case anyone else finds it too, Fedora and I have already discussed a minor issue with teleport to range.

Edited February 7, 2008 by bluap

[asgnny]

The patch seems to work fine for me. It's fantastic!

[bluap]

Make sure you also test it on large maps that have unreachable areas as well. I'd hate for a bug to creep back in that used to disconnect/resync people with slow machines when trying click to unreachable areas on the Tab map.

Learner, I've tested on the Whitestone map using the summoning area near Graham's Village. If I try to click-walk into the arena when pathfinding is enabled, I get a large spike in CPU loading for may be a second (I'm on a 2.4GHz pentium 4). This is exactly the same as if I try clicking on the tabmap or minimap to get in. Without pathfinding, there is no CPU spike for click-walking. If you are happy that I've exercised the bug condition, and the result is OK, I'll commit the patch.

[Fedora]

If cpu load is an issue, you can change the dist value in move_to to something higher than 2. This way only clicks dist tiles away will activate the pathfinder.

[bluap]

If cpu load is an issue, you can change the dist value in move_to to something higher than 2. This way only clicks dist tiles away will activate the pathfinder.

Distance is not the issue. It's when there is no path to the target. I don't think it is a problem, I'm just checking that I've tested as Learner suggested.

Edited February 10, 2008 by bluap

[bluap]

I've committed the patch with a few minor adjustments. Thanks fedora.

[bluap]

I've noticed a slight side effect of this patch when your are attacked while walking. While fighting, you constantly try to fee,without pressing home or clicking to move. Once the fight is over, you resume your original path without having to click anywhere. Now this is the same as what would always have happened if you map walked, but it does not seam correct for normal walking. I have a easy fix: check if you are fighting and following a path, and if so destroy the path. However, this will change the behaviour for map walking too. Is everyone happy with this? Also can anyone suggest a better place to do the check than in draw_scene()?

Index: draw_scene.c
===================================================================
RCS file: /cvsroot/elc/elc/draw_scene.c,v
retrieving revision 1.141
diff -a -u -r1.141 draw_scene.c
--- draw_scene.c		25 Feb 2008 22:50:38 -0000	  1.141
+++ draw_scene.c		27 Feb 2008 11:39:39 -0000
@@ -15,6 +15,7 @@
#include "multiplayer.h"
#include "new_actors.h"
#include "new_character.h"
+#include "pathfinder.h"
#include "shadows.h"
#include "skeletons.h"
#include "sound.h"
@@ -114,7 +115,14 @@

void draw_scene()
{
+	   actor *me = get_actor_ptr_from_id(yourself);
+
	CHECK_GL_ERRORS();
+
+	   /* if we're walking a path and start fighting, destroy the path */
+	   if (me!=NULL && me->async_fighting)
+			   if (pf_follow_path)
+					   pf_destroy_path();

#ifndef NEW_WEATHER
	if (dungeon || !use_fog) {

[Schmurk]

Personally, I think that it should stay like this but it's only my own opinion. I usually click on the minimap to flee when I'm fed up clicking like a mad or using home key so if this feature disappear I'll be quite disappointed.

 

Now, I've also experienced the same thing yesterday during the no more grief day and sometimes it's a bit annoying but sometimes it's also quite cool. In all cases, if it's too annoying, there's still the possibility to uncheck the option.

 

Anyway, there's maybe another way to do it. We can also increase the distance check in the move_to function in order to decide if we call the standard move function or the path finding one...

[Learner]

Personally, I think that it should stay like this but it's only my own opinion. I usually click on the minimap to flee when I'm fed up clicking like a mad or using home key so if this feature disappear I'll be quite disappointed.

 

Now, I've also experienced the same thing yesterday during the no more grief day and sometimes it's a bit annoying but sometimes it's also quite cool. In all cases, if it's too annoying, there's still the possibility to uncheck the option.

 

Anyway, there's maybe another way to do it. We can also increase the distance check in the move_to function in order to decide if we call the standard move function or the path finding one...

Continuing to flee is a bug that could get you killed by not attacking enough, most likely to happen if something attacks you that isn't an easy wind.

[Fedora]

mmm...good for training, bad for pking. I guess enlarging the radius in the distance check is the best solution, so we can retain the old mapwalking behaviour and still have the benefits of the patch.

[Schmurk]

Continuing to flee is a bug that could get you killed by not attacking enough, most likely to happen if something attacks you that isn't an easy wind.

Yes of course and it can be very annoying in some cases like you said. So maybe we can add a new option that kills path finding when attacked. So then it's up to the player to decide how the path finding stuff should behave.

[LabRat]

Dunno if it would work, it just seemed the most obvious simple way to me.

 

How about:

Index: actor_scripts.c
===================================================================
RCS file: /cvsroot/elc/elc/actor_scripts.c,v
retrieving revision 1.249
diff -u -r1.249 actor_scripts.c
--- actor_scripts.c	25 Feb 2008 22:50:38 -0000	1.249
+++ actor_scripts.c	27 Feb 2008 14:48:31 -0000
@@ -1455,7 +1455,8 @@
	//int i=0;
	int k=0;
	//int have_actor=0;
-//if ((actor_id==yourself)&&(command==enter_combat)) LOG_TO_CONSOLE(c_green2,"FIGHT!");
+	if ((actor_id==yourself)&&(command==enter_combat))
+	   pf_destroy_path();
	actor * act;
#ifdef EXTRA_DEBUG
	ERR();

[bluap]

Continuing to flee is a bug that could get you killed by not attacking enough, most likely to happen if something attacks you that isn't an easy wind.

Yes of course and it can be very annoying in some cases like you said. So maybe we can add a new option that kills path finding when attacked. So then it's up to the player to decide how the path finding stuff should behave.

That's why I still think destroying the path if we're fighting is the right way, extending the non-pathfinder walk range is only a partial solution. So making the path destroy optional is a good middle ground if we have to. That control config tab is getting a bit crowded though.....

[bluap]

Dunno if it would work, it just seemed the most obvious simple way to me.

That looks a better place than my version. But I'd still check pf_follow_path before calling the destroy function.

[LabRat]

Yeah, I know there is a little more than that involved, such as checking if I exist etc but it was a quick proof of concept hack.

[Fedora]

has this been commited? if so doesnt seem to work in latest cvs...

[LabRat]

I can't see anything similar in the berlios CVS history of actor_scripts.c since this thread was live, so unless someone came up with a spiffy way in another file on there I guess it never got merged.

[bluap]

has this been commited? if so doesnt seem to work in latest cvs...

The pf_destroy_path() when fighting? No I haven't done it because there was no consensus. I still think we need to add it though. I guess we need a final say from Entropy or Learner....