Zugg Software :: View topic

Posted: Mon Apr 28, 2008 7:29 pm

In my New Year's letter I talked about our plans for this year. After the CMUD 2.23 Public version I was going to work on the MyMuds project. But more and more I find myself answering posts and emails with:

Posted: Mon Apr 28, 2008 8:33 pm

Firstly - though I wrote this sentence last - a disclaimer: I wrote this as a bit of a stream of consciousness, and haven't thought very deeply about it; these are just things that occurred to me as I was writing. Anyway:

There are two things that people want out of CMUD that they're not currently getting, in my experience: the mapper to work properly, and stability. Since the MyMuds project is based on CMUD, I think it's important that CMUD delivers before you start building new technology on that foundation. I wasn't involved in the zMUD community here like I am in the CMUD community now, so I don't really have anything to compare CMUD against; I guess that leaves you to decide whether or not you think CMUD is at a point where it's ready to build these extra things on top.

Fundamentally, though, I think it's a question of which audience you'd rather appeal to. Fixing bugs in CMUD will presumably continue while the mapper is rewritten, so these changes will appeal to people who currently use CMUD (some of whom will need to renew their licenses towards the end of the year), people who've tried CMUD but were turned off, and people who use or used zMUD but haven't tried CMUD. These people are likely to be strongly influenced by a new mapper and by further bugfixes.

On the other hand, MyMuds is appealing to a much more murky group. The impression I've got is that it's highly focused on MUD admins, who'll be able to use the site both to advertise and to provide a free, high-quality client to their users. I think they'll be highly influenced by the quality of the client and of the technology used in the website, so it's important to present a polished product. Because of this, I think the mapper will be a very good draw to these people. Secondly, MyMuds will appeal to people who can't afford the lump sum for CMUD; this group will likely be happy with the MyMuds client as it would stand, but is this group terribly large? Finally, it'll appeal to people who want to use CMUD on computers that they don't own and while moving (via a USB key or something). Again, is this group very big?

