TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

Shortest path isn't quite shortest (2.00.8 [newest beta?])

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports
View previous topic :: View next topic  
Author Message
Elvang



Joined: 27 Mar 2012
Posts: 16

PostPosted: Fri Mar 30, 2012 9:40 pm    Post subject: Shortest path isn't quite shortest (2.00.8 [newest beta?]) Reply with quote

Using the version linked here, occasionally the selected path does strange things like this.

#PATH: s s nw s s s s s sw nw sw sw sw sw sw nw nw nw w w w w nw nw nw n w s


The weight for those rooms where the behavior occurs in this example is at 3.000.

This is a zip containing the map file where this occurs. The above example has the current room as vnum 248082, and '#map find {} {} water%*'.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Fri Mar 30, 2012 10:40 pm    Post subject: Reply with quote

Weird, I'll look into it.
Back to top
View user's profile Send private message Send e-mail
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Mon Apr 02, 2012 4:17 pm    Post subject: Reply with quote

I looked at it for two hours but can't quite figure it out.

The problem is somewhere in the shortest_path() searchgrid_find() and searchgrid_walk() functions, and seems related to weighted rooms.
Back to top
View user's profile Send private message Send e-mail
Elvang



Joined: 27 Mar 2012
Posts: 16

PostPosted: Mon Apr 02, 2012 6:55 pm    Post subject: Reply with quote

I've experienced similar behaviors in long paths where it goes 's;e;s;e;s;e;...' rather than just taking the se exit (effectively doubling the room moves/weight for that portion), if that helps at all. The errant portions of the path are always the same weight (that I've noticed), though it doesn't seem to happen at any specific weight, or even reliably within the same weighted area.

Possibly related, I've noticed a somewhat similar behavior when mapping new rooms. My mapper is based on your Aardwolf GMCP automapper script, but assigns a room weight to the unexplored rooms that is the same as the creating room, along with "0xUNEXPLORED" in the desc. Often, using '#map find {} {} {0xUNEXPLORED}' will cause the path to first go to an adjacent, lower weight room that is also touching the target, rather than moving directly to the target from the current room.

An example, with the numbers being the room weight, x denoting unexplored. All rooms have exits n, e, w, s, nw, nw, se, sw.

Code:
[ 6x] [ 6x] [ 6x] [ 6 ]
[ 6 ] [ 1 ] [ 6 ] [ 6 ]
[ 6 ] [ 1 ] [ 6 ] [ 6 ]


Performing the search for "0xUNEXPLORED" from the middle left room will produce a path of "e nw" rather than the expected "n".
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Tue Apr 03, 2012 8:15 pm    Post subject: Reply with quote

I think I got it fixed, hopefully without breaking something else in the process. Updated the beta.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group