Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Lua ➜ Mapping - Pathing

Mapping - Pathing

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1  2  3 4  5  

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #30 on Thu 31 Aug 2006 07:23 PM (UTC)
Message
If the hashing algorithm is good, then your chances of getting duplicates are fairly small. Of course, it depends on how big your hash key is; a four-character hash will have lots of duplicates, but a 128-character hexadecimal hash will have a whole lot fewer duplicates.

The real problem here is that neither hashes nor indices can solve the fundamental problem, which is uniquely identifying and distinguishing rooms. If you enter a room, you need to find some way to tell which room it is; Nick's hash method would give you a pretty good idea, in almost all cases. The index issue is slightly separate; the index is not used to determine which room you're in, and is rather an internal unique representation of the room. You still need a mapping from room name/description/etc. to an index number, and that is the million dollar question.

You could probably use some heuristics to make fairly educated guesses. For instance if you come across a room that hashes to the same as one you've seen before, but it is highly unlikely that it is the same (because it is, say, 20 steps east from the first) the mapper could either assume that it's a different room or tell the player that it's confused and ask what it should it.

This issue is very, very complicated... Frankly, it would be so much nicer if players could just see the MUD's internal method of distinguishing rooms. :-) Either that, or give the players more ways to tell if two rooms are different. Of course, sometimes you might *want* the players to feel lost, if for instance you are in a big desert. (That is one reason why we use the random descriptions: making things look somewhat similar, to give a feeling of being in a very large, mostly non-descript segment of terrain.)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #31 on Thu 31 Aug 2006 09:27 PM (UTC)

Amended on Thu 31 Aug 2006 09:29 PM (UTC) by Nick Gammon

Message
These are all issues I have been thinking about, and I admit that the solution is not totally simple.

First, the hashing idea. Certainly you could store the room descriptions, but I think that the hash is shorter, especially if you also have to store the name, the exits, and maybe nearby descriptions.

The whole idea of a well-designed hash is that it is very, very unlikely that you can get duplicates. A major reason for this is that hashes are used to "sign" documents digitially.

Say, for example, Shadowfyr gave me a digitally signed document in which he promised to pay me $100, and I could change that to read $100,000 and then make minor changes (like adding spaces, or slightly rewording it) and keep re-hashing it until I got the same hash, then the signature would not be very useful.

In fact, the MD5 hash is a 128-bit hash, and therefore has 2^128 possible combinations (340,282,366,920,938,463,463,374,607,431,768,211,456 combinations), so you can see that for a few thousand rooms, a collision is not that likely.

If you were worried, you could do a 256-bit hash (SHA256 which is provided in the MUSHclient Lua libraries) which gives you 2^256 combinations (115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 possibilities)

Even the 256-bit hash only requires storing 32 bytes (maybe 64 if you stored them in "hex" format).

The problem with duplicate descriptions is hard to solve as far as I can see. I agree that maybe hashing (or storing) the exits is not a great idea, and in any case something like "a path around darkhaven" could easily fail both our tests. My test of the exits might not help (the path might have various entries that are east and west) and Ksilyan's idea of proximity might also fail, as the paths are likely to be adjacent.

The only (fairly) certain test I can think of is to look into nearby rooms, using Ked's algorithm, and stop after getting one or 2 rooms away (and then going back, if we are able).

Here is an example of what I am talking about. Say there is a long north-south road in Darkhaven, where every room is called "Vertic Avenue".

Now as we enter each room we take all possible exits, and add their descriptions to our hash (or append them to the master description).

Now we have something like this:


Vertic Avenue -> east -> butcher -> west -> baker


This gives us a different hash from:


Vertic Avenue -> east (no room) -> west -> (no room)


or:


Vertic Avenue -> east -> arms supplier -> west -> cooking trainer


However the case of:


Vertic Avenue -> east (no room) -> west -> (no room)


might have multiple occurrences, which is why you probably have to try further afield. Using the terminololy from the algorithm above, you might need to generate 10 or so "particles" to guarantee uniqueness.

I can forsee other difficulties, though. For one thing, one-way exits might make it hard to go back to the room under investigation.

