Store keywords, ambiance comments, exit descriptions, and sloping messages

[teoli2003]

In the long term, I would like to improve:

• the search
• the offline mode that allows to discover an area, or to practice it.

Like the room description, these messages are not useful in what I call the 'fighting' mode, but important to catch the ambiance, or for quests.

I currently store such messages in the room note, but this is not very practical to build new feature on top of it (like improving the offline mode). It is also difficult to know which areas of my map is complete or not.

The current map file schema can't store them, so I plan to add these:

1. keywords
   E.g.
   *+ CW>l tower
   The five-storey-high tower seems to be of dwarven make. A whiff of smoke
   rises to the sky from a chimney on the roof.

(Yes, there are plenty of hidden gems all over there!)

A map of strings, associated to a room.

[There may be several keywords with the same description, but I don't think it is worth using a more complex structure]

2. ambiance comments
   E.g. (In Fangorn)
   By a whiff of air, the odour of the decaying vegetation is intensified.

A list of strings, associated to a room. [Several strings for a room]

3. Exit descriptions
   Quite common, for secrets (found or not found), death traps, and explanation why a direction is blocked. Some areas, just for fun :-)
   E.g.
   *+ CW Move:Tired>l d
   One of the planks looks like it could easily be moved in and out of
   place.

A single string, associated to a room direction (flagged as an exit or not)

4. Exit 'passing' descriptions
   *+ CW>e
   You struggle to reach the top of the hill. [Fake one, didn't had one handy ;-) ]
   Top of the Hill

A single string, associated to an exit.

I think I will extend the file schema first, and allow to read/set them using a new frame of the room edition dialog.

Once this is done, I plan to extend the offline mode to display them.

@nschimme what do you think?

[nschimme]

My only concern is the impact of storing all of this additional metadata in memory given that its only useful for "offline" use. The primary use case for MMapper is still "play" so I don't see this as adding value in that department. That being said, I see this as still useful.

Perhaps we should move away from the current custom binary storage format and utilize a SQL table instead? This would allow us to easily select additional room metadata from disk and not force us to load everything into memory like in the current system. This also allows us to go nuts with additional metadata.

[waba4mume]

I'd love that, as an explorer. And yes, sql(ite) storage seems like a sane way to go about it.

FYI, passing descs are called slope when building rooms (they're designed to make exits cost a few extra movement points). They can show a different message when riding.

[teoli2003]

I made some calculation to see if the size of MMapper in memory would be too big or not.

On MacOS Sierra:
MMapper at launch (without a map): 81.9M
MMapper with my map (95% of all Arda, with a lot of infomarks): 216.6M

Skype: 417M
Chrome/Firefox: several processes > 1G

Estimation 20000 rules w/ 2 exit messages/room (likely overestimated!). Sloping message and ambiance messages included. 20000 rooms w/ 1 keyword (likely overstimated). 100 chars/message
-> 6'000'000, 6M

I think that the additions of these message won't increase the memory significantly (and the .mm2 file being zipped, it shouldn't be much either).

[nschimme]

Thanks for doing the memory analysis. It looks like it should fit in memory even if we decide to create a mobile client given how most phones have 2GB+ of RAM these days.