Zugg Software :: View topic

Posted: Wed Sep 03, 2008 10:35 pm

As you can tell from some of the other forum threads here, I'm still buried in the low-level details of the new mapper. I'm still trying to decide at what point to release a beta version for people to start testing. I've been starting to think about the architecture changes to allow for multiple map windows and multiple locations, but I don't have those features implemented yet. The mapper is mostly working in the normal way that it always has with a single map window. And I haven't yet changed how room scripts are handled either.

I've still got at least another two days of work to get the current room properties dialog fully functional. Just a lot of details to finish and still a lot of testing to be done on it.

Given that 2.36 is pretty stable, I'm not sure there is any reason for me to rush anything out at this point. So I'm considering just continuing to work on the new multiple-map and multiple-locations design, and implement the changes to how room scripts are handled and then release a beta version with all of those new features and changes to test. This would keep me from getting distracted with other bug fixes and keep focused on the new mapper stuff for a while longer.

This goes a bit beyond the scope of the initial "Phase 1" of the mapper. But I think these new ideas for tracking multiple locations and handling scripts in a better way would be huge improvements to the mapper. It makes sense to do these things while I'm in the low-level redesign mode, and would help open up possibilities for things that we might not have thought of for the future.

My impression is that people would rather play with a new beta that actually has some cool new features in it, rather than just beta testing the same mapper that just has the SQLite changes and new room properties dialog. But let me know if I'm wrong.

So, you probably won't see the first beta with all of the new stuff until closer to the end of Sept.

Posted: Mon Sep 15, 2008 11:31 pm

I've finished with the massive editing of the mapper that was needed to split it into the new modules for handling multiple locations and multiple map windows. Today I finally got CMUD to compile again. Of course, when I try to open the mapper I get many errors, so I'll be doing the testing and debugging for the rest of this week to try and get it working at least as well as it did before for single map windows.

Hopefully next week I'll be able to start adding the support for the new commands like #LOCATION for creating and manipulating multiple location objects.

So far, I'm pretty much on schedule and haven't run into any nasty surprises yet.

Posted: Mon Sep 15, 2008 11:35 pm

Very cool. Thanks for keeping us up to date!

Posted: Wed Sep 17, 2008 7:55 pm

Just a quick mid-week update. The new mapper stuff is starting to work pretty well. Today I was actually able to add the #LOCATION and #WITHLOC commands and get those working. So now I can add new location markers to test them. They seem to work pretty well.

Of course, I don't yet have any way to save these location markers since I haven't added the new settings type for them to store them in the package database yet. I won't get to that until next week.

Right now I'm going through the rest of the mapper to figure out what works and what doesn't. There are still a few routines in the mapper that access the current MUD session directly instead of just going through the current location object. I haven't added any of the drop-down lists to select which locations to track in the map or room properties. Nor is there any sort of "scoping" for any of the location objects yet. I also haven't tested multiple or shared map windows yet. So still plenty of work left to be done.

But the mapper is displaying the multiple locations in their custom colors, speedwalking is working, and the limited %roomXXX functions and commands that I've tested seem to work and use the current location (set with #LOC or #WITHLOC) properly.

Still looking good for a release at the end of the month. Actually, the way this is going, it might even be earlier. Very happy with the new architecture so far. The flexibility of multiple markers is pretty cool.

Chiara and I will be gone for a long weekend starting tomorrow for our 9th anniversary. We are going back up to Estes Park (Rocky Mountain National Park) where we visited on our longer trip last year. Just for a few days this time. No time for any longer vacation right now. So Monday I'll be back at work on the mapper.

Posted: Wed Sep 17, 2008 8:25 pm

Have fun, and if your at a high enough elevation, have a snowball fight for me.

Wizard Joined: 22 Mar 2007 Posts: 2320

Enjoy your vacation and refresh your brain. This is looking good! When the beta comes out, I'll test it in my 10,000 room map

