Mudlet-2.0-test4 released

User avatar
Omit
Posts: 190
Joined: Sun Aug 01, 2010 10:54 pm
Location: Middle Earth
Contact:

Re: Mudlet-2.0-test4 released

Post by Omit »

@Chris.... I looked at this earlier and it bothered me... took me a little while to figure out why. I think your goal is to have a list of unlocked exits for a room with RoomID as the Key value.... problem is the ones you want to use for that can fail to deliver usefull results.
chris wrote:...
Here is the output now, which should restore the old behavior and add the one that I like:
getSpecialExits
table {
42: '0enter'
}

...

getSpecialExitsTable
table {
42: table {
'enter': '0'
}
}

}
If there are more than one exit to the same room, they will overwrite each other in this table.... the result being that only the last entry for a roomID will be reported to the user. (making the first exit for that destination unavalible for pathfinding) The only way to return usefull lock information in a Lua table with the roomID as the key is to filter the list of values before they are put into the table(hence my suggestion to be able to request just locked or unlocked rooms).... Of course, if they are filtered before they are returned.... there is no need to return a table of tables but just the key and value.
table {
12: "enter"
}
(That should also make it easy for people to change pathfinding scripts to just use unlocked exits.... they would just need to add the parameter to the function call and all other scripting would still work)

Yes, values would/could still be overwritten when calling these functions(even with a filter) but it should not cause an issue as at least one valid locked/unlocked room would be returned.

User avatar
chris
Posts: 493
Joined: Fri Jun 17, 2011 5:39 am

Re: Mudlet-2.0-test4 released

Post by chris »

That's the same issue with the normal getRoomExits(), as I mentioned getRoomExitsSwapTable() exists for both flavors. The # is either a 0 or 1 to indicate status so you can script like:
Code: [show] | [select all] lua
for i,v in pairs(exit) do
 for j,k in pairs(v) do
  if k==0 then
   do this
  end
 end
