Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page 1, 2  Next
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Apr 28, 2008 7:29 pm   

Which comes first? The Mapper or MyMuds?
 
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:
Quote:
That problem cannot be fixed until I rewrite the mapper later this year

The mapper is an important part of CMUD. Problems with the mapper are preventing some people from converting from zMUD. The mapper is fairly unique to zMUD/CMUD (other clients have mappers, but they are pretty poor). An improved mapper can attract new customers.

The MyMuds project is still important, but it was going to appeal to a different audience. It was going to be aimed at potential players who couldn't afford to buy the full CMUD client. Yes, it was also going to help developers distribute and sell their script packages, provide new improved forums, and potentially bring in more advertising income (assuming I haven't completely drained the advertising money already with the yearly icon auction).

Both projects are complex and time consuming. The more I have gotten into the design of MyMuds, the more it has grown. And MyMuds isn't something that I'd want to release "half-baked". Getting the mapper converted from MDAC to SQL is also complex, but can probably be done in less time than the MyMuds site.

Now, I know that the response I will get in this forum will be biased towards doing the mapper first. So I probably shouldn't even be asking this question. I guess what I'm really asking is for opinions on what other improvements to the mapper might also be helpful in boosting sales. I need to do something to improve CMUD sales and I don't want to make the same mistake as in the past of getting distracted on a new project that doesn't improve our income.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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:
Fang Xianfu wrote:
Mapper. Mapper mapper mapper mapper mapper mapper mapper.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California

PostPosted: 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
Reply with quote
Arminas
Wizard


Joined: 11 Jul 2002
Posts: 1265
Location: USA

PostPosted: Mon Apr 28, 2008 8:44 pm   
 
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."
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Mon Apr 28, 2008 8:51 pm   
 
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.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Mon Apr 28, 2008 11:06 pm   
 
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.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Tue Apr 29, 2008 3:49 am   
 
charneus wrote:
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.


Really, just a mapper that works.

I know part of the problem for me has been the fault of IRE muds rather than zmud mapper, but even with advice on preferences from people that have successfully used zmud to map Achaea/Aetolia etc, I never got it working properly.

Visually, I want to be able to use it. I mean.. I have this massive map of Aetolia using the mudbot imapper, and its great that it simply -works-. I especially love how it parses information from the game (like who lists showing the room people are in) and converts it to a vnum for them, so it would be nice if that sort of information (the list of room titles for example) was easy to reference in script (it might be already, no idea) so I could create triggers that do the same for me. I think Vijilante has some good suggestions for improvements, but that ultimately not many are really needed.

That said, it really does boil down to simply being able to use it. And I know there are weird things with IRE, but I never understood why it was so difficult to get it to recognise the title, description and exits properly in the autoconfig. I mean, I had it set so the -only- time a particular colour came from the mud, was for a room title, and it would pick up everything but, heh.

I'd suggest when testing it toward the end, the more map-noobish of us testing the autoconfig out on http://www.topmudsites.com/ muds.. maybe the first 20 at least (divide them up between us?), and making sure that first time users can get straight into it.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: 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
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Tue Apr 29, 2008 7:53 am   Re: Which comes first? The Mapper or MyMuds?
 
Zugg wrote:
Now, I know that the response I will get in this forum will be biased towards doing the mapper first.

"Biased" is not nearly a strong enough word/concept to define my feelings. I DITTO Fang's sentiments.

Zugg wrote:
I guess what I'm really asking is for opinions on what other improvements to the mapper might also be helpful in boosting sales.


Edit: Zugg types way faster than I
1. Mapper packages. Why must people constantly reconfigure their mapper for MUDs that other players are already mapping? Drop all the pertinent settings along with the #NODIR and #NOMAP stuff into a package and create a second/separate/linked mapper settings library for download by registered users. I know I've sent my .zfg? settings to other players before because they were unable to get the mapper configured correctly, maybe there is a need for this.