Posted: Wed Sep 24, 2008 4:37 pm

An important project has suddenly come up that I need to work on this week, and part of next week. Thus, I need to change the ETA of the first new mapper Beta to the middle of October. Sorry for the sudden change, but I'll keep you up-to-date as much as I can.

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

More important than the cmud mapper?! *gasp* ;) Thanks for the updates! Very excited to see it.

Beginner Joined: 05 Nov 2007 Posts: 14

Very nice.

I'm just wondering about the drawing design, are you still going for the old "room as box" design or can the users alter it?
For example, I'd like to be able to have "roads" show like a round colored circle instead of a box, while houses and "inside" areas still be boxes.
I'm not sure how to better describe it. It makes looking at the map and checking where I am a lot easier, I think.

Looking forward to seeing your new mapper! :)

Posted: Mon Sep 29, 2008 12:06 am

Can we get a hint on what this new project is?

Wizard Joined: 22 Mar 2007 Posts: 2320

Using different shapes for rooms was a feature available in the zmapper product, not in the built-in mapper. Zugg is not changing anything like that yet. The upcoming beta will mostly have fundamental changes in the way map information is stored.

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

Also, some of the more advanced functions will probably still be a separate product. Zugg hasn't discussed CMapper as much as he is getting the basic functionality for the CMUD mapper down first. With what he has brought up, I'm excited.

As for the project, probably something that is going to earn him some nice cash. :)

Posted: Mon Sep 29, 2008 4:44 pm

Azerack: You can already change the shape of rooms using zMapper. The intent of the previous mapper was that all "graphical" enhancements to the map would require the zMapper plugin. While some of these features will be moved into the normal mapper, many graphical enhancements in the future will still require zMapper (to be replaced with a new cMapper program). Yes, zMapper is a bit buggy, but you might want to download the trial and play with it a bit.

Also, as Rahab mentioned, the current rewrite is working on more low-level architecture changes. You won't see any graphical enhancements until the Phase 3 of the project, as mentioned elsewhere in this forum about the plan for the mapper improvements.

Shalimar: Sorry, no hint yet. You'll have to wait for the announcement when it's ready.

Posted: Fri Oct 31, 2008 7:39 pm

Time for a new update. Now that www.SlightlyMorbid.com is released, I'm back to the mapper. I was able to do more debugging this week before I got distracted by the CMUD 2.37 release. It seems to be mostly working like the old mapper did, except for all of the underlying architecture changes.

What I still want to finish before the release is to get the new structure for mapper scripts in place. This involves creating a new kind of "Window" object that can represent a more general type of window. Then I can use this for the existing MUD windows, but also for Mapper view windows and Room Properties windows. This is the key user interface method for allowing you to create multiple mapper windows.

Then I need to store the new Location objects as new settings types. Right now I have the #LOCATION and #WITHLOC commands working, but the locations don't get stored in your package file yet.

Then I'll add the Room, Zone, and RoomType objects, which are the "classes" that you can place within a Mapper window to contain your map scripts. This involves creating a subclass to the current "Class" object. The main difference between a Class and a Room is that a Room also has script text associated with it that is executed when you enter the room. This will contain the current script assigned to the room in the mapper. Any other settings created by this script will get created and stored within the Room object, just like with a Class.

As I've said before, while I'm tempted to do a beta release right now to let people test to make sure I haven't broken anything in the mapper with all of this new architecture, I also realize that once I do a beta release, then I get bogged down in bug fixing. So I'm going to continue to wait on this release until I have more new stuff ready.

Posted: Tue Nov 11, 2008 8:16 pm

Well, regardless of my rant about PCI compliance and our PHP4 web site, I am *not* delaying the new mapper. I'm going ahead with the mapper stuff and will deal with the web site issues after the holidays in January.

So, I'm still working hard and hoping to release the alpha/beta release of the mapper either this week or next week. I'm still in the middle of the architectural changes mess with the new way of handling room scripts.