I call this group murky because there's a fundamental question that's still unanswered: are they willing to pay for the product? The former group doesn't have this problem; they've all expressed interest in the product or a similar product in the past, and many of them have paid for it (some of the CMUD trial users may not've been zMUD users). That they're willing to pay for the product is given; it's the quality that keeps them away. I know you did some research into levels of interest in MyMuds, so I guess you have a more concrete idea of the answer to this.

As for my personal opinion, I think I put it best here:

Posted: Mon Apr 28, 2008 8:41 pm

I think you're right in saying that the mapper would be the majority vote. But then the question goes towards why? Part of that answer is because the mapper plays such an integral part in any MUDding experience. While MUDs may have an ASCII map in-game, it's not normaily pleasing to the eye. Not to mention that you can't just run a query to find a room and walk to it MUDside.

I know the conversion to SQL will be something most, if not all, will be looking forward to. Faster map searches? Lovely! Being able to change the map background color will be nice, too. I know a few MUDders who like to have black map backgrounds, myself included. But in all honesty, I'm not sure what all can be added to the mapper, or what could be changed. Perhaps another will be able to provide even more insight to this.

As for MyMuds, I was eagerly anticipating this when my computer wasn't working and I had no other way to MUD except by USB drive on my mother-in-law's computer. I'm not so eager about it anymore. While it is a great project, I don't find myself using it as much. But then again, I can't MUD from work anyway. And while MyMuds may bring in some revenue, it probably will not generate as much as a debugged Mapper and CMUD in general. Talking to people who play on Aardwolf, several times I hear them say they won't switch to or pay for CMUD until the bugs have been ironed out or until they can use the mapper without issues. So, in my opinion, I think the mapper would be a better way to go.

Charneus

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

Yes, I'm biased towards thinking that you should rewrite the mapper first. And oddly enough I don't have that many problems with it myself.

Two things as far as improvements come to mind that are probably already on your list anyway.

1. Improve the scripting by doing away with that pesky system folder that the mapper is always writing to.
Perhaps by making the mapper contain its own package file within it for scripts

2. Finish implementing the docking stuff with the mapper window so it doesn't get confused about the focus.

These are really the only things that come immediately to mind. Mostly because they have caused several replies from us in the forums of,
"Sorry that won't be fixed until the mapper is rewritten."

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I think I feel about the same as Fang on this. As much as I would love to see the MyMuds.com project launch and improve my capabilities as a developer, the thing that's really affecting the adoption rate of CMUD right now is stability of the client. I have issues with the mapper myself, preventing me from entering certain areas because CMUD completely freezes when I take certain exits and I can't find the rhyme or reason to be able to cope with it.

Apart from the mapper, general bug fixing in CMUD has been crucial to its success rate, too. I'm sure you're already painfully aware of the impact of those glitches, so it doesn't really need to be repeated in this thread. The bug fixes have been great lately, and I'm able to find workarounds for the most of the ones I come across now, allowing me to play with the client a whole lot more.

The features I'd ask for in a new mapper would essentially boil down to minor fixes and tweaks:
- Improved speedwalking without the need for scripting it (nebulous request, I realize)
- Improved mapping of those special/other exits. When I go "in" or "out" and the mapper randomly picks a spot to drop the new room, sometimes it just doesn't make any sense (on top of another adjacent room or far away from the previous room).
- Better integration of ATCP.
- Ability (toggle option) to automatically "guess" your location when the mapper gets out of sync with your movements, similar to what MudBot's mapper module does. That is, it checks your room title and available exits against the list of rooms when you successfully move and the room doesn't line up with your map.
- We can assume better integration with the new docking system is already on the to-do list, right?

My complicated little automapper/speedwalker script is what slows down the client the most, I think. I'm using ATCP to match room names for speedwalking now, so I've been able to disable the one trigger that was super slow, but I haven't tried mapping new rooms in a while.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Biased is definitely an accurate word for how we would react. I find the MyMuds project intriguing, but I have always wanted more from the mapper. If you take a look at my ToolBox package you will see some of the kind of things I feel the mapper should be able to do right out of the gate. I never quite finished my coup de'tat portion of that script, because I got sidetracked with subregex. The last thing I was working on with it was a way to query for all rooms within X steps of the current reported location, that kind of query would really be better handled in code then script +SQL.

In any case, if you think anything in that package is worthy of being a standard feature feel free to copy any portion of the logic used. If you want me to try porting some portions into Delphi to save you time, I will be happy to give it a go.

Posted: Tue Apr 29, 2008 3:05 am

This thread seems to have turned into an "ideas for the new mapper" thread, so I don't feel too bad about posting this thought I just had:

More mapper events, and clear documentation on when they're raised. Practically anything the mapper does could have an event associated with it that someone might find useful - when a speedwalk starts (perhaps with parameters showing the starting and finishing rooms, or even a full list of the route the mapper's walking), when the mapper thinks it's lost (when the room the mapper thinks you're in doesn't match the one the MUD is saying you're in), whose parameters could perhaps be the room name, description and exits of the room the MUD is saying you're in... all sorts. Could be good.

Also, in addition to the lost and found logic everyone's after, it'd be nice if tagging was indicated in the autoconfig window and in the mapper config itself. It's not always clear whether the mapper is still trying to find room information on its own, or whether it's relying solely on your tags for certain parts.

Posted: Tue Apr 29, 2008 3:49 am

Posted: Tue Apr 29, 2008 3:54 am

Oh, I forgot to address the real question: Zugg, I think the mapper will attract more users.

Especially if it is easy to begin mapping properly, relatively quickly and painlessly, on the majority of the more popular muds. These muds would be any that are advertised through CMUD, or that make the top of mud rating sites like topmudsites.com

Posted: Tue Apr 29, 2008 6:19 am

Btw, use ATCP for IRE MUDs to get foolproof mapping. One of the "fixes" in the mapper is to make #TAG (and ATCP, which uses tags) to be more foolproof, but it's already pretty good. Just be sure to turn off MCCP when using ATCP. But using this I have no trouble mapping any IRE MUDs.

Back in the zMUD days, I *did* run the mapper against the top 20 MUDs and had a very high success rate. Of course, the top MUDs have changed since then. But getting the config working isn't all there is to good mapping...you also will need to create a bunch of #NOMAP and #NODIR triggers to ignore certain lines from the MUD and to ignore "you can't move that direction" movement. And there is no way to detect those...you have to write the triggers yourself.

One thing that I've considered is creating pre-installed *.ZFG mapper configurations for the MUDs in the icon list in CMUD. Also, improving the Shared Package Library to store mapper configurations for various MUDs is part of the mapper improvements. Storing a mapper configuration, along with the necessary triggers to map a MUD would probably be some of the best packages for people to download from the library.

Anyway, just a side comment to answer some of Caled's issues. Keep the comments coming, they are very useful.

