Feature Request(s)

All and any discussion and development of the Mudlet Mapper.
mudlettest
Posts: 9
Joined: Tue Nov 02, 2010 12:34 pm

Re: Feature Request(s)

Post by mudlettest »

Heiko wrote:
mudlettest wrote:Actually, linking to Nirvana can be very useful. For example i move to new room and it could show me all exits the room currently has, so i can just map further by just looking at map - all exits that have to be mapped are clearly seen.
Where is the problem? If you see exits to unknown rooms, you create new rooms for them first and then set the appropriate exits. I know that the mapper api isn't documented at the moment and you have to rely on demo scripts. Have a look at my little Aardwolf demo. This works on the above principle i.e. you see an exit to north -> create a new room object and then set the respective exits. If you find out that this room exited before you change its id and update its exits appropriately. Deleting rooms isn't supported by now, but as soon as it is, you can simply delete all rooms without exits. That's no big problem.

To delete an exit set its id to 0. This will remove the exit. Room ID 0 is reserved for this purpose.
This all is good, if i map 1 room and then all rooms near it at a time. But perhaps i want to walk along some specific path in area, which i know is safe. Then after that (maybe on next day) i want to map further. But when i return to this area, there is a problem, i cannot see any exits that i did not map yet, that means i have to move along each room and check if i didn't map anyting. Yeah, the problem is not big, i can do that, but i'm just suggesting, nothing more

User avatar
Omit
Posts: 190
Joined: Sun Aug 01, 2010 10:54 pm
Location: Middle Earth
Contact:

Re: Feature Request(s)

Post by Omit »

The scripting I have been working on maps the adjacent rooms as well as the one I am in (marking them in a different color so I know I have not visited them) and then update them when I do enter them. this way they can be saved and seen when restored. (still working through some of the problems that mapping this way causes)

mudlettest
Posts: 9
Joined: Tue Nov 02, 2010 12:34 pm

Re: Feature Request(s)

Post by mudlettest »

Yep, this was one of possibilities i was thinking about. But now i'm waiting for delete functions and such :)

User avatar
Omit
Posts: 190
Joined: Sun Aug 01, 2010 10:54 pm
Location: Middle Earth
Contact:

Re: Feature Request(s)

Post by Omit »

...and I am waiting on the function for telling me if a room exists at a location and the ability to add "non-standard" exits... mapper does me little good without them :( (I have played around with my own data structures to store/track/return this info but is too inefficient to use with this mapper.)

mudlettest
Posts: 9
Joined: Tue Nov 02, 2010 12:34 pm

Re: Feature Request(s)

Post by mudlettest »

Yeah, those are obviously must have :)

User avatar
Omit
Posts: 190
Joined: Sun Aug 01, 2010 10:54 pm
Location: Middle Earth
Contact:

Re: Feature Request(s)

Post by Omit »

REQUESTS:
* getroomColor(rID) -- I am storing the room colors in a database as there is no access to the value after you set it.

* additional fields associated with each room (I need one for the ascii char from the muds ascii map... but 3-4 generic fields may be best. To be used however a user sees fit) setUserValue(Rid,x)/getUserValue(Rid,x) where Rid is the room and x is value between 1-4

User avatar
Vadi
Posts: 4901
Joined: Sat Mar 14, 2009 3:13 pm

Re: Feature Request(s)

Post by Vadi »

I'm wary of the 'additional fields' idea. No need to reinvent the wheel, lets use Lua here. How about a special Lua table that gets saved into the map data? So you can store anything you want in it (including the fields for rooms and etc) but you wouldn't need to worry about saving it or transferring when you share the map.

User avatar
Omit
Posts: 190
Joined: Sun Aug 01, 2010 10:54 pm
Location: Middle Earth
Contact:

Re: Feature Request(s)

Post by Omit »

A special table would be fine to....
My thought is that: there needs to be a way to store any additional info with the map (at least for non-ire muds where it's not supplied)
I am capable of running a separate system to keep track of what I need but it introduces additional problems. If this kind of stuff can be handled by the mapper.... it will make the whole thing a lot cleaner.
(only hesitation with using a Lua table is that it does have limits.... I have reached them before.... with about 3/4's of the mud I play mapped.... I worked around the limit by swapping out tables when the area changes.... only one area loaded at a time.)

EDIT: thinking on this... a single variable to be stored with the room that may be either a text string or a lua table...
should be minimal to setup... would not be subject by the limits of a lua table (unless you are crazy enough to store that much data with a single room)

(Simplicity is Beautiful)
Omit
Last edited by Omit on Sun Dec 19, 2010 7:03 am, edited 1 time in total.

User avatar
Omit
Posts: 190
Joined: Sun Aug 01, 2010 10:54 pm
Location: Middle Earth
Contact:

Re: Feature Request(s)

Post by Omit »

Suggestion:
* remove all reference to exits/room connectors in the map when grid mode is set to true. For large LP muds I think this would increase performance of rendering large wilderness areas and the connections are not shown anyway (except in rare instances).

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Feature Request(s)

Post by Heiko »

0. Other exits will be added today.
1. I'll add a user data field in form of a string list. That's not optimal, but less work for me than setting up a user table. This should be enough.
2. getRoomColor() will be added
3. We can't reasonably use the 3D mapper with grids of 1000*1000 or larger which is common for grid maps. 3D view is basically useless for grid maps as those are explicitly designed for 2D views and usually have next to zero z-axis variations except a handful of isolated buildings. My approach has been to show areas that are based on grid maps in a proper 2D view and use the 3D view for dungeons or areas where a 3D view actually makes sense.
4. A user drawing canvas with a minimal drawing API would be another solution.

Post Reply