Generic Mapping Script

[chrio]

When you are able to see normally, that information is updated at a different stage.

Ah, that makes more sense then. Thanks for the reply.

[Jor'Mox]

Minor update to the script. It was having issues resetting once it was told to create a portal. Issue fixed in the current copy.

[Jor'Mox]

I'd be more than happy to test things out to see if I can replicate the problem in a new version though, assuming someone can make a compiled binary for me.

I've got osx and win32 binaries posted that I built a couple month ago. They're not 100% current, but they are fairly close.

http://forums.mudlet.org/viewtopic.php?f=7&t=5712

Finally got around to testing on these, though I'm just getting started. One thing that is a real problem is when you select enough rooms, it becomes completely impossible to reposition them effectively, because the list of rooms selected covers a huge portion of the map. Is there a way to adjust things to make this less of an issue?

Also, side note... this version absolutely changes the way existing functions work in regard to mapping, to such an extent that I am needing to make a significant number of modifications to my mapping script (which worked in 2.1) in order for it to work properly. Specifically, getRoomUserData used to return "" when there was no data, and now it returns nil, which of course upsets code written based on its previous behavior.

[Jor'Mox]

And, when trying to move rooms via the map GUI, it behaves weirdly, such that if I am not super careful when I right click and select "move" it won't work. I have to right click near the bottom of my map window, and move my mouse after clicking "move" very quickly so that it is back inside the map window before the menu (which extends in this case above the top of the map window) disappears in order to be able to move a room.

[Nyyrazzilyss]

Also, side note... this version absolutely changes the way existing functions work in regard to mapping, to such an extent that I am needing to make a significant number of modifications to my mapping script (which worked in 2.1) in order for it to work properly. Specifically, getRoomUserData used to return "" when there was no data, and now it returns nil, which of course upsets code written based on its previous behavior.

I should have made a list of changes I had to make to accommodate changed functions. Glancing at my script, I do see where i'd changed that so both versions worked

Code: [show] | [select all] lua

exitNames = getRoomUserData(xroomid, "exitNames")

if exitNames ~= "" and exitNames ~= nil then

[Jor'Mox]

You can also just do getRoomUserData(roomID,value) or "". That way you don't have to adjust any logic that was created (and may be missed if it isn't close to where the data is gathered).

Anyway, I have updated the main script with a few updates to make it work appropriately with 3.0.0, as well as a few places I had missed adding the in and out direction doors (does 3.0.0 support having these for real now?).

[SlySven]

Guys, can you point out to me the Git commit (at least the first 8-10 digits of the SHA1) of the code that you started with - I had an issue with room movement in the GUI being weird and it was because I had a - sign in the wrong place. I don't think I released code with it in but I have to wonder and want to check!

I also had improved code for the "room selection" widget which also shows the room names if they are used and which dynamically resizes the widget that shows them so that the height needed to show all the numbers (and the names if required) is just enough to show and it expands and contracts as needed - does yours do that or have I yet to put that out there?

<aside>{I've worked on multiple revisions of code and I'm sort of losing track of what "normal" people are currently at }</aside>

As for the Room (and Area and Map) User Data, it might look as though I've broken backwards compatibility a little there, but since it is legitimate to store an empty string as the "Value" against a "Key" (e.g. using the presence or absence of the key as a flag) it is not possible to return an empty string on the absence of the "Key". I know it messes things a bit but I could not see a different way to do it - and yes it bit me as well, but in virtually all the Lua functions I get my hands on, if there is a nil return value there will be a second return as a string explaining the reason for the error. Usually an invalid type of an argument will cause a Lua error which terminates the current command and puts a error message on the error display of the editor for that profile AND on the central debug console if it is active; on the other hand an invalid value for an argument, e.g. a non-existent room number for a command that takes an existing room number will go the nil+message route which is a fairly standard way for Lua - it means that following code can recover in ways that it can't if a Lua error is invoked.

As we refactor and standardise the extensive {the C++ source file for TLuaInterpreter is the largest one in the entire project} range of Mudlet Lua subsystem commands (some of them have really misleading or just plain wrong error messages: e.g. some refer to a completely different command as the code was copied from another one and although made to DO the new thing but the error messages were not revised) you can expect this method of reporting failures to increase.

[Nyyrazzilyss]

I'm not sure which commit I built from - I know my windows build was made from your git/pr308 a couple days prior to it being merged, the osx build was a couple days earlier (while it still had the wall of text audit messages).

I'll make/post a current windows build this week, and ask the person who did the osx build for me if they can rebuild.

[Jor'Mox]

So, the room selection window that comes up does in fact show room IDs and room names, and resizes dynamically to fit the selection. However, that is the problem. With room names, it is now far wider than it was, so if I have more than two or three rooms selected at a time, the whole center of the map is covered by it, making it impossible to make a fine adjustment to where the rooms are placed, and similarly impossible to put them back where they started. It also appears that the font used is somewhat larger than it was, which makes the problem worse. Secondly, room selection via click and drag isn't as sensitive as it used to be, so it is more of a challenge to quickly select rooms that way. In a similar way, it is also more difficult to select a room by clicking on it. As far as my problem with actually being able to perform a room movement, I get the impression that the problem lies in the fact that when the mouse exits the bounds of the map window, it is getting cancelled. I can see why that might be done, even more so if there is a click outside of the window, but since the menu that pops up often extends beyond these bounds, I think that cancelling on mouse exit is a poor choice, and it has caused m a great deal of consternation, especially as this was not an issue before.

As a side note, I have noticed that there is a setting for maps that is supposed to turn on or off high quality graphics of some sort. However, I see the exact same thing regardless of it is on or off (on my Mac), and this is the case regardless of which version I use (2.1, 3.0.0-delta, or this later 3.0.0 build). If this is intentional, perhaps it would be best to hide the checkbox, so as to avoid confusing people. And if not, I'd be interested to see what improved graphics look like on the map.

[Vadi]

That setting just toggles anti-aliasing on and off - maybe yours is somehow always forced on by OS or video card drivers?