Enchanter Joined: 10 Oct 2000 Posts: 698

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Am out and about so will keep it brief.
I'm biased too of course. MyMuds holds no interest for me personally and I don't expect to put any money into it.
If CMUD stayed the same and my 2yr subscription ran out I'd not bother upgrading without the mapper.

So from a 'my interest' point of view - Mapper.
From a 'how will Zugg get my cash' view - Mapper.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

My first thoughts on upgrading the mapper.

1. Get rid of its zfg and ini files.
1a. The information in the ini file is better served being saved into the layout files for the session.

1b. The information in the zfg should be moved into new settings in the package editor. The first would be a module level setting called a mapper configuration. It would be able to contain classes and triggers, and all other existing setting types. This is where the mapper would create any temporary scripts or triggers it uses. The settings that are directly part of this module level would be global, external, local, map file name, and slowwalking preferences. This setting would be the link between a window and the map, meaning that a map command or function would look for such a setting that is enabled for that window and then preform with the associated map.

1c. This follows off 1b, configuration data is stored as settings. We can keep the current paragraph method initially, but some settings would better be created as an obvious trigger using the #TAG command. In the end it might make the most sense to actually create everything as a series of triggers. This consolidates the way in which the map interracts with data into a single interface instead of the currently kludged logic it uses to detect and override. The benefit of this method is that portions of the configuration can be turned on and off with #T±, room description is something that is commonly turned on and off.

2. #NODIR can be automated. When a user enters a direction the mapper currently detects that and queues the direction. It also sets the %inwalk and %walkactive flags. It does not turn on the slowwalk timeout. If it created a step timeout and record a current scroll buffer position it could then determine if it is likely that a wall or such was encountered. The logic would be if received data prompt user regarding step having been stopped, when user indicates yes then prompt with list of lines received since direction was sent. The user can then select the appropiate line and the #NODIR trigger will be created. This sort of prompting needs to be done in such a fashion that it does not block normal user input, but is very obvious. It should also be able to be turned off in the configuration control.

3. Configuration improvements. Many of us have said that the configuration dialog needs to be more interractive. When it comes back with its detected data it needs to allow the user to mark lines and parts of lines. It needs to show the original coloring of the lines and have checkboxes to control what things are. The checkboxes would initially be set by the wizard, but user input there would adjust it. Some additional checkboxes that make sense are Color, NoMap, NoDir.
3a. Additionally the ability to set up parsing within the description should be made available, this would be an additional wizard section. I don't it needs to go any deeper then a per sentence/line base. It would provide checkboxes for Include and Color. This would control what actually gets recorded for the description.

3b. With the first detection completed, create the room while the wizard is still active. Then step in the opposite direction. It has been my experience that while the wizard is actively looking for information it notices things slightly differently then the configuration it creates. This is supported by many users stating that the wizard detected perfectly, but the map didn't work on thier very next step. By stepping in the reverse direction and attempting the capture with the configuration you can display a confirmation of did I get everything correct.

4. Mapping gentle maze areas, this is an area that needs improvement. By a gentle maze I mean those where rooms don't quite line up in a cartesian form, but the exits are a reasonable 1-1 with reverse direction match. I will post a screen shot for this later so everyone knows what I mean. I will also post the logic series from my override script that walks through and maps these things nearly perfectly.

More ideas to come later, but I think these are the first things that really need to be done in rewriting the mapper.

Adept Joined: 21 Sep 2005 Posts: 250 Location: Austin, TX

I'll agree with the majority here - I would far rather see the mapper improved and upgraded before the MyMuds website. I have put myself out (on my MUD) as the local CMUD guru. Easily 2/3 of the questions that I get from other players involve either mapper configuration or one of the outstanding mapper bugs/crashes. From that anecdotal information, I conclude that the mapper is

I'll post thoughts on mapper upgrades later, once I've had time to marshal my thoughts on the matter.

Posted: Tue Apr 29, 2008 8:59 pm

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The thrust of my 4th point really wasn't the layout, as that is a very individual thing. My point is more that it is very possible to have the mapper properly connect such exits without the user having to drag and merge rooms.

The logic with my point for #NODIR can actually be extended. If the timeout it uses is short like 2 seconds, and no new lines have been received it could wait again, if just a few lines and a prompt have been received then it should prompt the user about a wall, or possible room information when no description is expected. Many lines say 4-20 means that the room probably came through and wasn't recognized. I would also say that anything over 15 lines means the user is busy and the lines should silently be recorded someplace with a little icon for the user to click on and intitate the prompts. This actually makes the mapper more of a system that tries to learn about your mud.

