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

User Data store for areas and for whole map?

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Feature Requests
View previous topic :: View next topic  
Author Message
Slysven



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

PostPosted: Sat Oct 31, 2015 10:53 pm    Post subject: User Data store for areas and for whole map? Reply with quote

Whilst coding another MUD client I came to the conclusion that there is merit in having the ability to store data items for both: each area (once there is some significance to them) and for the map as a whole in the same manner as is offered for each room with the
#map {set} {roomdata} {<value>|${<variable>}} [vnum]
#map {get} {roomdata} {<variable>} [vnum]

So we could have:
#map {set} {areadata} {<value>|${<variable>}} [area]
#map {get} {areasata} {<variable>} [area]
#map {set} {data} {<value>|${<variable>}}
#map {get} {data} {<variable>}

Where area is a used area value (though it is presently a string NOT specifically a number), and if not given the value of the current map room's area is used (which can be the empty string). The main advantage of having both is that the data can be apportioned to the relevant thing. E.g. if the map is used for more than one character being played in a Mud the data for the MAP can record which room each character was last in and when or the details of the last edit, whereas the AREA data could signal a default background music file to be played or some data that is the same for lots of rooms (in the same area) without having to put the data into each room individually.

This is not to say that this data could not be kept within a data structure within a file read/written separately but that some data is more appropriately stored with the map rather than the session.

Ah, jumping between clients has caused me to forget the current low significance of room areas on the TinTin++ client.

Anyhow thoughts anyone?
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Sun Aug 21, 2016 8:45 pm    Post subject: Reply with quote

Not a bad idea.

TinTin++ has no areas however. So I'd have to add the ability to create, delete, and update areas.

Would be easier for a user to create a variable for this kind of information, and they could access them directly using $ rather than having to retrieve them each time.
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: Thu Sep 01, 2016 8:50 pm    Post subject: Reply with quote

Welcome back, Scandum! Ecstatic

Scandum wrote:
TinTin++ has no areas however. So I'd have to add the ability to create, delete, and update areas.

Would be easier for a user to create a variable for this kind of information, and they could access them directly using $ rather than having to retrieve them each time.
In a curious reverse symmetry the MUD client I am devoting most of my effort to does not explicitly store room descriptions {they have to be stored in the general room "data" structure} though it does have those Area thingies!

On the other-hand it does not have TinTin++'s "dynamic" mapper - where the relative location of the rooms around the player are determined by their connectivity to the room the player is in at the time. So separating (fixed placement) rooms that would otherwise overlap by placing them in different areas is an alternative way of resolving it. It also uses the A* algorithm for route finding - which, although it may be faster than the Dijkstra's which I think TinTin++ uses does work best when the physical coordinates assigned to each room accurately reflect their positioning within 3-dimensions rather than drawing convenience - and I don't think it works properly with cross-area searches as the areas can easily have different coordinate origins/systems...!

I have managed to port my "Description" indexing system to it - taking care to get the same hash values from the same room description texts as the one I posted here a while back. I live in hope of getting a user of a TinTin++ client to share real-time player location data with a user of the other client despite having different mapping system. Mind-you I still need to implement a MMCP peer for that client (and rewrite TinTin++'s one to have a "happy-eyeballs" approach to using a dual-stack IPv4 & v6 system, unless you've already done that Scandum?!) Smirk
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Thu Sep 01, 2016 10:31 pm    Post subject: Reply with quote

Never got around to IPv6 for chat.

TinTin++ uses Dijkstra, with some optimizations. It performs 20 searches for a path that takes 20 moves, but after the first search it won't search away from the target, so probably more so resembles A*
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Feature Requests 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