Zugg Software :: View topic

Posted: Mon Jun 02, 2008 3:28 am

With the work about to begin on the new mapper, I thought I'd throw in my 2 cents for what I'd really like to see:

** Additional 'Other' exits

Right now if you have a non-standard exit you can either use the 'Other' exit and put in the command or you can hijack another direction which isn't being used. This is hard when you have multiple non-standard exits and most of your other exits are being used.

I'd like to see additional 'other' exits added.

Ideally this could be configured:

- Define non-standard exits like you can now, but instead of only having 1 'other' to choose from, have multiple placement graphics to choose from. This way you can define 'in' and 'out' and any other weird exits you happen to have without running out of 'other' non-standard exits.

- Have the defined non-standard exits from above show up in the Exits tab of the room.

** Undo function

It's really painful to do something unintentional to the map and have to figure out what it was and undo it.

** Better checking for erroneous double exit definitions. This happens when you are editing a room's links, you can sometimes end up with multiple exit links 'north' but only one of them goes anywhere. This seems to happen unintentionally quite a bit and it would be nice if this was handled better by perhaps alerting the user or automatically fixing the issue.

** Better integration of non-standard exits - As it sits now with Cmud I can't get it to automatically create rooms for non-standard exits like it did in Zmud. Standard exits work great, but non-standard exits require that I fully manually create all the non-standard exits and link them up. Please integrate the non-standard exits in a way so that they don't require extra work to do when creating maps. They are completely broken on Cmud and they were always a pain on Zmud, always requiring extra code to do the odd bits that Zmud decided not to do for non-standard exits.

** More control over the speedwalking queue - There exist functions such as %nextdir, %inwalk, and %destroom, but I've only had limited success in getting them to work correctly. The function %inwalk didn't seem to accurately indicate when I was in the middle of a speedwalk at all when I tried to use it.

Could we have read and write access to this queue? I'd love to be able to access it directly to chop off or add a direction from the queue as needed. I could also process it to obtain a myriad of other data and information I might want, all without you needing to create a function for each thing.

** Auto-Centering of map when browsing. If you look at your maps off-line and click on a random zone the map window most likely will display nothing because it's off in a corner of the map, I often have to spend a lot of time trying to locate where the map is and center the map manually. This isn't an issue when moving around because there is an auto-center feature you can you already, but this is an issue when you aren't actually moving around and you want to browse your maps.

** More fields for data in the rooms. Descriptions and Notes fields are currently doing double and triple duty on my map as I try to find a place to cram all the data I want to store about a room. I currently concatenate all my data with '|' and then de-concatenate them when I need to access the data. It's all very tedious, and a few more fields would be very welcome.

** More friendly for maps that are up to 5 digits in the unique room 'id' - The fields were not sized to look at numbers this large and I have to manually enlarge the fields in the exit tab every time if I want to see the complete number. Also, perhaps there could be a way to click on items in the map and have their unique 'id' captured for use so I don't have to look at the 'id' then hurry and type it in before I forget it.

** Ability to show the short 'id' names on the map. I use these all the time for tagging rooms for getting around fast and it would be nice if these could be displayed on the map. Currently the only way I can see these once I put them in is to right click the room and go to the 'Other' tab. Right now I either have to memorize them or I have to manually add text on the map to I recall the short id name.

** Fix the issue where the longest (character wise) direction object's Value field is used when speed walking. I've added in multiple items apart from "s|south" which was standard. I have "leap s|swim s|s|south" and now I have to do this "leap s|swim s|s|south|s " so that it uses "s ", instead of "leap s", because otherwise "leap s" would be the longest and the one it would use for speedwalking.

Posted: Mon Jun 02, 2008 5:01 pm

I would love to be able to be able to programmatically defined a new Room Type via the api. This particular lack feature lack is preventing me from creating a complete automap generator from imap data. (A project though well delayed, I hope to finish at some point.)

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Posted: Mon Jun 02, 2008 10:43 pm

Btw, I guess I'm not exactly sure what bug with non-standard exits you are referring to. Maybe you can bump another thread with this problem report, or add a new topic to this forum describing the problem. When I need to create a non-standard exit on the MUD that I play, I use the normal syntax with > as the mapper character. For example, if I want to create a new room to the north of my current room with the non-standard direction of "enter", then I type this:

Posted: Tue Jun 03, 2008 12:15 am

Posted: Tue Jun 03, 2008 12:26 am

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