end
Perhaps a better scheme would be a table like:
Exit Name = {1=to room id, 2=lock status} to avoid the extra for loop. The reason it was done in the first place is because I hated having to do string splits to get the exit and lock status. Also, realize I don't see the problems you may have because I run my own development branch that is merged back into the main. I think this is a resolved point, as both the initial functions exist as well as two new flavors. The outstanding issue is how the special exits are stored in TRoom, I think a QMap <int, QMap<> > should be the structure and I'll experiement with that. I also resolved the setRoomEnv issue with non-default alpha(even though the old implementation didn't work in the first place without it)

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet-2.0-test4 released

Post by Heiko »

chris wrote: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.
You cannot define exits to rooms that don't exit, otherwise you need to run map exit audits in the drawing code which, in turn, leads to unnecessary performance issues. The mapper must be able to store multiple special exits to a given room id e.g. a room has 3 different exits to room id 1: "touch blue stone" -> 1, "caress blue stone" -> 1, "kiss blue stone" -> 1.
chris wrote: It should allow multiple unique exits per to id
That's what it does.
chris wrote:, 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.
I don't have a clue what you are trying to say here. Please explain in more detail.
chris wrote: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?
Prepending lock information saves a ton of memory in those cases where people have huge maps and rely mainly on special exits in their mapping scripts. Note that the advantage of special exits is that they are so flexible and can e.g. be used to store Lua scripts to make the special exits dynamic and context sensitive.


The special exit lock information, i.e. the prepended 0 or 1 before the exit command is supposed to be hidden behind the getSpecialExit() interface. I simply forgot to do this when I added special exit locks. One of the isLocked() functions should get the lock status. getSpecialExits() will only show what special exits are defined and contain no information on the lock status.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet-2.0-test4 released

Post by Heiko »

chris wrote: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.
I haven't looked at your repository lately, but make sure to synch with SF.net. When working on the map code, make sure that you don't brake grid maps as these use a different render mechanism i.e. cached image drawing.
Any major map refactoring should wait until after the next major release.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet-2.0-test4 released

Post by Heiko »

@ Omit
As I've pointed out above, getSpecialExits() is not supposed to carry any kind of lock information. It will be fixed to b behave just like it used to do before special exit locks got introduced. However, I think it's a good idea to add your suggested lock exit filter as it doesn't break the old API and makes things easier for some people.

User avatar
chris
Posts: 493
Joined: Fri Jun 17, 2011 5:39 am

Re: Mudlet-2.0-test4 released

Post by chris »

That's what it does.
No it doesn't, here is the latest SF code:
Code: [show] | [select all] lua
void TRoom::addSpecialExit( int to, QString cmd )
{
    // replace if this special exit exists, otherwise add
    QMapIterator<int, QString> it( other );
    while(it.hasNext() )
    {
        it.next();
        if( it.key() != to ) continue;
        if( it.value().size() > 0 )
        {
            QString _cmd;
            if( cmd.startsWith('0') || cmd.startsWith('1') )
            {
                _cmd = cmd;
            }
            else
            {
                _cmd.prepend("0");
                _cmd.append( cmd );
            }

            other.replace( to, _cmd );
            return;
        }
    }
    // it doesnt exit -> add
    QString _cmd;
    if( cmd.startsWith('0') || cmd.startsWith('1') )
    {
        _cmd = cmd;
    }
    else
    {
        _cmd.prepend("0");
        _cmd.append( cmd );
    }
    other.insertMulti( to, cmd );
}
The value is replaced, hence touch stone/kiss stone will overwrite the prior exit. You may have multiple identical exits to different rooms as well, which as I said in most cases will be wrong, but should probably be up to the user to keep correct.

Here's an example:
Code: [show] | [select all] lua
addSpecialExit(37,41,'enter')
addSpecialExit(37,42,'enterc')
display(getSpecialExits(37))
addSpecialExit(37,42,'enterd')
display(getSpecialExits(37))
which gives:
Code: [show] | [select all] lua
table {
  41: '0enter'
  42: '0enterc'
}

table {
  41: '0enter'
  42: '0enterd'
}
I don't follow what you mean about defining exits to rooms that don't exit, what I described in: 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.

was the problem I just described, which is that special exits replace eachother. other.replace makes that fairly evident. Maybe a QStringList would work better for memory management on huge maps? If that's still an issue with parsing through the stringlist, maybe QMultiMap might be the best storage structure?

User avatar
Omit
Posts: 190
Joined: Sun Aug 01, 2010 10:54 pm
Location: Middle Earth
Contact:

Re: Mudlet-2.0-test4 released

Post by Omit »

Try it again with the swap function.... Special exits are funky... Hence the need to store the data as it was.
getSpecialexit give A valid command to destination id and swap gives you all valid commands.
An exit should only be overwritten if you define one with the same command.

addSpecialExit(90,14,"enter")
addSpecialExit(90,56,"enter")

Oh... When mapping I define all new special exits to room id 14
(Room 14 has no location). I then update the command with a "real" room upon going that dir for the first time.

User avatar
chris
Posts: 493
Joined: Fri Jun 17, 2011 5:39 am

Re: Mudlet-2.0-test4 released

Post by chris »

The point is two mappings from->to with different special exits will overwrite, QMap doesn't allow multiple identical keys, regardless of using the swap function. By keying via the to room id, we have only one special exit per to room id. We need a new structure.

User avatar
Omit
Posts: 190
Joined: Sun Aug 01, 2010 10:54 pm
Location: Middle Earth
Contact:

Re: Mudlet-2.0-test4 released

Post by Omit »

That is why the "key" is the command string.(or was when special exits were added to the api.)
I do not know C++ but have many many years of experience with relational data...
That is the only way it makes sense to do it. ( this is my fourth mapper I have written, all but this one I have created my own data structures. And have done it wrong.)

As for the "structure" to hold the info....a string certainly sounds reasonable to me.(unless there is some other mech for a table w/ a string as the key). If you wanted to "normalize" the data structure it would require anouther table to be created/updated/stored. It would house an id for every possible movement command. This adds a lot more complexity. I would avoid this and just parse the string as long as it can be done easily enough.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet-2.0-test4 released

Post by Heiko »

@chris

No, QMap can also store multiple values with the same key.
The code has this: other.insertMulti( to, cmd );
The problem is that you changed the getSpecialExit() function by returning a table with room IDs as keys instead the old format that had command as keys and room IDs as values. This used to work very nicely in the past.
Consequently, if you want a getSpecialExitTable() type of function that returns roomIDs as multiple keys then you need to work around the Lua restrictions by returning a table that has the room IDs as key and a table containing the various exit commands as value.

Please also try to explain your other posting above that I didn't understand.

Post Reply