Mapper questions

Hi,

I'd like to use the mapper module.

1. If the mud doesn't send unique room numbers, I know that an uid can be generated by hashing the room's title, exits, and description. But in some cases there would be collisions caused by e.g 2 different rooms having identical name/description/exits. Is there a way of overcoming this problem? For example, if room A and B have the same hash, and A's north exit is B, I'd want different uids. If this is impossible to do, how would it affect pathfinding if the calculated path passes through such rooms - would it just get stuck there?

2. The mud provides the ability to set different colours for room name, exits and description, providing an easy way of extracting this information. However, when the incoming text is printed to screen, I don't actually want the colour to be shown as that would interfere with my screen reader. How can I get the best of both worlds?

3. How exactly does an exit of a room get mapped so that it points to another room when you walk? I know that conceptually, when you type east and you are in a new room, that it should update appropriately - but how does it associate typed commands with responses? What about custom exits like "inn" or "shop"?

4. Is teleportation supported for pathfinding? E.g, casting a spell to recall? In another mud, you can either walk, or use waypoints. Waypoints are rooms that allow instant travel to other waypoints.

The problem is, rooms should be identifiable in their own right. That is, to know that A's north exit is B, you would actually have to walk north and see what happened. And if B happens to be full of angry mobs, you may not want to do that.



If you have rooms that are different but "look" the same, then the mapper will get confused. For example, if you had something like:



As you go north from the town, it thinks that you reach "A narrow path" (which you do). Then when you go north again it thinks that north from "A narrow path" leads back to itself. Ditto when you go north a third time. Finally when you hit the village, it would correct the north exit for "A narrow path" so that its view of that part of the MUD is now:



Which is obviously incorrect. Attempts to speed-walk or path-find will fail for that segment. However once you clear the problem spot everything should be OK after that.

---

I don't see why colours would affect the screen reader. The screen-reading plugin uses a callback that gets the raw text as displayed, without colours.

---

As described in this post:

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

The mapper is "MUD agnostic" (the mapper module). It is supported by other functions in a plugin, those functions call functions like "get_room" to get room information. These would vary from MUD to MUD (eg. depending on whether you have room numbers, or have to create your own).

If the MUD doesn't tell you where each exit leads, what I normally do is remember when the user types an exit (eg. "east") and then when we end up in a new room we deduce that going east from the previous room must lead to this room, hence we can add that exit link to the database for that room.




They won't work unless you allow for them somehow. In any case the drawing part of the mapper only draws the main directions (n/s/e/w) plus the ones inbetween (ne/nw/se/sw) and the two directions "up" and "down".



Not in the version I did, however I believe some people have added portals - I'm not sure how. I think Aardwolf does that, you could ask Fiendish how he did it.

I think that if colours happen to match those that screen readers look for when watching for screen changes, they announce it, which causes problems.

Regarding colours, is it possible to do something like the following?

* have all triggers that use colour do a keep evaluating, hide text from output and log
* have a trigger with a high sequence number catch all coloured text, printing the text out without colours?
* Since I can't visually see the colours myself, is there an easy way of having it print what colour text is? E.g colour<black>hp:250/250</colour:black>

I understand the heuristic used for mapping uses last sent text to match directions, but that breaks if you're sending stacked commands. Is there any way around this problem besides going to each room slowly?

You must be using a different screen-reader to what ships with MUSHclient. That is specifically designed to read the text-only output of the MUD.

If you are using something else that you are more comfortable with (and I don't know how it is reading the graphics) you can always set all the ANSI colours to white (except the background of course) so there won't be any colour changes.

If you're talking about the plugin that reads incoming text using sapi5, then I don't know of anyone who uses that due to high latency in the voices themselves and speech rates for most voices being too slow. Most use MushReader instead, which directly communicates with screen readers: https://www.allinaccess.com/mc/

If I did that, that would defeat the point of using it - I want to have the mud send me different colours so I can differentiate them, and yet have it displayed as if ascii was not turned on (i.e, treat everything as white on black). Unless you mean there's a way to do this?

What're the performance characteristics of the mapper module or the pathfinding algorithm used? The mud I want to use it with has large overland areas (e.g materia magica). One continent has 200,000 rooms (counting these rooms).

I have data about the terrain for all these rooms, and was thinking of using the mapper to compute optimal paths between areas. Fully mapped, the mud probably has millions of rooms.

You said before:



Now you are saying you want the colours to be spoken. I am confused about what you are asking for.

The mapper is quite fast however you normally limit the depth of the search. Obviously searching 200,000 rooms would take time. Normally you set a limit (which is configurable) of around 50 rooms. That is, 50 rooms outwards from the starting point (that would be more than 50 rooms in total, eg. 50 rooms east, 50 west, 50 north and so on).

My thinking there is that you want the fastest path to a local shop, not the fastest path to somewhere on the other side of the continent where taking a portal is probably a better option. There is a bit of background to the algorithm in this thread:

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

Let me try explaining it more clearly.

If I have ascii colours being displayed from the mud in mushclient, they have problems since they interpret certain colour changes as new text being drawn to the screen, and try reading parts of it. This interferes with the other plugin, mushreader, which uses the provided callbacks to directly tell the screen reader what to read.

What I want is the ability to turn on ascii colour in muds, so that I can do this:
1. create triggers based on colour attributes.
2. Just before the screen is updated with the new text, to intercept the text about to be drawn, strip ansi from it, and then draw the modified text.

This would allow me to create colour matching triggers, and have my screen reader not break.

I wish you would give more detail about this screen reader "mushreader". If it is reading out colour changes you can surely tell it not to?

As for detecting colours, if you are displaying ANSI colours (the standard 16 normal and bold ones) you can still detect that "brown" has arrived even if you choose to display it as blue on the screen.

Your question:



... seems to me to be a different topic to "mapper questions". It is nothing to do with the mapper, but an ancillary question about displaying colours and screen readers. It is confusing to jump back and forwards between discussions about detecting room numbers, and how long it takes to pathfind, to asking about how to suppress colours.

Apologies, should I create a new topic for it? It came up because some muds allow you to colour room names and descriptions differently, which makes detecting them much easier.

I think a new topic for how colours are drawn, and screen-readers would be appropriate, yes.