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
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2
3
4
5
Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
Date
| Reply #60 on Mon 01 Jan 2007 01:30 AM (UTC) |
Message
| Of course. My point is that an optimization that didn't "know" that the underground existed at all initially might look for the path to the area boundary instead, this being flawed, since once the underground is known, its no longer the most reasonable path. | Top |
|
Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
Date
| Reply #61 on Tue 02 Jan 2007 06:49 AM (UTC) |
Message
| Exactly. An exhaustive search is probably the safest, and with a limiter, should not consume your CPU for 10 minutes. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
Date
| Reply #62 on Tue 02 Jan 2007 07:28 PM (UTC) |
Message
| Mind you. Its probably a good idea to make it so that if "no" path is found with those limits, that it looks for one with a bigger limit, so you start with 30, then if not found, try 40, etc. Or, maybe even let the player specify, something like, "find orc shaman : far". Where that designates that it should use a bigger limit, or just ignore them. Its not impossible for some mud to have a path from the farthest corners to each other be 30+ rooms. Of course, if using this with a GUI, you could simply have a set of buttons to define if you want "near", "close", "distant", "far" or "unknown", as a search limit. And if previous successful searches where stored, so going from the bank to Zorg's Merchantile was already found, the "current" distance would be stored for those start/end locations, so that a new search only looks for something "shorter than or equal to" that.
In other words:
Near - 10
Close - 20
Distant - 30
Far - 40
Unknown - infinite
So, if the path from the Bank to Zorg's is "known" to have been 19 last time, it won't look for any path longer than "Close" the next time. The only issue is how many prior searches it stores, so you might want an option of "save this search", or even just throw out ones that haven't been used more than once after 10 active days. That way you don't have to look through 50,000 * 50,000 prior searches (in the worst case, like some moron going to every room, one at a time, and searching every other room in the game world...), just the "often used" and most recent ones. | Top |
|
Posted by
| Nobody
(38 posts) Bio
|
Date
| Reply #63 on Sun 07 Jan 2007 06:32 AM (UTC) |
Message
| Who wants to help me plan out some data structures for a mapping system that does everything above, but also has the ability to learn new rooms and add them (with appropriate linkage to other rooms) ?
It doesn't really matter much about which language is used - perl hashes are pretty much the same as lua tables in this case. The trouble I'm having is searching for a room by title. I was hoping to have a way to search for something quickly (I was thinking of somehow using a room title as a key, but that falls apart when multiple rooms with the same title occur) so I guess I'll have to do the old brute search method.
What I'm aiming for here is a mapper that can monitor your position and keep itself updated about which room you're in, and one that adds the room if it's not found. I'm not too concerned right now with things such as detecting rooms and making it all 'portable' for all muds. Right now I'm just focusing on the data structures for storing the data. Who has some ideas?
I'll be storing the following data: Room title, description, vnum (not given by the mud, generated by me), exits. Room title and description will be strings, vnum obviously will be int, and exits will be a hash (or table) of direction->vnum.
So far I have a hash with the vnum as key, and the text data as a sub-hash (with the exits data as a sub-sub-hash). Can anyone think of a better way ? | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #64 on Sun 07 Jan 2007 08:19 AM (UTC) |
Message
| Well, there is a data structure called the multimap, which can store several values with the same key. That way you could keep very quick lookup, and when you have conflicts, you would resolve them however you would normally resolve them. (You have to resolve them somehow anyhow.)
One main difference with this data structure is that you wouldn't specify just a key to remove, but a key-value pair so that it leaves other values that might share the same key.
An easy but not optimal way of implementing this is to have every key point to a list of values for that key. (This is not optimal because most of the time the list overhead is useless. It might be better to only have a list if you actually need one, but that adds extra complexity.) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Onoitsu2
USA (248 posts) Bio
|
Date
| Reply #65 on Wed 11 Apr 2007 11:09 AM (UTC) |
Message
| Since this WAS a very hot discussion, and is still more likely than not an idea in a lot of user's heads, I have tried to track down some things on it, and have located an Open Source Client, that HAS a MAPPER, so that such code can be examined, and perhaps a mapper can be built by the "Programming Community" since the release of mushclient's source.
http://www.mudmagic.com/mud-client/source_download.php
That is the URL to DL the source in a variety of archive types. The Windows Zip is 3769KB (roughly 3, nearly 4 MB)
I am unsure as to the Language used, as I have not DL'd the source as I am having connection difficulties (Dialup only wanting to connect at 26.6 for some odd reason)
Laterzzz,
Onoitsu2 | 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.
175,358 views.
This is page 5, subject is 5 pages long:
1
2
3
4
5
It is now over 60 days since the last post. This thread is closed.
Refresh page
top