Really the entire point of my post in this topic this morning is to say, that rewriting the mapper needs to be a true rewrite. There is more that needs to be done with it then anyone thinks, and leaving it half done will only cause more problems. It is a very big job and I would support Zugg if he felt that getting a groundwork for MyMuds up was more important.

Other clients are starting to have an actual mapper, and for CMud to be on top it needs to have things like the configuration structure changed. The configuration wizard is actually the oldest part of the mapper and has always been finicky. CMud has the settings structure, and regex capabilties needed to do away with the older configuration system.

Posted: Wed Apr 30, 2008 1:14 am

My initial comment on this is that you have to be very careful. While I'm definitely interested in making big improvements to the mapper, I also want to maintain zMUD compatibility. A lot of people have put a *lot* of work into getting their mapper working, and if the mapper in CMUD doesn't work with their existing map configuration, then they are not going to use CMUD.

So while I can add new methods for detecting room names, exits, etc, the "old" configuration will still remain. It actually works very well on a lot of MUDs, and I don't want to toss something out that works just because it's old. The trick is to make it easier to override with #TAG. Right now #TAG still has some quirks.

A new Wizard could use some new algorithms to make this better, but I still need to support the old algorithm.

Posted: Wed Apr 30, 2008 1:19 am

I dunno... would it be so hard to support the old configuration using zfg files and whatnot while also including a newer configuration style for new configs? I remember you saying at one point that you wanted to be able to store mapper config information in pkg files, which would probably be the best change you could make to the mapper (after, perhaps, the database change). Doing that would break zfg support, so there needs to be some way to support both.

Since mapper configs would be stored in packages, it's possible that someone might have more than one config throughout their collection of packages. Perhaps the new mapper would have some kind of list of available configs and let you choose which one you want to use yourself? That'd allow you to choose an old zfg config if you want or to choose a newer config. You could even have an option to set the config via scripts, for example when swapping from brief to verbose mode, or from mortal to immortal.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Import .zfg, new import option that converts all the data in the zfg into a series of triggers with some small amount of script. The old algorithm works as a baseline for detection. Improving the users ability to interract with it and adjust it is valuable. Making it easy for the user to turn off portions of the detection on the fly it great. Having experts post perfected mapper configurations into the package library is priceless.

Enchanter Joined: 10 Oct 2000 Posts: 698

I've thought about how to express this and I can just find no way to make it not sound like I want to argue...

If a lot of people have put a *lot* of work into getting their mapper working but the mapper works very well on a lot of MUDs, does this mean that a lot of people spend a lot of their time on muds that are difficult to map? Question

I really believe that people wouldn't mind losing their old config files if a replacement system was created which was a step by step procedure, rather than the repeated tweaking and trying *I* usually end up doing when the first five configuration attempts don't work. They probably wouldn't buy or use CMUD if the actual maps no longer worked after configuring however. The biggest problem will probably be getting all the mapper related triggers such as #NOMAP and #NODIR and other, user-created settings, incorporated into a new configuration scheme. Or will mapper related settings remain separate from the actual config files and the mapper packages be a grafted type package that contains both?

In zMUD, I created all of my mapper settings in the Automapper and AutomapperAll classes that already existed in the System class. If it were possible that certain classes could be exported and incorporated into a new configuration package, it seems to me that would be ideal. A similar process would still be required for mapper-package creation, wouldn't it?

Anyway, I agree with Vij that this is a huge project and I'll live with whatever is decided. Maybe I'm just not grasping the full importance or work necessary when considering a full rewrite versus a compatible rewrite.

Haven't seen this message recently, but it's still true: Zugg ROCKS!!! Thanks.

Magician Joined: 17 Apr 2005 Posts: 496

Oh boy, a subject near and dear to my heart. As someone who's spent an insane amount of time mapping, I wouldn't actually mind doing it all over again... well, OK, I'm actually doing it all over again right now anyway, so I wouldn't mind doing it all over again all over again whenever the improved mapper is released, assuming that the mapper is really awesome, and includes at least some of the following:

Store room type (and similar values) in a better way. My wildest dream would be having an entire GUI and script interface where users could set up their own additions to the room type properties, so I could have actual names for the room types, a section storing which faction controls the room, etc. I know we have a user set string right now, but it's a pain to use to store several types of data (you have to do a lot of extra scripting and remember that, for example, the third item in the list is the room type).

