The TinTin++ message board

[Slysven]

I've run into a slight difficulty, in the MUD I play, I've generated a second character with, amongst other differences to my first, a lower level of search capabilities. This means that some exits from some rooms that character CAN'T EVEN SEE THEM, let alone use them. What I need is a way to disable various links depending on which character I am playing.

Also in some games, and the one I play is no exception, some exits require say a key to open them - no key - no exit. Unfortunetly the route finding code would only work in these situations by deleting the unusable exits and only reinserting them as they become available. Constantly adding and removing the same exits from the map data seems counterproductive and given the way the ASCII vtmap is drawn can cause the map geometry to change if the rooms don't properly align without the particular link in place (a sign that you haven't got it laid out correctly...!)

To accomodate this information I believe we need to add TWO flags (for three different states) to the room exit flag field; I propose:

[Scandum]

I'm kind of wary of adding door support because there's no clean way to handle them.

You can set the exit command to open a door, which handles unlocked doors.

I'll add the 'avoid' exit flag to deal with locked or unusable exits. You can use the exit data field to customize the map for a specific character, for example:

[Slysven]

Yes - I get you, an AVOID flag could be made to fit in with what I was thinking - the important thing is that the route finding algorithm doesn't try to use an exit that isn't availible...

[Slysven]

I did a bit of rummaging around in my 2.00.7 hacked version to try and impliment this sort of thing but I came a cropper trying to understand the shortest path searching function - and how I could stop it using an exit that was blocked. I know that this has been replaced with new code that deals with a weighting factor to influence route selection when there is a choice in the 2.00.8 beta.

I got the impression that part of the 2.00.7 algorithm did some tracing of routes backwards and stored the length of the path to each room from the current room in the ses->map->room_list[vnum]->size variable. The thought crossed my mind is, if that is the case then how could I make it to handle a route that is only open one-way? More importantly, does the 2.00.8 deal correctly with this one-way situation?

I guess I am tempted to abandon the 2.00.7 code and adopt the 2.00.8 beta but in what ways will my map file be changed by the 2.00.8 that would be incompatible with the 2.00.7?

The EXIT_FLAG_AVOID will be ignored obviously, but existing data entered by the 2.00.8 version should be preserved if I have to go back to the 2.00.7 "stable" release.

The roomweight attribute for each room - I'd probably add something into my existing "Frankensein" 2.00.7 just to preserve the data, though of course there is nothing there yet. Eventually I think I will use this to hold the 'Movement points' cost for each room - though I guess I will have to use the roomdata field to store that for different situations/characters and swap it as necessary.

Is there any other incompatiblities in the Map format?
Thanks Scandum, for the great work you are doing (I noted also the #MAP VNUM adoption and I look forward to the route search speed increases.)

[Scandum]

I don't think either 2.00.7 or 2.00.8 backtracks.

EXIT_FLAG_AVOID should be working in the beta, but the code is already outdated, probably best to wait till I have a stable release if you want to stay in sync.

The weight setting is more so intended to avoid annoying rooms, without removing the ability to access those rooms if needed. I guess it'd be useful to set it to movement cost on MUDs where you constantly run out of movement.

I think the current format is:

R {vnum} {flags} {color} {Name} {Symbol} {Desc} {Area} {note} {terrain} {data} {weight}