Improve make exits to zero be stubs #7658
Conversation
Working apart from parsing user data used to retain special stub exits. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
#### Brief overview of PR changes/additions *Extensive* change-set to allow the creation of stubs on special exits and the addition of custom exit lines on those as well as "real" exits. UI modified to support this (removal of dedicated "Stub exit" check-boxes on "Room Exits" dialog, new status icon for stubs in exit room Id line-edits), amendments to custom line dialogues to handle lines that do not go to a specified room. A fix to and enabling of map version 21 which eliminates the manipulations to the map data so that the internal data structures - which have developed over time - are stored in a compatible manner in older format. This largely makes use of the "User Data" parts of the Map/Area/Room constructs. Whilst developing this code I discovered that my previous work in this area was leaving the modified User Data in place after the save had taking place and with the separate development of the "background saves" this meant it was being left in place even when the map format in use didn't not need it; to fix this a revision has been made that removes those "system.fallbackXXXX" user data items as soon as the corresponding user data item has been written to file storage. With the addition of the ability to have a custom exit line for stub exits that they could, for instance point to a Map Label. There is also the addition of a circle line around rooms that have a special exit which does NOT have a custom exit line and if there are none of those a dotted circle if there is a special stub exit without a custom line - this is so that end-users can see that there are special exits/stubs in a room when there is no other indications of one being there. Also for non-XY plane "normal" exits and stubs previous Mudlet version would display triangle shapes on the room square/circle to indicate their presence - these are now suppressed if there is a custom exit line, this reduces the "stuff" on the room if it is not needed. #### Motivation for adding to Mudlet Improved map creation end-user functionality as it allows better handling of exits whose destination is not known. Also, since "Special" exit stubs can theoretically be scripts it ought to be possible to handle exits that do NOT go to a fixed location - although that will need mapper packages to handle it. #### Other info (issues closed, discussion etc) The way the extra data is stored in the current map formats will enable maps with these extra features to be opened in current Mudlet version although they (custom lines on stubs and special exit stubs) will not be visible in the mapper of such versions. With the enabling of binary map format 21 maps saved with that format will not be open-able with Mudlet versions prior to this PR being merged - but the default has not been changed so it will not be used without deliberate action by the end-user. Also added some debug messages for binary map file operations - to make it easier to debug in the future when revising the map format. `DEBUG_MAP_FILE_PROCESSING` is not defined to anything by default but setting it to `1`, `2` or `3` will give increasingly more reports of the current position in the file when reading and writing the file - which helps to work out where things are failing should the two sets of numbers get out of step. Also added some "magic" - the ASCII characters "MudletMapFile" immediately following the 4 bytes big-endian `int32_t` that contains the map file version for version 21 (or later) map file format. This is to make the detection of files as actually being binary Map Files for Mudlet even more reliable than currently - and could be submitted to: https://www.darwinsys.com/file/ Also remove the prefix from some automatic variables that start with the ill-advised `_` character. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…iles Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Hey there! Thanks for helping Mudlet improve. 🌟 Test versionsYou can directly test the changes here:
No need to install anything - just unzip and run. |
|
NOTE: This should be functional |
I'd failed to account for the zeros now stored for stubs and it was breaking the "generic-mapper" script when it was searching for rooms to match the current location deduced from the incoming text. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
… file. I initially included map symbol fonts in the code written - before I realised I had already incorporated that data in the 1.000 format! Whilst I removed the specific writing of that details into the JSON map file I left the generic (and `static`) reader and writer methods in place should they be needed in future. Previously the JSON map format did not record the map zoom level for each area - as that was introduced after the original JSON map handling was done and I forgot to put it in. It is now recorded in the area user-data of JSON map files but removed from the user data on reading and immediately from the current profile data immediately after writing it to the JSON file. Also I discovered that I had made a coding error in the prior JSON reading code that meant colours with an alpha component were not being read correctly - they lost the alpha and were drawn fully opaque whether it was recorded as less than that level of opacity or not. The JSON code has been revised to pass a version number (a decimal number with 3 decimal places) throughout the reading and writing methods and code put in to conditionally process the current fallback user data elements that are needed but which will not be needed when the version value - currently `1.000` is increased to `1.001` or more. This has not been incremented so far. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…rights Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
This looks like a great addition! Here's some things I noticed; The tooltips are different here, the second one is more informative though. Peek.2025-01-23.10-02.webmI think the circle might need some scaling along with room sizing, or perhaps we can come up with a different visual aid? I like how the room collision was done with changing the room border to a different colour, maybe something along those lines to show something is afoot? Peek.2025-01-23.10-08.webmShould we be disallowing entry of non-numerals entirely into the room exit ID field dialog?
What is the condition for this to suppress? I played around with it but couldn't make the triangles disappear. |
Yeah, I get what you are saying - though I don't want to "overload" the boarders too much - if push comes to shove that could be revised in a later PR - in the meantime I'll check the scaling - as it is I remembered there is an existing drawing issue that might also impact on the colouration/scaling of the drawing of elements for the room.
I suppose so - but that might stop you typing the space bar to clear the entry when a multi-digit number is selected - you'd have to find the backspace or delete keys and I guess there might be a tiny bonus to be able to put a text note or something in the lineedit while entering in details before the save button is clicked... 🤷
Draw a custom line for the exit in the relevant direction, as soon as you draw the first point for that line the triangles for that direction should disappear... |
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…der) Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
I've realised that moving the Map Labels to each area will make things harder in the future for some improvements and I'll need to revert some prior changes. As such format 21 is not as I'd wish it to be so I'll disable it again. If anyone else HAS used it (though it is explicitly marked as "experimental") they will need to temporarily get a copy of the old code, build it, load the map and then resave it as a version 20 file going forward.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Nice idea, that looks better imho. |
There was a problem hiding this comment.
I haven't yet looked at the code in detail, but I notice there is a performance regression in loading the map - this map of Achaea loads in 0.4s in PTBs while it takes 4s to load here.
Could you also update the PR description? It looks like map format 21 was pulled (which is ok).
Conflicts resolved in: * src/dlgRoomExits.cpp Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
That doesn't surprise me too much I just loaded the existing latest map (around 2K rooms) I I then repeated this with the development code as of (a859877) and that was faster as you suggested - it took 0.31 seconds: Going back to this PR's code I re-enabled version 21 and saved the map file (using The problem is that munging the reformatted internal data to fit in the existing map format takes time. It is possible that there could be scope to optimise this - but don't forget that my tests are being done with debug code without optimisations rather than release code with them... |
|
Is this a one-time performance hit? |
Not until users can "upgrade" to that newer format, then it'll be a hit just when using the "old" format - unfortunately I don't think we want to put the users through that twice as I think the same thing will happen when we get the map labels stored better... I will take a quick look at the serialisation process again to see if I can speed it up at all... |
|
I am going to convert this to a draft for the moment - whilst it works for me the delays on load because of the data that has to be munged to make things compatible with the current map format version (20) is not good enough for the UX if it has to be done every time. I will keep it up to date with the current development version (because I am using it personally) but won't "un-draft" it until I have "improved" the map labels such that they store enough detail to be regenerated from the stored data and do NOT have to store the "raw" |
Conflicts resolved in: src/TRoom.cpp Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Brief overview of PR changes/additions
Extensive change-set to allow the creation of stubs on special exits and the addition of custom exit lines on those as well as "real" exits. UI modified to support this (removal of dedicated "Stub exit" check-boxes on "Room Exits" dialog, new status icon for stubs in exit room Id line-edits), amendments to custom line dialogues to handle lines that do not go to a specified room.
It was intended to add a fix to and enable map version 21 which eliminates the manipulations to the map data so that the internal data structures - which have developed over time - are stored in a compatible manner in older format. This largely makes use of the "User Data" parts of the Map/Area/Room constructs. Whilst developing this code I discovered that my previous work in this area was leaving the modified User Data in place after the save had taking place and with the separate development of the "background saves" this meant it was being left in place even when the map format in use didn't not need it; to fix this a revision has been made that removes those "system.fallbackXXXX" user data items as soon as the corresponding user data item has been written to file storage. However I realised that there are likely to be some other changes needed to "Map Labels" in the near future which would also require a change to the binary (and JSON) map structure and I felt it would be counter productive (and unwelcome to the end-user) to have to handle more than one of these in a short time.
With the addition of the ability to have a custom exit line for stub exits that they could, for instance point to a Map Label. There is also the addition of
a circle line around rooms that have a special exit which does NOT have a custom exit line and if there are none of those a dotted circle if there is a special stub exit without a custom linecode revised in a later commit to put a dashed or dotted room board overriding and replacing a user selected border for rooms affected - this is so that end-users can see that there are special exits/stubs in a room when there is no other indications of one being there. Also for non-XY plane "normal" exits and stubs previous Mudlet version would display triangle shapes on the room square/circle to indicate their presence - these are now suppressed if there is a custom exit line, this reduces the "stuff" on the room if it is not needed.Motivation for adding to Mudlet
Improved map creation end-user functionality as it allows better handling of exits whose destination is not known. Also, since "Special" exit stubs can theoretically be scripts it ought to be possible to handle exits that do NOT go to a fixed location - although that will need mapper packages to handle it.
Other info (issues closed, discussion etc)
The way the extra data is stored in the current map formats will enable maps with these extra features to be opened in current Mudlet version although they (custom lines on stubs and special exit stubs) will not be visible in the mapper of such versions.
Also added some debug messages for binary map file operations - to make it easier to debug in the future when revising the map format.
DEBUG_MAP_FILE_PROCESSINGis not defined to anything by default but setting it to1,2or3will give increasingly more reports of the current position in the file when reading and writing the file - which helps to work out where things are failing should the two sets of numbers get out of step.When map format 21 is enabled in the future some extra "magic" will get added to the file - the ASCII characters "MudletMapFile" immediately following the 4 bytes big-endian
int32_tthat contains the map file version for version 21 (or later) map file format. This is to make the detection of files as actually being binary Map Files for Mudlet even more reliable than currently - and could be submitted to: https://www.darwinsys.com/file/Also remove the prefix from some automatic variables that start with the ill-advised
_character.Signed-off-by: Stephen Lyons slysven@virginmedia.com