Maybe there is a more elegant solution?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #32 on Sat 02 Sep 2006 12:50 AM (UTC)
Message
Well Ksilyan, to be honest, the biggest issue with, "if the program could see the way the mud sees a room", is that some "don't" have such a thing. The closest where I play would be something like:

./Simon/My_City/GenericRoom_1.c

The problem being, there might be several of those rooms, and they might be 100% identical, right down the the individual exits. There is no internal ID number, quite possibly identical exits and no way to even produce a useful hash as a result. A hash is imho, completely worthless, except as a quick check to see if there might be a similar room, and warning the player if something seems odd. For the purposes of pathing, its totally poinless, since you are only interested in the room you are in, the room you are going to, and what it takes to get there. A hash is unlikely to be useful in seeing if an exit is locked, blocked, etc, without making the hash more complicated. It is probably just as easy and more accurate to check the original data for that room, than rely on a hash to figure that out. This means, you are adding a X-bit hash, that is useless for "anything" other than making it "maybe" marginally faster to check an apparently new room against those already known, and thus warn that player of a possible problem. The only advantage I can see is that keeping the hash table in memory is probably "cheaper" memory wise and in terms of speed that doing a series of retrievals from a database.

This is likely a rare enough case that you could let the player do it themselves when "they" realize there is a problem, and only adjust the data "after" they do something like- Click to select first room, click to select second room, click a "Merge" button. And its probably less complicated to let the user fix the problem, than have the mapper constantly whining at them, in something like overland maps especially, that the mapper "thinks" a problem exists. I tend to suspect that the problems possible when trying to use hashes and help the player too much may outway the benefits, but that's just a guess.

Oh, and one ***really*** big problem I see, is that its not totally impossible for someone to create a mud, at least with a real driver, instead of one of these "modern" ones, where the rooms "location" stays the same, but there is no certainty that the name, description and/or exists will *always* be the same.
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #33 on Sat 02 Sep 2006 02:02 AM (UTC)
Message
I think that what this comes down to is that there simply is no general, perfect solution. The huge variety of more or less different setups precludes that. So, I think the problem worth solving here is targeting a specific sub-class of mapping problems and tackling that. Not to be pessimistic but I think it is basically hopeless to try to make a completely general mapping program that will work across all games. Even if it's possible, it would probably be much less effort anyhow to sub-divide the games into categories and tackle them one at a time.

To be honest, I would find it very useful to have a tool in which I create rooms myself, and I take care of linking them; and from that point all the mapper does is move me from room to room along with my movements. For example if I have mapped rooms A and B, and B lies west of A, and I'm in A and go west, it will know to put me in B. Simple as that. This would be a very big help already. From there it should be pretty simple to automatically detect which exits are present in a room, and ask the user to manually link them to their destinations.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #34 on Sat 02 Sep 2006 04:03 AM (UTC)
Message
Quote:

A hash is imho, completely worthless, except as a quick check to see if there might be a similar room, and warning the player if something seems odd.


Let's assume for the sake of argument that the hashes will not collide if the data being fed into them is different. From the figures I gave earlier, where there are trillions of trillions (is that gazillions?) of possible hashes I think we are fairly safe there.

The real issue is the data (hashed or not). If we are collecting things like room name/description/exits we can either hash them or simply concat them together and store the resulting string. I only mentioned the hash as it could be a reasonable "key" for indexing into the room data. You could also do what you suggested and simply generate a numeric key (1, 2, 3 ...) and assign a new one when you think you have a new room.

If you know in advance that the room descriptions will be unique then your problem is largely solved, of course. However if not, then it may be very hard to solve. An automated "mapping bot" could easily get confused in this situation:


---> Winding Passage ---> Winding Passage --|
                              |             |
                              ^             v
                              |             |
                              ----<----------


The bot keeps going east, thinking it is finding new rooms, but actually keeps revisiting the last one without realising it.

In fact, even checking nearby rooms won't help because it will find a "Winding Passage" to the east and to the west of it.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Ked   Russia  (524 posts)  Bio
Date Reply #35 on Sat 02 Sep 2006 04:04 AM (UTC)

