Feature Request(s)

[Vadi]

I'm not aware of the Lua limitations you speak. Perhaps you need a better design?

[Heiko]

Lua limitations? What are you talking about? Wrong thread?

[Omit]

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.

Ok, if I understand the the limit correctly... it's not really a limit on the Lua Table but on the stack. I Lua table can be any size but.... there is a point where it cannot be easily saved and restored. (when it happens.... Lua will just fail to restore it and the data will corrupt..... limit is somewhere around 2^18 or 262144)

Oh... and yeah... after I reached the limit I had to rewrite and make my tables more efficient(had it happen with my first mapper I had made for mushclient)

[Omit]

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.

I agree, I am planning use the setGridMode( Area, true ) in order to render my grid maps.... problem is.... all the exits for the rooms are still being drawn (even if they can't be seen). This being the case, the only difference in using the two views, is the way they display. (no advantage for performance) My experience tells me that if the map would not draw the exits when in gridmode, it should increase the performance exponentially and even grid areas of 1000x1000+ would be no problem. (maybe even force grid mode to only show one z axis, although this would be very minor compared to the exits)

(additional note: I have all ready mapped a grid area of almost 1000x1000 and the mapping and scripting can handle it just fine, it even renders fine... it just refreshes very very slow.)

[Heiko]

For large grids it definitely refreshes way too slowly and thus costs general processor time in Mudlet. This is why I'll replace the underlying 3D pseudo 2D view with a real 2D view for usage in grid maps.

Vadi plays MUDs with less than 20.000 rooms if I remember correctly - and those are spread over tons of different areas. Lua backbones are no problem for these "small" MUDs, but large LD MUDs can have up to 100 million rooms in a single area (and several of these large areas) and this is the reason why we have a c++ backbone to do the heavy duty work.

[Vadi]

So your issue is the basic table.save / table.load that's not designed for such heavy usage - easily solved by using a proper serialization libraary (pluto comes to mind).

It's not a "Lua limitation" at all.

That, and MUDs I play have 5million+ rooms - but the simple fact is that you don't have to use the wilderness to get about, it's optional.

[Heiko]

Those 5 million+ additional grid maps rooms in your MUD are not known to the mapper and thus have no room in our discussion. You are free to add them to the map and write a path finding script in Lua and compare the results with the current C++ implementation. Then you'll see why Lua isn't the right tool for this kind of work.

[Vadi]

Sorry, the current C++ is too slow already in pathfinding, adding more rooms to it would make it crawl :/

[Heiko]

According to the data that I have gathered It's definitely fast enough for small room based MUDs (rbms) and most likely also for large grid maps because grid maps are positionally laid out correctly as opposed to rbms and thus the advantages of the A* path finding algorithm can come into play which isn't the case for rbms. However, pathfinding is definitely speed relevant - especially as the overall speed will decrease considerably with the next update when single direction exits get activated with the introduction of user defined special exits. The A* algorithm is the fastest one available for our purposes.
In any case, the whole debate is about adding dynamic custom user data to the map structure. It's convenient and definitely a must have for grid based maps which make up about 50% of the big MUDs as far as I know and is thus an important design criterion for the mapper. I agree that this could be left out if we add a capable cross platform Lua serialization library, but I don't know if such a thing exits i.e. that the serialized data is truely portable as is the case with our current binary map format. In any case it would be yet another library (and thus considerable work especially for ixokai's mac release and most likely also for the windows release), but the major drawback that I see is that it makes maps less portable and thus more difficult to share. As far as the costs are concerned, it doesn't make much difference because it's dynamic data.

PS: I try to get out the next release before Christmas.

[Sidd]

A feature I'd like to see is changing how the map displays what room you are currently in, it currently highlights the room red, but I have a hard time seeing this, being able to adjust that color, or add like a '+' or something signifying you are in that room would be incredibly useful. Thanks!