You CAN create more non-standard exits than the solitary OTHER.

Each link has only two directions.
So if you want another OTHER exit in the room you need to create another link.
If you didn't do it this way you would have something like this -< which wouldn't work very well at all.

Do you mean that you want other types of visual cues so if you have three other links you can actually visually tell?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I think I would like to see some display options for other type exits. I have encountered more then a few rooms that used all 10 standard directions and had 2+ other type exits. It is nice to be able to visulally recognize them.

I also definitely want some thing that has never been automatic before. I want the automapper to create stubs for such exits with the only things required by the user being #DIRECTION settings and configuring the mapper. The mapper is already setup to put all commands sent to mud into the queue when in map mode. It just has no idea what to do with them without a stub. Getting the stubs created automatically makes a huge difference.

Taking it a step further is notifying the user of a possible unknown exit name being found in the exits line, and offerring a solution. This should have some means to mark future occurences to be ignored.

While we are talking about exits how about door detection. Many muds provide some sort of door information in the exit line now. It would be nice if the mapper was able to take advantage of that information. The current script requirement to capture and parse exit information for doors is dauntingly complex to many users, and blantantly redundant to everyone using the mapper.

Posted: Tue Jun 03, 2008 3:15 am

Posted: Tue Jun 03, 2008 3:18 am

Vijilante correctly stated what I was trying and perhaps failed to state. I created the stubs myself for non-standard exits in Zmud so that when I took the exit it would link properly. In Cmud I can't create the stubs. If this could be done automatically like the standard exits, that'd be fantastic.

I did code for myself the checking of exits on the mapper vs. what I see, but it'd be great if that was done automatically.

Posted: Mon Jun 09, 2008 8:28 am

Another item occurred to me that I left off the original list:

- Make entered movements into a queue. This is a hard one to describe. When I type 'e' to go east, Cmud then either triggers for the room name or awaits an '#OK' to be executed saying that the room change was successful. One issue I have is if I sent multiple movement commands at once such as this situation:

I type 'e'
Then it occurs to me that there is no 'e' direction and that I really wanted to go 's' so I type 's' very shortly after I type 'e'.
The Mud sends "There is no direction east" and I trigger off that a "#NODIR" which causes Cmud to stop looking for the "#OK".
Now the second thing I entered "s" goes through and I change rooms.
However Cmud is no longer looking for the "#OK" so the map doesn't update that I indeed went to the south.

So it would be wonderful if Cmud could queue the directions entered and apply the "#OK" or "#NODIR" to only the direction at the top of the queue.

So with the modified functionality it would do this:

- Enter 'e' then 's' at nearly the same time. It queues up "e|s".
- The '#NODIR' applied to the first item 'e' of the queue.
- Then the correct movement goes through and applies to the remaining item "s" in the queue.

Posted: Mon Jun 09, 2008 5:02 pm

Actually, the mapper already has a queue that works like this. It even shows the direction at the top of the queue in the lower-right part of the status bar for the mapper window. So it is already supposed to be working like you suggest, and it sounds like there is a bug in the current implementation in some cases.

Posted: Mon Jun 09, 2008 11:16 pm

Perhaps it is just an issue with #nodir. I see it working properly if I don't use #nodir to flag a move failure.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Might I suggest that we get a "variables" table which we can store as much or as little data as we want on a per room or per zone basis... this would let us have unlimited (theoretically) user variables to tag a room with... add a new %roomvar() or similar to let us query / add / remove from scripts. This way we can custom tailor it to our specific use.

I'll let you pick the appropriate # and % functions, but I was thinking:

