Mapper Room/Area Placement Error

[Belgarath]

Can someone help me debug or fix a problem with my mapping script?
When I'm mapping around, all manually since no gmcp in my mud, I come into a new area and i have an alias to make the area and set my current room to that area, but for some reason it makes the area table add that room on [0] instead of [1], which messes up my room searches and autowalks.

It goes for the second room I create in that area, which takes the [1] place!

Code: [show] | [select all] lua

{
  567,
  [0] = 566
}

I just want them to be sorted correctly where 566 takes the first position in the table, followed by 567.

The functions I use for setting my current room to a new area is:

Code: [show] | [select all] lua

function setArea(name)
  local areaID = getArea(name)
  if not areaID then
    areaID = addArea(name)
  end
  mapper.currentArea = areaID
  setRoomArea(mapper.currentRoom, areaID)
  on.map.areas = getAreaTable()
  centerview(mapper.currentRoom)
  saveMap()
end

function addArea(name)
  local newID = addAreaName(matches[2])
  if newID == -1 then
    warning("That area name is already taken :(")
  else
    info("Created new area (" .. matches[2] .. ") with the ID of " .. newID)
    on.map.areas = getAreaTable()
  end
end

[SlySven]

WRONG, DISREGARD: I think the first line in your setArea(name) function is in error, the command you want is getRoomArea. Also, some versions of Mudlet 2.0+ have serious issues with changing the area Id of a room once it has been explicitly placed in an area with the setRoomArea function. If it has not been placed in an area before the room will have an area Id of either -1 or 0 IIRC but if that is not the case and the function resetRoomArea(roomID) - which indicates that your version of Mudlet has been fixed doesn't exist then the only safe way to move a room from one area to another is to:

• Copy the data of a room to a new one which then can be placed in the right area (not forgetting to move exits TO that room to point to the new one instead. If, as a result, this leaves unwanted rooms in a wanted area you will have to also copy all the wanted rooms to another area, connect up the exits for the copied rooms and delete the old area to free up the room Ids of the now duplicated rooms.

This problem came about because flawed code did not remove data about a room from the old area when it was moved to a new one - with the result of both of them appearing to own it and all sorts of nasty (and possible fatal, to the Mudlet application) things happening when some further actions (such as deletion of that room) occurred...

The issue of the order of the table contents of the results from getAreaRooms() is a "feature" in that we can't fix in the function bearing that name because it may break existing scripts that work around the fact that C++ starts its arrays at a index value of '0' whereas it is standard practice for Lua to use '1' for the index value of the same thing. In bug#1173407 it was noted that this also applies to:

• getExitStubs()
• getRoomsByPosition()

I am sure that somewhere, I or someone, else suggested "fixed" equivalent command with the names: getAreaRooms1(), getExitStubs1() & getRoomsByPosition1() but I've lost track of what happened with those...

Edit: Oh, blast, I didn't read all the details correctly and got it wrong, you will need to write (or have already written) your own getArea(string: <name>) or perhaps more correctly getAreaId(string: <name>) function to find out the ID for a given area... If you don't have one already, It'll have to get the table of area IDs vs. area NAMEs with a call to EITHER: getAreaTable() which returns a table of: {key: Name, Value: Id} OR: getAreaTableSwap() returns table of: {key: Id, Value: Name} and then iterate through the returned Lua table to find the matching area name and the corresponding Id. Ignore any areas with an Id of -1 or 0, those are dummy Ids that are used for rooms that have not (yet) been assigned an area - and should be SAFE to use setRoomArea() on!

[Belgarath]

Thank you for the response And wow, that is interesting >.> I'll see if I can work on that safe method!