Mudlet - Forum

Looking at the previous code I see from T2DMap::switchArea(QString name): that if the new area has rooms on the same z coordinate as is currently showing in the 2D map it positions the view at the centre of all the rooms on that z-axis value - if it does not it get the z-coordinate of the first room in the Area's QList of rooms and then positions the view at the centre of all the rooms on that level - for an empty area it positions the view at (0,0,0). This is for the 2D map - I haven't checked the code for the 3D one...

However things should have changed with the recent revisions I made to the storage of the list (now a set) of rooms for each area - there is no such thing as a "first" member in the set, at least not something that can be guaranteed to always be the same. Ah, that's awkward, the code does the same thing as before but just uses the first room Id it gets out of those that the area has if the new area does not have rooms on the same Z-coordinate value - but the first room it uses really will be arbitrary.

Let me think about this - perhaps I need to have a count of rooms in each z-coordinate and then go to the level that has the highest count and centre the view on that (using the lowest level in the event of a tie - which will work best if the 3D mapper has similar sort of code).

Sounds reasonable, i'm not sure if that's what it's always doing (2D, I don't use the 3D mapper so can't speak to that)

Often it does seem to center that way, but quite often there's no rooms on the screen at all.

That is promising - got some prototype code that EITHER (if the new area has the same z-coordinate as the current is currently showing) works out the mean of all the rooms on THAT level then finds the room closest to it and centres the map view on it OR (if that z value is not in the new area) finds the z-coordinate that has the MOST rooms (and chooses the lowest in the even of ties) then works out the mean of all the rooms on THAT level then finds the room closest to it and centres the map view on it. There is a short-cut exit in that if the area chosen is the one with the current player in it - it automatically re-centres on the player room.

Bottom line is that a room is always shown at the centre of the map unless it is an empty area - which is much more user friendly than being dumped onto a blank part of the map and not knowing where to scroll to!

Just have to port the same sort of thing (in 3D) to the 3D mapper.

EDIT: That is done and in and commit-178c664d (development) and commit-af986079 (release-30). Just waiting for C.I. tests to pass and clearance to merge them.

I've downloaded and compiled this - Not getting any errors, and selecting an arbitrary area from the mapper is now working -much- better. I picked a random selection of areas, half of which previously would center on empty space - Everything is centering on the rooms present in that area now

Of course, back to the original thread topic - It would be nice if calls to centerview also updated the selected map in that list accordingly If the entire map is going to change to a different area, the name of the map showing in the widget really should also change at the same time.

Perhaps instead of just updating area listed - A pair of get/set functions for area listed on widget. With calls to centerview always occuring userside from the script, a user call to that function would also deal with updating (if required - or not updating if they don't want to). Future extendability of that (without having to return to it) would be in the direction of allowing clicking on user defined buttons/map labels to also change that map.

What (might?) work best is if it didn't work by list entry number, but mudlet area number, and just translated between the two internally.

Synchronization right now is only one way - Changing the area listed changes the map, but changing the map doesn't (can't) change the area listed.

I haven't tested, but if sync was userside by choice, that would likely link with sysManualLocationSetEvent

I wasn't aware that centerview(<roomId>) wasn't now updating the area displayed in the widget - it is something that I had put into code at some point in the past but it might have been a prototype that I did not "let out of my laboratory"...!

Will check and fix if not.

Oh dear - we now have a corner case that needs to be handled IFF: we have done a centerview(...) with a room in the default area AND: we have hidden the "Default area" from the area selection widget AND: we have revised the code to show the currently displayed map's area in the widget THEN: the area selection widget CANNOT show the area name because it does not contain it.

I think I can see how to cover this - we must clobber the area widget until the map area shown is NOT the default area (given that the widget CAN be used to arrange this it is not a feasible action to hide or disable the widget) - instead I think I have been able to italicise it and put a line (or three) through the displayed text to show that it is not in a normal state: View image if it is too big to show the right side of image in the browser in-line.

Hadn't even thought of that one - I never call centerview myself without first unhiding (unlocking a room and moving it to the correct area). It would be different though for people using those areas differently, or for someone trying to do so on mine directly though the lua commands / not through my script functions.

I guess the only question then would be how much to let the user do something the script disallowed? They do have the ability to go into the settings themselves and enable the default area display...

My opinion at least would be sure, italic/slash/(unknown)/etc and a blank map would be fine. It doesn't crash, and it is correctable.

(edit)

Compiled the latest and using pr308 100% now (not delta) - It's working really well, not to mention pr308 has pretty much my entire mapper wishlist - Hopefully it hasn't been to much effort Thanks!

The user can always do a themselves - unless you start to get evil and write a replacement centerview(...) wrapper yourself - which can be worked around if they were really bothered (though packaging things up like the Geyser/Vzyor systems are, does make it more bother to do so)!

BTW Vadim has pointed some issues with those PRs (a typo and concerns about the "Wall of Text" response that the accumulated glitches that a "mature" map can accumulate over time may provoke as a result of previous "undocumented software features" when it is "cleaned-up") - so those are still Works In Progress at this time...

SlySven wrote: BTW Vadim has pointed some issues with those PRs (a typo and concerns about the "Wall of Text" response that the accumulated glitches that a "mature" map can accumulate over time may provoke as a result of previous "undocumented software features" when it is "cleaned-up") - so those are still Works In Progress at this time...

Just a followup for you on that one - I've got several people running pr308 (both windows and osx) with an updated copy of my script now. They were all updating from previous versions of my script, and the 'wall of text' part was brought up by all of them. In particular, it shows when the (older) mudlet saved map loads on first startup, then another huge one when they go through the map update process to move from the older half dozen individual maps that I would use to the single much much nicer pr308 map.

And yes - If I was working on the maps, i'd need/want to be aware of that. They definitely don't need it, especially since they're already being switched (from the map update) to 'fixed' maps. The only reason it was happening was because I needed information that wasn't being affected by that from their older mapfiles, so those maps had to be loaded (generating the warnings)

You may want to encourage your users to look on the last tab on the profile preferences and set the map format to the highest value there shown (should be "18 - {experimental not recommended}") - it should "stick" when/if a map gets "saved" and will default to that once a "release" version comes out. You may wish to consider offering two versions (or just work in the highest version and drop back before saving a version for players who are sticking with older versions and then re-saving back at the highest before quitting out) - though if you are using "other" means to create the map (with your own map data parsing/generating script system) then you may have other ideas and this may be academic anyhow.

For the record: the "map and area user data" feature (similar to the previous "room" one) needs map file format "17" and the "copy a map to several other profiles and keep track of where the player is for each profile separately" needs map file format "18".

I'm just finishing off the "send map issue report to a file" (re-purposing the previously redundant "errors.txt" file in the profile's "/log/" subdirectory) - by default most of those "wall" messages will not be shown but will be sent there - together with a suggestion to look at the file at the relevant point, on the main console if there are "significant" issues. However a check-box on the "map" tab of the profile preferences will re-enable the current "detailed" reporting on-screen.

Sadly, now we have got the "default area" (at -1) properly instantiated I've notice a slow down on the auditing process (the 2.3 Million room map that I've previously used as a test case is taking me a good few minutes to load and check) for more reasonable map sizes (say <100K rooms) it should not be too bad...