Amended on Sat 02 Sep 2006 04:09 AM (UTC) by Ked

Message
Here's what I finally came up with. The actual code is in the next post.

This uses room name and exits (without the description) for the room signature. The Locator object has move(), look(), undo_move(), and room_display() methods, which are called when making a move, entering a command that will result in a room description but doesn't move you anywhere, receiving a failed move message from the MUD, and receiving a room description, respectively.

Upon initialization, the Locator object searches the map for all rooms with the given signature, for each match it creates a Tracker object, that supports the same methods listed above.

Tracker objects try to match the player's moves to the contents of the map. They do this by storing each move in an internal queue. A move is removed from this queue when either undo_move() or room_display() methods are called. The Trackers' room_display() method returns either true or nil. The former is returned in one of 3 cases:

1) A move direction queued by the Tracker doesn't exist in the current room.
2) A queued move is a "look" command.
3) There was a match between signatures for the expected room and the room being actually displayed. In this case the expected room is set as the Tracker's current room.

In all other cases, the main one of these being absence of a match between signatures, it returns nil.

Locator, when its' room_display() method is called, iterates through its Trackers, calling their corresponding methods. All Trackers that return nil are removed from the Locator's list of trackers. The Locator re-initializes itself when it runs out of trackers.

The Locator can return the current location with its getCurrentRoom() method. It will do so only if there is exactly one tracker left in the list, in any other case it should return nil to signal that the current position is unknown.

So far I can see one advantage of this system and two large shortcomings.

The advantage is that the system is fairly simple and will work on both the MUDs that display unique room IDs and those that don't.

The first shortcoming is that it is very sensitive to the order of commands sent and received. Right now, failing to notify it of a single failed move will break it immediately. This is a big deal because keeping track of failed move messages is not always an easy task. For example, being prone could prevent you from moving in a direction, but also from doing any other numbers of things, and filtering out those prone messages that prevented movement from those that prevented picking your nose is difficult.

The second shortcoming is that the system requires the map to be complete, exits and rooms missing on the map will cause constant failures to pin down the current position. Not sure how this can be helped at this point.

And of course, it requires plenty of refactoring. For instance, I am unhappy with the way exits are represented on the map - they don't allow for hidden exits, coupling what is show in room descriptions with what is really there. I think that a separate Link object would be a better idea.



Top

Posted by Ked   Russia  (524 posts)  Bio
Date Reply #36 on Sat 02 Sep 2006 04:07 AM (UTC)
Message



dofile "room_stuff.lua"  -- room definitions

function sortExitsTable(exit_tab)
  local labels = {}
  for label,_ in pairs(exit_tab) do
    table.insert(labels, label)
  end
  
  table.sort(labels)
  return labels

end

function sortExitsList(exit_list)
  local exit_list = exit_list
  table.sort(exit_list)
  return exit_list
end



-- a map object that implements all methods for
-- getting rooms, etc.
map = {}

map.rooms = rooms

map.getRoomSignature = function (vnum)
  local room = map.rooms[vnum]
  if not room then
    return nil
  end
  
  local sig = room.name
  sig = sig .. " Exits: " .. table.concat(sortExitsTable(room.exits), ",")
  return sig
end


map.makeRoomSignature = function(room_name, room_exits)
  local sig = room_name
  sig = sig .. " Exits: " .. table.concat(sortExitsList(room_exits), ",")
  return sig
end

map.getRooms = function(room_name, room_exits)
  local sig = map.makeRoomSignature(room_name, room_exits)
  local rooms = {}
  for vnum,room in pairs(map.rooms) do
    if map.getRoomSignature(vnum) == sig then
      table.insert(rooms, vnum)
    end
  end
  
  return rooms
end

map.getRoom = function(vnum)
  return map.rooms[vnum]
end