(and obviously wasn't thinking about this as hard Razz).
2. Second view. I mentioned this during the development of the original mapper but it was decided it would be too difficult, so it probably still is. Also, it would have limited use on MUDs that create hard-to-map areas such as when .wsen doesn't end up in the same room where the path was entered...except that we now have zones so it shouldn't be as much of an issue. Basically, instead of square symbols representing rooms, flatened parallelograms are used. One of these symbols above another would represent the z-axis of the map. Lots of time and effort could be spent adding camera angles and zooming but it's not necessary (at first, hehe). I use the trick of moving mult-level rooms into one level with not-shown links, but I'd still like to see a 3D representation of my maps.

3. It's been mentioned before but, integration with the future chat module so that hidden codes (such as MXP) can allow tracking a buddy's location on MY map if he decides to broadcast his location. MUDs hated that scripts were developed to give "an unfair advantage to certain players." Imagine the level of hate caused by making this an easy trick - I think players would love it... until they forget to not broadcast on a PK MUD.

Be sure to use that logic-pathing concept information so that the basics work immediately. I remember when all the possible modes/exit and entrance scripts/room scripts finally got figured out in the zMud mapper, it was so very nice to map after you got all the logic straightened out for all the possible modes.

I'll think about this some more, but right now I can't think of anything else. Surely someone else has some ideas?
Reply with quote
Guinn
Wizard


Joined: 03 Mar 2001
Posts: 1127
Location: London

PostPosted: Tue Apr 29, 2008 10:45 am   
 
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.
_________________
CMUD Pro, Windows Vista x64
Core2 Q6600, 4GB RAM, GeForce 8800GT
Because you need it for text... ;)
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Tue Apr 29, 2008 11:04 am   
 
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.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
JQuilici
Adept


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

PostPosted: Tue Apr 29, 2008 8:32 pm   
 
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.
_________________
Come visit Mozart Mud...and tell an imm that Aerith sent you!
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Tue Apr 29, 2008 8:59 pm   
 
Vijilante wrote:
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.

I reckon this sort of thing is what MXP was born to do. For example:
#say "The mapper thinks you may have entered a direction that caused it to hit a wall. <send #nodirconfig>Click here to tell the mapper which line indicates you've hit a wall so that it can detect this automatically in the future.</send> <send '#help #nodirconfig'>Click here for more help on using this feature.</send>"

Vijilante wrote:
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.

I really don't think this is necessary. Often maps take quite a bit of tweaking to get them looking pretty in these circumstances, and if you're going to be doing the tweaking manually anyway, you might as well leave it to be completely manual. Practically every area on the MUDs I've played used gentle mazes like this, and I didn't find it much hassle at all to put the rooms in nice-looking positions.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Wed Apr 30, 2008 1:04 am   
 
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.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: 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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Wed Apr 30, 2008 1:46 am   
 
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.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
mr_kent
Enchanter


Joined: 10 Oct 2000
Posts: 698

PostPosted: Wed Apr 30, 2008 7:35 am   
 
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.
Reply with quote
gamma_ray
Magician


Joined: 17 Apr 2005
Posts: 496

PostPosted: Wed Apr 30, 2008 7:31 pm   
 
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] .... :)
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Wed Apr 30, 2008 8:24 pm   
 
gamma_ray wrote:
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).

This idea is AWESOME. Perhaps it could be part of CMapper, because it sounds complex to implement. Another possible feature for it in that case would be to have room colours and pictures for each different room type. Say, if the room has a faction set, the faction colour takes precedence, else it'll be the room's terrain type. The room's picture could be a coin if it's a shop, else a scroll if it contains your guild trainer, and so on and so forth...

gamma_ray wrote:
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.)

You're wrong about how this works. The letter is used ONLY for speedwalking, where it requires a single letter. That's in the same way that hjkl represent the diagonals in speedwalks - there needs to be a single character for your other special exits. The command list is the part that's used to determine if you've just entered that direction or not, not this letter, and there's no such limitation on that list.

Your final two ideas are nice too.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Wed Apr 30, 2008 8:40 pm   
 
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).
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
gamma_ray
Magician


Joined: 17 Apr 2005
Posts: 496

PostPosted: Wed Apr 30, 2008 10:19 pm   
 
(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).
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
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

© 2009 Zugg Software. Hosted by Wolfpaw.net