To give you an analogy, this new mapper is like getting a new house. It might look the same as the old house on the outside, but on the inside the rooms are all arranged differently and there are some new features. For example, the new house might have some new rooms that the old house didn't, or a bigger kitchen. But it still has all of the familiar rooms of the old house too. All of the old furniture (mapper scripts) fit into the new house, but they might end up in a different room.

The first alpha or beta version will be like getting a new house that is freshly painted, but without much decoration done yet. I'll have all of the hooks on the wall for future decorations, but it will initially be a bit bare. My hope is that you'll be able to move in all of your existing furniture and hopefully won't have any trouble figuring out where to put it. Hopefully the doors are all wide enough to accommodate your large items.

OK, so it's a silly analogy, but it fits pretty well. There are *lots* of new hooks in the new mapper architecture that will allow new features to be implemented easily in the future. But this first version is going to be a success if it just works like the old mapper without any new problems. That's my main goal. You'll be able to see many of the new features and start to play with them, but the most important feature is that the new mapper still works as well as the old mapper without any changes to your scripts or configuration.

Back to some of the specific implementation details, we have talked a lot about how to handle room scripts in the past. We talked about creating a new kind of "class folder" for room scripts, zone scripts, room types, etc. Rather than creating a bunch of new setting types (like Rooms, Zones, etc), I am simply adding some new features to existing "class" objects.

Specifically, a Class folder now has two scripts assigned to it (that you edit in the package editor just like the script for an alias or trigger). The first script is executed when the class folder is enabled, and the second script is executed when the class folder is disabled. This will be used by the mapper so that each Room is just a normal Class folder and when you enter a room, the class is enabled, causing the enable-script to be executed. The disable-script will be blank, but you can use this as needed to clean up anything when you leave a room and the class gets disabled.

In the old mapper, the scripts for a room are created and destroyed as you enter and leave a room. This is very slow. In the new mapper, the Room class folder is simply enabled when you enter and disabled when you leave. This is much faster and also allows you to create more complex script objects that get saved with your normal session package.

The next new attribute of a Class folder is something called a "Reference field". This is a special field used to connect a class folder with a room or zone on the map. But it provides a more general architecture that could allow more features in the future.

A Class folder that is assigned to a specific room on your map will have a Reference field value of "RoomXXX" where XXX is the room number. A Class folder that is assigned to a specific zone will have a Reference field of "ZoneXXX" where XXX is the zone number. A Class folder assigned to a specific room "type" will have a Reference field of "RoomTypeXXX".

When you enter a room (for example, you enter room number 1234), the mapper will enable any class folder that has a reference field equal to Room1234. This actually allows you to have multiple class folders for a single room (or zone, etc). When you leave a room, the class folders with that reference field value are disabled. The mapper actually creates links to these class folders when the map is first loaded, and then keeps them updated as you modify your classes. So there isn't any "lookup time" required. The mapper doesn't need to search for these class folders...it already has a link for each room and zone to their list of classes. So this is very fast and flexible.

In a way, this is similar to events where you can have multiple scripts assigned to the same event name. The Reference field is like an event name, but it is used to enable/disable entire sets of scripts stored within the classes (and execute the new class enable and disable scripts).

This is a very powerful concept. It makes the mapper faster and more powerful, but it will also have application in your normal scripts. This is how I like to implement new features...even though it's something needed for the new mapper, it has side benefits even for non-mapper scripts.

I'm right in the middle of the implementation and testing of this right now. So far it is working pretty well. I have a fair amount of work still left with the user interface and in testing various obscure cases. However, the mapper is so complex that I probably won't be able to test much of this myself, so I'll be relying upon the first round of beta testers to find the problems.

Going back to my "house" analogy, you will probably discover that the first version of the new house still has some holes in the walls, or some walls that are not painted yet. But hopefully the overall structure of the house will be sound and secure and it won't all come crashing down.

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