-- An object implementing all movement-related methods
function Tracker(init_room_id)
  local t = {}

  -- An attribute holding the current room's presumed ID
  t.current_room = init_room_id

 
  -- Holds a history of moves
  t.moves = {}
  
  -- This is called on each move
  t.move = function(dir)

    local room = map.getRoom(t.current_room)
    -- add target room and move to history
    table.insert(t.moves, dir)
      
  end
  
  -- This is called when doing a LOOK command, or any other command
  -- that results in a room display without actual movement
  t.look = function()
    table.insert(t.moves, "look")
  end
  
  t.room_display = function(room_name, room_exits)
    local exit_taken = table.remove(t.moves, 1)
    
    local room = map.getRoom(t.current_room)
    local targ_rsig = map.getRoomSignature(room.exits[exit_taken])
    local this_rsig = map.makeRoomSignature(room_name, room_exits)
    
    if not room.exits[exit_taken] then
      return true
    elseif exit_taken == "look" then
      return true
    elseif targ_rsig == this_rsig then
      t.current_room = room.exits[exit_taken]
      return true
    else
      return nil
    end
  end
  
  -- Call this when a failed move is encountered
  t.undo_move = function()
    table.remove(t.moves,1)
  end
  
  
  return t
end 


-- Call to start searching for the current location when lost
function findCurrentLocation(room_name, room_exits)
  
  -- search the map for any rooms with the given signature
  local rooms = map.getRooms(room_name, room_exits)
  
  -- create a separate Walker for each room returned by the map
  local trackers = {}
  for _, vnum in ipairs(rooms) do
  	table.insert(trackers, Tracker(vnum))
  end
  
  -- return the list of generated Walker objects
  return trackers

end



function Locator()
  local t = {}
  
  t.trackers = {}
  
  
  t.init = function(room_name, room_exits)
    t.trackers = findCurrentLocation(room_name, room_exits)
  end

  t.move = function(dir)
    if table.getn(t.trackers) == 0 then
      return nil
    end
    
    for _, tracker in ipairs(t.trackers) do
      tracker.move(dir)
    end
    return true
  end


  t.room_display = function(room_name, room_exits)
    if table.getn(t.trackers) == 0 then
      t.init(room_name, room_exits)
    end

    local new_trackers = {}
    for _, tracker in ipairs(t.trackers) do
      if tracker.room_display(room_name, room_exits) then
        table.insert(new_trackers, tracker)
      end      
    end
    
    t.trackers = new_trackers
    
    
    if table.getn(t.trackers) == 0 then
      t.init(room_name, room_exits)
    end
  
  end
        
  
  t.undo_move = function()
    for _,tracker in ipairs(t.trackers) do
      tracker.undo_move()
    end
  end
  
  t.look = function()
    for _, tracker in ipairs(t.trackers) do
      tracker.look()
    end
  end
  
  
  t.getCurrentRoom = function()
    
    if table.getn(t.trackers) == 1 then
      return t.trackers[1].current_room
    else
      return nil
    end
  
  end
  
  
  return t

end


loc = Locator()
Top

Posted by Ked   Russia  (524 posts)  Bio
Date Reply #37 on Sat 02 Sep 2006 04:08 AM (UTC)
Message
And a few simple tests using Nick's map:


function checkPosition(pos)
  if loc.getCurrentRoom() == pos then
    print ("Position correct: " .. tostring(pos))
  else
    print ("Test was failed! Position: " .. tostring(loc.getCurrentRoom()) )
  end
end


-- Do a short walk to ensure that it works at all
--
-- start at 21013
loc.init("Hawk Street", {"s", "n"})

-- move 'n' to 21012
loc.move('n')
loc.room_display("Intersection of Horizon Road and Hawk Street", {'s','e','w','n'})

-- move 's' back to 21013
loc.move('s')
loc.room_display("Hawk Street", {"s", "n"})

checkPosition(21013)


-- Simulate three moves in correct directions with one failure
--
-- start at 21013
loc.init("Hawk Street", {"s", "n"})

-- move 'n' to 21012
loc.move('n')

-- move 'n' to 21011
loc.move('n')

-- move 'n', presumably to 21010
loc.move('n')

-- arrive message received for 21012
loc.room_display("Intersection of Horizon Road and Hawk Street", {'s','e','w','n'})

-- a move failed, so one room display is missing
loc.undo_move()

