TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

Question on Mapping

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
LokiChaos



Joined: 27 Oct 2009
Posts: 61

PostPosted: Sat Jun 01, 2013 3:16 am    Post subject: Question on Mapping Reply with quote

Hi, currently I've been doing per-zone maps, each saved to their own file. However there is a bit of lag when changing zones and tintin saves the map for the left zone and loads the map for the new zone.

I recall reading that it is intended you only have one big map, but I'm more than a little concerned about tintin++ handling a map of such a size.

The MUD I play has over 175 areas (actually I think it's closer to 200 at this point) with anywhere from 10 to 1500 rooms each. On top of this there are 4 distinct "wilds" regions (the largest being 1500x2400 rooms, two more smaller but still close to that size, and a fourth smallest being abut 490x380 or so). So in total there are easily 6+million rooms, highest vnum's via GMCP I get at in the 9M range lowest seems to be 10k, I believe they are unique, but I've only started mapping recently.

How well will tintin cope with this? What memory implications would there be to hold such a dataset? I'm not really interested in mapping the wilds (cuts the map down to only about 30k rooms based on some estimates), aside from replacing my current pathfinding system that uses a C helper to handle which speedwalks to load to walk between various cities (I have a table of pre-defined paths for walking along roads, the pathfinder just makes a list of which paths you need to do to get between arbitrary points on the road network).
Back to top
View user's profile Send private message
mrbigtaco



Joined: 26 Jun 2011
Posts: 54

PostPosted: Thu Jun 06, 2013 4:28 pm    Post subject: Reply with quote

I currently use it as one big map and it's around 40k rooms in the map. The main problem is just trying to avoid overwriting/corrupting your map- I handled that through external scripts to do checksums and git commits upon changes... initially it was tarball archiving for versioning but the storage footprint became too large.

As far as performance for pathing- I've seen no degradation in performance as the map has grown to its current size over the course of a year, finding paths happens almost instantaneously. Like you mentioned, the main performance hits are read/writes for disk IO. The machine that I run this on is pretty modest- a dual core atom 1.7ghz with 2 gb of ram and 1 gb swap (it's a mythtv media server also as the primary role). Performance has always been acceptable (except in the version of tt++ where #map run rendered the map's highlighted path and forced that portion of the output to be process prior to receiving the output from the mud... I believe that was fixed in the 2.00.9 though).

I can't really speak to cases of 6-9M+ rooms, but at least with 40k rooms it's no noticeable performance loss. I imagine it would scale similarly and your main performance cost will always be disk IO.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Sat Jun 08, 2013 5:16 pm    Post subject: Reply with quote

I never really tested the mapper with 9 million vnums. It's going to cost you about 36 MB of memory to allocate a map that size. You would most definitely have to map as little of the actual wilderness as possible.

I did optimize tintin at one point to work with large maps, but if things become sluggish you can always send me your map file and some examples of commands that are slow.

But if you have a map of 9 million vnums, and about 100,000 rooms created you should be alright.
Back to top
View user's profile Send private message Send e-mail
Slysven



Joined: 10 Apr 2011
Posts: 365
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK

PostPosted: Mon Jun 10, 2013 11:04 am    Post subject: Reply with quote

Mind you if you have vnumbs in the millions you might want to avoid setting #MAP FLAG ASCIIVNUMS - if I recall correctly there is only space to display 5 digits of the room number. I have played around with map displays and one attempt to increase that range was to replace just the most significant digit with A-Z then a-z to enable displays in 5 'digits' of 00,001 to z9,999 (=719,999). Perhaps there might be scope for an option to switch to purely Hexadecimal room numbers to help those with really HUGE maps...?
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Sat Aug 10, 2013 12:04 pm    Post subject: Reply with quote

I could add a toggle for base 10, base 16, or base 64.
Back to top
View user's profile Send private message Send e-mail
atraeyu



Joined: 12 Dec 2007
Posts: 165

PostPosted: Wed Feb 12, 2014 4:07 pm    Post subject: Reply with quote

mrbigtaco wrote:
I currently use it as one big map and it's around 40k rooms in the map. The main problem is just trying to avoid overwriting/corrupting your map- I handled that through external scripts to do checksums and git commits upon changes... initially it was tarball archiving for versioning but the storage footprint became too large.

As far as performance for pathing- I've seen no degradation in performance as the map has grown to its current size over the course of a year, finding paths happens almost instantaneously. Like you mentioned, the main performance hits are read/writes for disk IO. The machine that I run this on is pretty modest- a dual core atom 1.7ghz with 2 gb of ram and 1 gb swap (it's a mythtv media server also as the primary role). Performance has always been acceptable (except in the version of tt++ where #map run rendered the map's highlighted path and forced that portion of the output to be process prior to receiving the output from the mud... I believe that was fixed in the 2.00.9 though).

I can't really speak to cases of 6-9M+ rooms, but at least with 40k rooms it's no noticeable performance loss. I imagine it would scale similarly and your main performance cost will always be disk IO.


Any chance you have some of that code laying around that you could share? Smile
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> General Discussion All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group