Two questions regarding the new reference fields (which sounds like a great idea):

1) Will the reference field be a single value, or a list? (for a list, think of a 'shops' class that I want to link to half-a-dozen different rooms on the map - all shops - so that it is enabled/disabled on entry to any of them)

2) Will there be a scripting command to enable/disable 'all classes with a certain reference field', or will only the mapper be able to do it? That capability would seeem to fit with the it's-something-like-an-event philosophy noted above. Note that this would also allow one to achieve the behavior contemplated in #1 without having the reference field be a list (by having the room-enable script in each shop room enable all 'shop'-referenced classes).

Thanks, and looking forward to seeing the new mapper.

Posted: Wed Nov 12, 2008 9:09 pm

See, that's exactly why I love these forums and love to post about new stuff that I'm working on. Because I had never thought about that, and it's a *great* idea.

However, I don't think I will actually implement it as a string list for the reference field. Once important criterion is that the mapper needs to be able to traverse the list of classes to enable very quickly. With a single reference value you can form a single list of class objects for each reference "keyword". If you allow multiple values, then it is more difficult to form a single "thread" of classes that share a common value.

In other words, I don't want you to create a "shop" class and then list the rooms in the reference field, like "Room1|Room9|Room123" etc. That puts too much of the map structure into your scripts.

What I want to do instead is let you define your own reference keyword, like "shop". Then you apply this keyword to each room as a room property. So Room1 has the "shop" keyword, Room10 has the "shop" keyword, and Room123 has the "shop" keyword. When you enter a room, the original RoomXXX class is enabled, but then it will enable any classes assigned to any of the keywords.

So in this example, you would set up a "shop" class and actually put the keyword "shop" into the reference field. Then each room that you want to be in this category would include the "shop" in it's list of keywords. So each room can have multiple keywords, but each "class" only has a single reference field value.

Does that make sense? If you wanted to have a more global class that was used by multiple keywords, then you can already do that with normal class enabling. For example, maybe you wanted a more fine-grained structure. So instead of "shop", you had something more specific like "weapon-shop" and "armor-shop". But then you wanted a global "shop" class to also be enabled. You would do this by simply putting "#T+ shop" into both the "weapon-shop" and "armor-shop" scripts. Or you could do this by listing both "weapon-shop" and the generic "shop" in the specific room properties. So that would be two ways to handle it.

By allowing the reference field to only contain a single value, then CMUD can cache a list of classes with common values for fast execution for the mapper.

For (2) I will try to come up with a syntax to use the existing #CLASS and #T+/#T- commands to enable/disable a reference field category. Not sure what syntax I'll use, but I'm open to suggestions.

But thanks for the feedback. Thanks to your suggestion, a new "keywords" field for rooms has been added and that will be the hook for more "room flag" kinds of features in the future.

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

So, if I understand correctly, each room will now have a (string)list of keywords, and each class will have a single reference field string. When you enter a room, it will automatically enable classes with the reference field "RoomXXX", plus any others with reference fields matching any of the keywords defined for that room. It will automatically disable using the same when you leave. Similar mechanism for each zone. In addition, there will be some syntax for scripts to enable/disable any classes with a given reference field.

Solves the problem nicely. I like it.

A few observations:

The syntax should clearly distinguish between enable-class-by-name (e.g. #T+ <name>), which enables only the first thing it finds in its search, and enable-multiple-classes-by-reference-field, which works differently. Having both semantics in the same #T+ command, and having the two namespaces lumped in together, seems likely to cause confusion. Just my $0.02. I'd recommend a new command or function rather than overloading #T+.
I'd also love to see some functions for going the other way - giving me back a list of rooms or zones which have a given keyword attached, and another for giving me a list of (the full names of) classes with a given reference field.
I'd be interested to know where exactly in the speedwalker sequence the enable-disable happens, for different kinds of speedwalks. (in other words, before or after walk script, room script, onRoomWalk, etc. is run)

Posted: Mon Nov 17, 2008 11:28 pm

Posted: Tue Nov 18, 2008 12:12 am

Yes, you have it correct.

1) The current syntax that I have is:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