-- arrive message received for 21011
loc.room_display("Hawk Street", {'s','n'} )

-- current position should be 21011
checkPosition(21011)


-- Three moves, one in a non-existant direction
--
-- start at 21013
loc.init("Hawk Street", {"s", "n"})

-- move 'n' to 21012
loc.move('n')

-- move 'ne' - direction doesn't exist
loc.move('ne')

-- move 'n' to 21011
loc.move('n')

-- arrive message received for 21012
loc.room_display("Intersection of Horizon Road and Hawk Street", {'s','e','w','n'})

-- move failed
loc.undo_move()

-- arrive message for 21011
loc.room_display("Hawk Street", {'s','n'} )

-- current position should be 21011
checkPosition(21011)
Top

Posted by Onoitsu2   USA  (248 posts)  Bio
Date Reply #38 on Sat 02 Sep 2006 02:08 PM (UTC)

Amended on Sat 02 Sep 2006 02:09 PM (UTC) by Onoitsu2

Message
Ksilyan has got somewhat of the right idea, as zMud's mapper (one built into zmud, not zMapper) uses MS Access databases, so that it will always have a unique key for each room, and that key is created automatically by the DB engine, it is not made from anything, no hash, no concat, just automatic. I remember using the mapper in version 6.something and it had an option of keypad creation (allows manual creation of room layout via the keypad, and sets a flag on said room to say "I am new, capture whatever Room Name, Descriptions, and Exits you see while 'inside' me", then from there you could right click the room in the mapper, and in the game send 'look' and then it would go to work, and unset the afore mentioned flag, so that next entry into the room (whether successful or otherwise will NOT change the info stored for it)

I suggest looking for a zMud map file, and opening it in MS Access, ones from version 6.5- will guarenteed open in MS Access 2000(XP), and that should give a general layout I am describing. Also the mapper would, when you would move in the game (send any direction) would create a virtual room in the previous method, send whatever direction was used, and then retrieve whatever info the mud sent back (meaning the automatic room entry info, can be Name and Exits, may be Name Descrip and Exits, may just be Name). Then from whatever info retrieved, whether all or some it would populate the appropriate info for that room, and toggle the previously mentioned flag. A Portal exit/entrance to a room, can be manually created, there is no real point in trying to match this automatically, it will only mess up the map layout, as you have no set direction where the room the portal exits into's direction is, so a special exit room can be created MANUALLY, say "north east" of the starting room, and the portal link was designated as a red dot in the bottom right (or left, I don't remember 100%) and then once the room is set, you can set the portal entry command, for the starting room, and then the portal exit command to go back (if any, or even if diferent) for the 2nd room. From there in order to monitor for said command it creates a temporary trigger ,matching on the command box imput, so in essence it is an alias '^(.*?)$' and keep evaluating is enabled, and within it it checks if the command entered is EQ to the command already set to enter the portal, if so it moves you to the 'linked' room previously created, otherwise it does pretty much nothing.

The exits, rooms are not created based upon the output of the exits information, only 'link directions' (the room you are in could be surrounded by exits, before even getting the room information for them) and from knowing there is an 'link' existant already the mapper can create a room in that direction if it is sent, and start the whole matching process over again.

I think we already have more than enough combined intellect on these forums, from how quickly entire scripts are posted, and the complexities of some of them. The mapper is basically a bunch of triggers, and the numbering system needing to be used in the mapper is needed to be complete uniqueness, same as used by the Access DB Engine for unique key entries, think of a company's order invoice technique, sure there may be an invoice number, but you do not use that as the unique key, you use a 32-bit short 'positive only' number, and have an invoice number field, and 'link' the tables 'Order Summary' and 'Customer' based on that 'Order Id' field and the 'Customer Id' one as well.

It is all in the layout of the data, you keep trying to create the unique number based on actual information, and concat'ing it or hashing it, but that is the wrong approach to allow such ease of creation of new rooms.

Just my 2 Cents, I may be completely and utterly wrong on this idea, but in my beliefs and experience using the mapper in zMud, this would be the optimal way of thinking, and enacting such a task.