#ADDROOMVAR <room#>, <variable>, <value> - adds the variable to the specified room if it doesn't already exist, otherwise just update the value
#DELROOMVAR <room#>, <variable> - removes the variable from the specified room
%roomvar( <room#>, <variable> ) - returns the <value> of the variable on the specified room
%roomvarexists( <room#>, <variable> ) - returns true/false if the variable exists for the specified room
%currentroom - might already exist? returns the room # for the current room, so we can do a %roomvar(%currentroom, "MyVariable")

Perhaps load the variables to a cache if we start querying them in a script/have the variables window open, but don't bother loading them into memory on every step in a speedwalk.

Posted: Tue Jun 10, 2008 1:00 am

Normally room functions' first argument is optional, defaulting to the current room. So %roomvar(,"MyVariable") would do what you're after.

An excellent suggestion.

Posted: Tue Jun 10, 2008 4:46 am

Just as a preview, what I intend to do is expand the current "Room Script" entry into a full XML "settings" format. This will let you store all sorts of things for each room, including variables. Basically, I'm taking the single string (text) database field and making it into an XML field so that more data can be stored there, without actually adding any additional fields to the database itself.

I'll think about your syntax suggestions, but I'm actually trying to avoid adding a lot more commands and functions unless really necessary. One thing that I'm considering is having a "room" work like a class, with the "Mapper" as a type of module/window. That would allow you to use the existing @//Mapper/RoomName/Varname syntax. The advantage of this kind of method is then you can use room variables just as if they were normal variables rather than needing to define a bunch of duplicate commands/functions.

Anyway, just an idea...nothing set in stone yet. But the current method of putting room-specific settings stuff in "System/_TempMap" isn't very good, and the overhead of creating and then deleting these settings slows things down. With "Rooms as Classes", the classes just get enabled/disabled, but the variables would still be accessible via the above syntax. Any triggers, buttons, macros, etc in the room would get disabled with the "room class" was disabled, rather than physically deleted like they are now in the "_TempMap" class.

The same idea would hold for zones, and the structure would also allow map-global settings. The other tricks would involve allowing the use of room numbers in place of the room name.

Posted: Tue Jun 10, 2008 4:58 am

Any chance we can have a way to access the database directly using whichever client/language you're using (mssql/mysql/whateversql) so we can play and tweak on a deeper level? If we screw up, who's fault's that ;)

Posted: Tue Jun 10, 2008 5:18 am

Zugg, that sounds very nice. I'm already thinking of various things I could store using it.

Thanks for the preview.

Posted: Tue Jun 10, 2008 10:26 am

Room name often isn't unique, so using the mapper's vnum would probably be a better bet. But ace nevertheless :D

And yes, it'd take an awful lot of legwork out of things like Vijilante's map queries if we could just query the map db ourselves with some function.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Posted: Tue Jun 10, 2008 9:31 pm

I'd assume that even if there's no way to edit these things through the package editor, it'd still be possible to create settings in the editor, cut them, and paste the XML into the room's field.

Posted: Tue Jun 10, 2008 10:28 pm

The idea would be that the "Mapper" would look like a separate package tab in the settings editor and you'd be able to manipulate mapper settings just like normal settings. That's the idea. We'll see what happens when I get to that part of the implementation ;) Certainly not in Phase 1 though.

alluran: The mapper database will be stored in SQLite 3.0 format. There are plenty of free tools for examining these databases. The eventual database module rewrite in CMUD will add real SQL database commands for SQLite which could also be used.

However, I should warn you that the mapper database format is pretty complex and it's *very* easy to completely screw it up if you mess with the tables themselves. The actual table/field structure will be the same as the existing MS ADO/MDAC *.MDB mapper files. So you can already manipulate them with lots of database tools (it's the same format as MS Access 2000 database files).

Posted: Tue Jun 10, 2008 10:31 pm

Btw, on the request for a zone "thumbnail", I'm not sure that will be possible. The purpose of the "zone" was to keep most of the map out of memory so that it only needed to store and draw the rooms/links in the current zone. Drawing a zone as a "thumbnail" would mean having the entire map database cached. Maybe now that computers have more memory this won't be a big deal anymore, but I'm afraid I can't promise anything like that right now.

Rescaling a set of rooms within the current zone is much more likely.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

So long as it doesn't add insane load overheads when walking from room to room, having an entire package for each room sounds neat. When will the XML parsing be done - when you first open the map? When you first enter the room? When you step into the zone? If a zone has 10,000 rooms will parsing 10,000 XML fields take a good 30 seconds?

Can you not just cache a .png of the zone in a blobfield of the database and only update it when exiting from "edit" mode. I never had use for zones anyway, but just a thought.

PS Alluran: You can already query the mapper database using ADO via zScipt, maybe SQLite has ADO drivers? I recommend read-only use if you do want to query it. I wrote a tutorial about accessing databases via ADO in the finished scripts forum.

Posted: Tue Jun 10, 2008 11:56 pm

And Viji's toolbox, which I mentioned before, is in the library and has loads of functions that help with querying the mapper over ADO and does more and crazier stuff besides.

Even people who have a computer from the Stone Age (ie, the turn of the century ;) should have no problem with ram - I picked up 4GB for £30 or so a few weeks ago. I guess my point is that the mapper can use a bit more memory if it needs to.