On the issue of #T+ and #T-, I would rather see the syntax match the existing syntax, #T+ name type. This would mean

Posted: Tue Nov 18, 2008 6:13 pm

Vijilante, that's a good idea. I'll probably call it "key" instead of "ref" since I'm trying to use the term "keyword" instead of "reference" in the actual program right now. You are correct that it will help people be more aware of a feature that they probably should be using and aren't.

Wizard Joined: 22 Mar 2007 Posts: 2320

I like Vijilante's idea, if it's practical. It just requires a reinterpretation of the second parameter as identifying a type of keyword or name, instead of a type of setting.

Posted: Tue Nov 18, 2008 10:39 pm

OK, I'm making progress. This is hard stuff but it is coming together. It's like building a house...have to start on the foundation, then build the walls, then finish the walls, etc. I've been doing one step at a time, and that has helped.

For example, on the Room Scripts:

1) First I added the code to create the new "Mapper object" in the settings. This is a "module" (so it lives at the top level of a package) that is assigned to a particular map database file. It becomes the default module container for all other scripts for this particular map database.

2) Then I added the code to store the Location objects. They are stored with the actual Window object that uses them. Once I added the #LOC command to create a Location, then I added the Location objects to the database so they would be stored with a package. Finally, I added the user interface so you can edit them (via Options/Locations similar to editing directions via Options/Directions). You can also do a View/Show/Locations in the Package Editor to see the location object there.

3) Next, I added the code to convert existing room scripts into RoomXXX classes within the Mapper object.

4) Once the scripts were converted, then I changed the code that executes room scripts so that it just enables and disables the room classes (causing the onEnable script to run).

5) Then I changed the #OK trigger for speedwalking to create the trigger within the Mapper object with the trigger ID name of LocXXX where XXX is the name of the location being tracked. So each location object can have it's own #OK trigger. Instead of creating/deleting this trigger all the time, CMUD now just enables and disables it and sets the pattern as needed for the next room.

Each of these steps built upon the work of the previous step. Looking at the entire problem was pretty overwhelming, but doing each step at a time was more manageable.

So I've now got the new mapper executing room scripts and handling the speedwalking #OK triggers. I've added a new #TRACK command so you can set which location you are tracking in the mapper window from within a script, and I've added the drop-down menus to the status bars of the mapper window to control which location is tracked. I also spiffed-up the status bar to make it more useable and separated the name of the current room from the mouse-over help tip area.

The Room Scripts tab of the Room Properties now displays the room script (the one assigned to the onEnable script of the Room class), but it is read-only. There is a button to click that will open the Settings Editor and jump to the script that you want to edit. Note that if you have multiple class folders assigned to the RoomXXX keyword for that specific room, the button to edit a script will only jump to the first folder that it finds matching this key. I will still need to add a way to "find" all of the class folders equal to a particular Key value in the settings editor. Not in this first beta version though. I'll add that search feature when I do the scripting functions that will return the list of matching classes. I haven't done the user interface for editing Zone scripts yet, but they work the same way and create ZoneXXX class folders in the Mapper object window.

So what's left? I still need to add the drop-down menu to the Room Properties window to allow you to change what room it tracks. And I still have a fair amount of live testing and bug fixing to do.

There currently isn't any user interface for creating multiple mapper windows or multiple room property windows yet. I'm still trying to think about exactly how I want to handle that. Probably some menu option within the Tools menu. But that's the main complexity of new features that is left. The rest is just testing and bug fixing.

So I think this is looking pretty good for a release at the end of this week. Cross your fingers!

Posted: Wed Nov 19, 2008 12:32 am

w00t!!!