Mudlet-2.0-test4 released

[Omit]

Hmm... It appears the Special Exits are more broken than I thought. It does NOT appear that you can save more than one command for a single direction any longer..... Something changed in the way they are stored(likely using the room id as the key, this makes it incompatable with alot of speciel exits). It would make absolutly no differance for pathfinding (as it will find A valid exit) but very very broken for tracking your movements by the commands typed. (Very Very Very important)

I need this corrected if I hope to create a good generic mapping script for LP muds using just the mapping api..... I can (and did before mudlet was able to track speciel exits) create a structure for speciel exits in Lua and save them seperately. This will make mapping of alot of muds unreliable. (not to mention that the map would not be easily portable)

EDIT:
Looking in to this further(looked at the C code for it and did a little testing), it appears there is an error in the way speciel exits are added.... currently when you add a speciel exit, it looks for an exit with the same roomID and replaces it if it exists already. This is not desirable...... I will show you why.

Here are the current results of calling getSpecialExitsSwap(Gid) for a room I was attemping to map exits for.
table {
'0closet': 291
'0staircase': 19
}

...I know, doesn't look too bad (other than the known issue with the 1's and 0's) but now look at the results of getSpecialExits(Gid)

table {
291: table {
'closet': '0'
}
13: table {
'staircase': '0'
}
19: table {
'staircase': '0'
}
}

...did you notice that.... the same command is mapped to two differant rooms? (This should not be, the Command must be used as the key value for speciel exits to avoid this. Very possible to have multiple commands mapped to the same room but should never have more than one room associated with a single command.)

[Heiko]

Oh and that reminds me, whenever I load my profile, I've just remembered that it says about failing to get permissions or something like that. That might be it I'm presuming? Again, thanks for your help. Appreciated.

That's most likely your problem. Somehow your file permissions are screwed up. Post a screenshot of this message please.

[Heiko]

Hmm... It appears the Special Exits are more broken than I thought. It does NOT appear that you can save more than one command for a single direction any longer..... Something changed in the way they are stored(likely using the room id as the key, this makes it incompatable with alot of speciel exits). It would make absolutly no differance for pathfinding (as it will find A valid exit) but very very broken for tracking your movements by the commands typed. (Very Very Very important)

I need this corrected if I hope to create a good generic mapping script for LP muds using just the mapping api..... I can (and did before mudlet was able to track speciel exits) create a structure for speciel exits in Lua and save them seperately. This will make mapping of alot of muds unreliable. (not to mention that the map would not be easily portable)

EDIT:
Looking in to this further(looked at the C code for it and did a little testing), it appears there is an error in the way speciel exits are added.... currently when you add a speciel exit, it looks for an exit with the same roomID and replaces it if it exists already. This is not desirable...... I will show you why.

Here are the current results of calling getSpecialExitsSwap(Gid) for a room I was attemping to map exits for.
table {
'0closet': 291
'0staircase': 19
}

...I know, doesn't look too bad (other than the known issue with the 1's and 0's) but now look at the results of getSpecialExits(Gid)

table {
291: table {
'closet': '0'
}
13: table {
'staircase': '0'
}
19: table {
'staircase': '0'
}
}

...did you notice that.... the same command is mapped to two differant rooms? (This should not be, the Command must be used as the key value for speciel exits to avoid this. Very possible to have multiple commands mapped to the same room but should never have more than one room associated with a single command.)

The special exits need to work exactly as they used to work before test4 in order to stay compatible with old scripts. Any new functionality needs to be added in a way that keeps old scripts working.

@ Omit:
Can you please summarize all mapper problems that need to be fixed? I'm trying to do an update asap.

[chris]

I'll restore the older getSpecialExits() and add a new table of table function then (getSpecialExitsTable()). The way special exits are stored seems funky to me, it first checks if the room to id exists, then if any special exit exits it replaces it, otherwise it adds it. It should allow multiple unique exits per to id, and the total # of exit commands in most cases should be unique (unless you flip switch, and enter now goes from room 10 to room 12, etc.). Because of this latter case I'm sort of leery of imposing restrictions the end user can't script around by toggling exit locks. I will impose the former restriction as well, but for now I'm going to hold off on the latter.

Heiko, do you foresee any issues if the 'other' exit is made to be a QMap<int, QMap<string, int> > instead of the prepending stuff atm?

[chris]

For the mapper, my request would be that we need to have the code to be as concise and easy to read as possible (ie paintEvent). I made a few new functions to take care of some of the repetition, such as drawPlayerLocation() and drawMapInfo(), and changed a few things around in the T2DMap code that was causing some funky behavior after label adding and using updateMap(). However, in general I think a refactor is needed to augment development.

One more Q Heiko, if we do agree that the new storage container is best, do you want to maintain the prepending of the exit lock for the getSpecialExits/Swap?

Here is the output now, which should restore the old behavior and add the one that I like:
getSpecialExits
table {
42: '0enter'
}
getSpecialExitsSwap
table {
'0enter': 42
}
getSpecialExitsTable
table {
42: table {
'enter': '0'
}
}
getSpecialExitsSwapTable
table {
'enter': table {
42: '0'
}
}

[Omit]

Thus far I have only found 3 bugs in the mapping functionality in mudlet….
1>setCustomEnvColor(environmentID, r,g,b,a) - the fourth parameter(alpha) should be optional and default to 255
2>getmapvar(“whatever”) - should return nil if the variable does not exist.
3> Special Exits – (see below for my suggestions)

My suggestions for changes in the Special Exit functions:

addSpecialExit(roomIDFrom, roomIDTo, command[,lockStatus]) – add 4th optional parameter for lock/unlock, defaulting to unlocked.

exits = getSpecialExits(roomID[,lockStatus]) – add optional 2nd parameter to only return locked/unlocked exits. Default would return the first(guess it’s really the last) valid exit with the room id as the key, 1 as second parameter would return only locked rooms and a 0 would return only unlocked rooms.

exits = getSpecialExitsSwap(roomID[,lockStatus]) – same as above except with the command as the key in the returned table.

The advantages of doing it this way is that it doesn’t break previous scripting and if you need to use these for pathfinding you do not need to parse the returned table for unlocked/locked exits.

@Chris regarding “Switch Rooms”, If I understand the problem correctly, I would handle the switch as a special exit(same as a door or whatever), it moves you from one room to another ( granted they look the same but each have their own set of exits, only really hard part, depending on the layout of the mud is determining the state of the switch.)

Omit

[chris]

Do you know that getmapvar () returns a list of all variables?

[Omit]

Yes, I know that but the average user is alot less likely than I to figure that out, if you do pull the entire table, you have to do an additional check on it. It is alot more user friendly to have it return nil. (and I would argue that any function added to the mapping api should do the same, pretty sure all the other functions already have a mechinism for returning an empty or nil result)

[chris]

I actually intentionally made it somewhat nonfriendly for regular users, hence my reluctance. You are changing core variables and there can be catastrophic results if a type mismatch somehow gets through. You are also performing the same amount of checks if it returns nil as opposed to accessing a table for the initial check

[Omit]

Of the three "bugs" I mention, this is the least of them. This is new in this version (so won't break anything previously done) and there is a fairly easy work-around for it. If the behavior does not change it would not break my heart.

EDIT:
I would love feedback on my suggestions for the changes to the speciel exit functions... (I do not and have never written a pathfinding script or found a need to lock exits but my hope is that the changes suggested would make it easier)