Laterzzz,
Onoitsu2
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #39 on Sun 03 Sep 2006 01:24 AM (UTC)
Message
Yeah, that was basically what I thought. Why reinvent the wheel, when most databases you are likely to employ already have unique keys? You could make the code smart enough to notice obvious oddities, or let the user handle manually merging the rooms (or more likely both).
Top

Posted by Ked   Russia  (524 posts)  Bio
Date Reply #40 on Sun 03 Sep 2006 03:26 AM (UTC)
Message
Well, a database is implied, since how else are you going to store and retrieve room and link data? Serializing to disc could work for a while, but reading large maps into memory and searching them by iteration is a bad idea.

A database backend also opens up a score of various possible uses for a map. For example, you could allow users to define their own "objects", creating for each object a table according to the defined schema with a foreign key into the rooms table, thus attaching objects to rooms. Users could then search the map for all rooms containing a certain type of object, a certain type of object with a certain set of properties matching specified values, etc.

These objects could be anything, mobs are one example. Another example involves the Concoctions skillset in Achaea that lets you harvest herbs, with different kinds of herbs growing in different kinds of areas. Different herbs could be defined as object types and then placed in rooms that actually contain them, allowing the user to get a list of rooms (or areas, if the mapper allows them in a sense of collections of rooms) that contain a certain herb. Or all rooms with herbs in them, which would give all natural locations in the world. Or, if the mapper allows for "object type inheritance" all herbs growing in forests could be created as members of the "forest herb" type, which in turn would be of type "herb", so searching for rooms with forest herbs would give all forest locations :)

Then of course, rooms can have shops, which have wares, which have prices... And so on. So a db is a must.


Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #41 on Sun 03 Sep 2006 04:09 AM (UTC)
Message
Quote:

... uses MS Access databases, so that it will always have a unique key for each room, and that key is created automatically by the DB engine, it is not made from anything, no hash, no concat, just automatic ...


There is no big problem finding a unique key. Access just adds 1 to the previous highest key when you create a new record. I can achieve that by starting at 1 and adding 1 each time.

The problem is, tying this unique key to rooms in such a way that we are sure the same key is used once, and once only.

For example, if I wander around a city and find "a butcher shop", and store that in my database/table/variable/whatever with key number 5.

Then I wander around for another half an hour, taking many twists and turns. Eventually I find "a butcher shop". Now is that the same butcher shop, and therefore key number 5, which I already have in my database, or another butcher shop at the other end of town, in which case I have to make a new key for it?

Maybe both shops have the same description - the room designer might have copied and pasted. They might both have an east exit. They both might sell the same stuff.

Deciding if they are the actual same room, or two different rooms, is the non-trivial problem we are trying to solve here.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Ked   Russia  (524 posts)  Bio
Date Reply #42 on Sun 03 Sep 2006 06:01 AM (UTC)
Message
Quote:
Maybe both shops have the same description - the room designer might have copied and pasted. They might both have an east exit. They both might sell the same stuff.


I think it will be safe to presume that while an individual room may have exact duplicates, duplicate collections of linked rooms are going to be much rarer. And their rarity will increase together with the size of collections.

So if you have added 20 rooms that you believe are new, you can tell which of them are and which aren't by searching for those 20 rooms and links between them on the existing map. Then you can decide whether to merge any or all of those rooms with the existing map based on the results of that search.

Then there's also the question of where to add those new rooms exactly, but that's a different issue.
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #43 on Mon 04 Sep 2006 12:41 AM (UTC)
Message
And of course, if all you do is inform the user that such a duplication may exist, and let them specify the merge, you have a lot less of the problem. We are trying to make a tool here, not something that can play the game for someone.
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #44 on Tue 12 Sep 2006 07:41 AM (UTC)
Message
To tie this thread to an earlier one, see this:

http://www.gammon.com.au/forum/?id=3970

That thread actually solves (partly at least) knowing where you are, so making something that combines that with the pathing algorithm, should give a pretty good result.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


177,907 views.

This is page 3, subject is 5 pages long:  [Previous page]  1  2  3 4  5  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.