Also, completely change the special exits settings to something more useful, specifically not requiring a single letter for each exit. Let's take two pretty common ones: in and out. Well, obviously, i and o, that's good.. except i is the inventory command for most games. Well, now about n and o? Except n is already used by north. OK, o and p!... well, p is used for the "probe" command. Etc. (Actually, you could just add the in and out directions as real exit directions like up and down, and I'd be super happy.)

Add a customizable toolbar (like in the main window) to the mapper window, so you can have scriptable buttons that control the mapper with the mapper, where they belong. (I think this is already on the list, but I haven't been keeping up, and I want it.)

FIND NEAREST ROOM MATCHING [SQL expression] .... :)

Posted: Wed Apr 30, 2008 8:24 pm

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I agree that we need better options and control for room types and other flags. Even just things like being able to turn off a zone for speedwalking would be very helpful (without the need for a query-and-loop function).

Posted: Wed Apr 30, 2008 10:04 pm

zMapper already lets you do a lot of customizing of custom room types. The problem is that few people bothered to use zMapper, and also that zMapper was pretty buggy. I haven't decided yet how much extra functionality will be directly within CMUD and how much will require the new cMapper program. I am also considering adding more of the cMapper stuff into CMUDPro, since people seem to understand buying CMUDPro for additional features rather than buying a cMapper plugin.

Part of the reason why the mapper rewrite is a big project is that when I change the database format in the CMUD mapper from ADO/MDAC to SQLite, then I also need to change zMapper->cMapper with the same database changes. This is because zMUD/zMapper and CMUD/cMapper actually share a lot of code (the display code and database code).

Rewriting cMapper to use SQLite means that I also need to get cMapper working better. I'll admit that I run into the bugs with zMapper all of the time myself. One part of cMapper that will be a pain is that the Shape Editor in zMapper uses a 3rd-party component that is no longer available, so I need to rewrite cMapper to use the DevExpress controls that CMUD uses. That's a lot of annoying work.

So anyway, a lot of the custom room type stuff is going to be in cMapper. My hope is that if cMapper is more stable, then maybe people will actually buy it. It also means that I need to better market it and show examples of what you can do with it. There has always been a lack of knowledge regarding what zMapper can do already.

Btw, cMapper should be a free upgrade from zMapper because it really is just an upgrade rather than a whole new product (like CMUD was). I don't plan to write cMapper from scratch...that would take *way* too long. I also want to reward those people who were good enough to actually buy zMapper even when it wasn't very stable.

But I will definitely consider your suggestions in making the custom room types easier to use. However, custom data will always be user-defined string lists. I don't plan to add a full database interface where you can add your own custom database fields to the rooms. That's more like something to be done with the database module in the far future. Letting users change the actual database structure by adding custom fields is a very bad idea and can lead to all sorts of incompatibilities down the road. So you will always still need to remember that the 3rd value in your custom data string list is the "faction".

However, I *do* plan to implement features to make room types more integrated into the mapper design. For example, "water" rooms that can be excluded from speedwalking when you aren't carrying a boat, or "flying" rooms that can be excluded from speedwalking if you can't fly, and stuff like that. So it's possible that you will see some additional room-type functionality even in the core CMUD mapper. But assigning custom shapes or icons to room types will probably always require cMapper.

Magician Joined: 17 Apr 2005 Posts: 496

(Please don't hate me, Zugg.)

When showing a zone with child (nested) zones, show all the rooms in the child zones, too. I keep my rooms in the zones they're assigned in game, because it works out nicely, and usually it's useful to just see the zone I'm in, but sometimes I want to see all the rooms in several (or every) zone in one BIG map--without changing the room->zone mapping in my map, and it would be logical to just nest the zones I want to see together.

This was brought up in another thread: A simple addmarker function, for those who don't want to mess around with creating room shapes, which adds a pin-style marker to the given room with an option of, say, twelve or so colours.

I also had a lot of gripes about the room shape thingy in ZMapper, but I don't have it installed atm to remember what I hated so much.

Edit: Totally ninja'd. I suppose I'll survive storing name->number in db vars, it's just..annoying trying to explain it to people.

Also, since you're rewriting the Shape Editor stuff anyway, I think one of the things I hated was that the format it used was odd? (OK, it's been a very long time.) Anyway, a more standard/easier to use format would be nice--something preferably handled by Inkscape (the major free/open vector program).