Zugg Software :: View topic

Apprentice Joined: 18 Jan 2001 Posts: 116 Location: USA

I play on a mud where there are additional fields in the mud file besides what the mapper currently tracks. An example is extra descriptions. They work like exits... there may be 0 or more of them in any given room, and each is comprised of a keyword list and a description.

I'm hoping there is, or could be, a way to add this to mapper. Maybe add a form where additional fields can be populated, and let the user configure the mapper by telling it what table/fields it would like to edit. The mapper could then query the db to determine the type of field that is, and display an appropriate input field for it on the form? I guess there would also have to be a way to duplicate the inputs for things like exits that have an unknown number of records.

This brings up a more general question... will it cause problems in zmapper if fields are added to existing tables or completely new tables are added to the db? If it doesn't work out to let users configure the mapper to populate new fields... at least maybe we could use access forms to add the additional data after the map has been created.

The reason this would be nice is then you could import real mud files into the mapper without losing data... edit the room descriptions or exits or whatever... and then export it again, retaining all the extra fields that were in the original mud file. Even if this importing/exporting had to be done with separate scripts, it would still allow users to take advantage of the map creation ability of zmapper to expand existing mud files.

Thanks,
Eupher

Posted: Thu Sep 12, 2002 6:33 pm

I don't see that there would be any problem adding new tables or fields to the current database. As long as the fields used by zMUD weren't changed, I don't think the database code cares.

There is already a "UserStr" string field and "UserInt" integer field assigned to each room. The use of these fields are completely up to the user. The advantage of using these fields is that they are already accessible via the zMapper COM scripting.

I doubt I'd add anything to zMUD to automatically parse these kinds of fields, since they'd be totally different on every MUD.