theBuilder
Newbie
Joined: 27 Sep 2005
Posts: 2
|
 Posted: Wed Sep 28, 2005 7:47 am
zMud 7.20b - Mapping
|
Hi,
The latest version of zMud 7.20b is looking sleeker, faster and more robust. The mapper component appears to be working well and doesn't appear to need a chunk of time writing triggers to do the basics - like simple room detection.
I'm am however still seeing problems with autolinking rooms.
Generally I map in two configrations:
The first is on a mud where I'm a builder and here I get to see the vnum of the room in the title - which is always unique across the entire mud.
An example of such output is:
| Quote: |
Housing Area (#xxxxx) [ Inside INDOORS TRACK ] [ (N) (E) S W ]
|
Setting up a trigger to set the tags works - and a quick reconfigure and the mapper works well, a little sluggish but easy to live with if the map is accurate.
The problems start when it comes to linking rooms.
First I start to move around a zone - and rooms are created.
A minor annoyance is manually adjusting the spacing between the rooms to make the map clearer. It would be good if rooms started to overlap on the same level - the map either auto-respaced - or there was an option to respace selected/everything.
Now it appears, unless rooms are directly adjacent, when the mapper enters room it ignores the detected vnum and creates a new room - even if the vnum exits in the database.
This creates a nightmare situation where, when you start reaching 20+ rooms that you have to either remember if you've been to a room (hard when you have identical room names and sequential vnums) or start searching the map for the vnum.
The second configuration I work is a player:
Here, when mapping, I leave a waymark in a unique vNum in the room and move to the next room. I detect the waymark in the room and tell the mapper to use this as the vnum. The waymarks can't be deleated and persist for long enough for me to map a zone. This suffers from the same problem as above - the mapper doesn't check for an existing room with same vnum when deciding to create a room or build a link between 2 rooms.
I believe the mapper, if configured to parse the vnum in the mapper configuration, should check for the existance of a room with that vnum in the database before creating a room. If a room with the vnum exists don't create a new room (it's gonna be the same room) - work out how the rooms are linked.
Now I know this isn't as easy as it sounds - builders can be devious (or just stupid) - with looped rooms or just a bad linking means it's sometimes hard to work out. So the suggestion I have is for the creation of some new events/aliases - which can be tied into the mapper.
The new events/aliases would be:
| Quote: |
mapperOnRoomEnter
Executed after before triggers have fired and before the any output has been parsed from the mud.
mapperOnParseRoomName
mapperOnParseRoomVNum
mapperOnParseRoomFlags
mapperOnParseRoomExits
mapperOnParseRoomDescription
Executed before the room is created, after output has been parsed, and once the mapper thinks it is ready to create the room - the appropriate tag field is populated and can be used/changed by the alias.
For tags such as exits and flags - it would good to provide the information as a collection of attributes. This would allow the changing of an exit into a one way path or a door (an example from the above snippet of a door - (N) ).
mapperBeforeRoomCreate
Executed before the room is created, after output has been parsed, and once the mapper thinks it is ready to create the room - the appropriate tag fields are populated and can be used/changed by the alias. In addition it might be a good idea to pass the DB room record which can be used/changed by the alias.
mapperAfterRoomCreate
Excuted after the room is created and passes in the DB room record that has been created which also contains a collection of DB room records that this room links to. This would also allow the setting of roomflags which when set as part of mapping triggers - appear to fire before the room is created - and hence affect the prevoius room. |
Some of these may appear superflous to requirements - but it would allow tweaking/modification of each element at the appropriate part of the room creation process for almost all muds.
Another area that could do with a little tweaking is zones.
The muds that I play on are generally divided into Continents, Areas and Zones (I know some muds might not have this breakdown). As a builder or a user I can work out where I am but the mapper doesn't allow me, using script, to create a zone. It would be good if I was able to do this at some stage in the room creation process - without having to pre-populate the zones in the mapper. I've been looking recently into stuffing it into the database with #NEW - but it feels like a kludge when there's a mapper that should allow me to do achieve what I want - without having to work out what the fields in the database are.
While I can understand that implementing continents and areas, because it might not be used in many muds, would be overkill. It howvere would be good to allow nested zones.
Now I may have missed some whizzy way of doing the above - in which case - cool - always happy to learn.
Kind regards,
theBuilder |
|
