Zugg Software :: View topic

Posted: Fri Jul 03, 2009 10:17 pm

I was hoping to get another Beta released this week (3.09), but the code is being stubborn again.

As I mentioned on the "To-do" list (which I made into a Sticky), I've been working mostly on the SSH/CMUDPro part of this so that I can try to get TeSSH into Public status. The main programming part of this was to port the FTP module from zMUD, improve it to work in CMUD, and then add SFTP support (file transfer over the existing SSH connection).

I've *finally* got this all working pretty well now. The only thing left is to allow each session window to have it's own FTP window. This is actually the same issue as allowing each session to have it's own Mapper window. So fixing this will kill both issues. But I didn't get to it today, so it will need to wait until next week.

Then I have a handful of "general bugs" that effect both TeSSH and CMUD to fix and then I'll release the 3.09 beta version. For TeSSH, 3.09 will be a Public Release Candicate (RC1). For CMUD it will still be a normal BETA version because there are still some mapper issues to be fixed that I'm delaying until after TeSSH is released. But by releasing 3.09 as an RC1, people will be able to test the FTP/SFTP stuff while I work on getting the TeSSH documentation set up on the new TeSSH.com web site in preparation for a public release of TeSSH.

So, hopefully next week (end of week). Cross your fingers. This is taking a lot longer than I planned, but at least I seem to be *finally* back to 100% after fighting that flu for over 2 weeks.

Posted: Sat Jul 11, 2009 2:26 am

As usual, the code is really being stubborn. But I'm going to work tomorrow anyway to try and get a beta release. Mainly because (a) I'm going to be doing all sorts of other errands next week and won't get much time to program, and (b) because I'm really getting sick of some of this code.

Today I spent the entire day (once again) trying to get the window docking system to cooperate. This is the issue allowing each session window to have it's own Mapper window (or FTP window, or Room Properties window). In 3.08, there was only a single global map viewer window being created, even though the new mapper code and Location object system allowed multiple windows.

While the mapper code allowed multiple windows, the problem was with the window docking system. Here is the convoluted way that the window docking system works:

1) When CMUD loads, any docked panels defined at Delphi "design time" are created. This is where the current global panels for the Mapper, Editor, Room Properties, Help system, etc are created in 3.08

2) CMUD loads a set of package files for a session.

3) CMUD creates docked panels for any window objects in the packages. The UID stored with each window object in the package is assigned to the docked panel.

4) CMUD calls the window docking "LoadLayout" routine. This routine (part of the 3rd party docking system) loads the *.XLY layout file, and for each dock panel in the layout file, it looks for a corresponding dock panel object with a matching UID. If no matching UID is found, the window is not created. Once the docking system matches each element in the XLY file with the real dock panel objects, then it updates the layout of the dock panels to reflect what was saved in the XLY file.

The key point here is that the actual dock panels must be all created BEFORE the XLY file is loaded.

In 3.08, the dock panel for the mapper always existed because it was created at design-time within Delphi. There was a single mapper docking panel with a single UID. So you couldn't have multiple map windows because there was only ONE dock panel for the mapper.

To allow multiple mapper windows, CMUD needs to dynamically create new dock panels for each mapper window and assign them a unique ID. Fortunately, the new "Map Object" stores the database filename of the map, along with a unique UID value for the map object. So I can use this as the unique UID for the dock panel associated with that map database.

So now, when CMUD loads, it needs to loop through the packages being loaded and determine which map database objects are being loaded. Then create a dock panel for each map with it's unique UID value. Then, loading the XLY layout file for the session will put the various mapper dock panels in the correct position. As a kludge, if the old fixed UID for the old map panel is found, then a new dock panel is created to match whatever map database object is the first one found for the current session. This allows existing XLY session layouts to still load the initial map window for a single session. But when the new XLY layout is saved, the dock panel for the map will have a new UID that matches the map database object.

Now, when you click the Map button, CMUD checks to see if a map panel is currently assigned to the current session. If not, a new mapper panel is created. If an existing map panel is found for the session, then it just shows the existing map panel.

As an extension to this, when searching for a map panel for a specific session, it first looks in the same package as the main session window for a Map database object. If nothing is found, then it searches for any map database object in a shared package. This should allow multiple sessions to use a shared map database, while allowing other session windows to have their own map object.

I've got all of this coded, but it's still not all working properly. It's working for FTP windows, which were my first test (and simpler because there wasn't any existing code to worry about). Once the mapper windows work properly, then I'll need to apply a similar technique for the Room Properties windows. The code that I've written is better than the old code and easier to understand and debug, so once I get it all working, it should be easier to deal with in the future. But replacing the old code with the new code is proving to be a pain.

So, like I said, I'm going to work on this tomorrow even though I don't normally program on Saturdays. This is the last issue on my high-priority list for this Beta version, so once I get it all working, I'll release 3.09 late tomorrow evening. Cross your fingers for me!

Posted: Sat Jul 11, 2009 3:25 am

Thanks for the update!

Posted: Sat Jul 11, 2009 3:56 am

Positive Mental Attitude Zugg, Early Afternoon! Early Afternoon!

Posted: Sat Jul 11, 2009 4:09 pm

Blah....I hate it when I get up in the morning and during my shower I realize that half the code I wrote yesterday is all wrong.

I don't know why I'm having so much trouble getting my head around the new mapper architecture. Maybe it's the 10+ years of working on the older mapper.

In the older mapper, the map window was tied directly to the master session window. But in the new mapper architecture, everything is tied together via the Location objects. The session window shouldn't have a direct connection to *any* map window...it should be using it's current Location object to determine what map window to use.

I mentioned a bit in the previous post how the window docking system works. I forgot to mention it's biggest limitation: While each docked panel has a unique UID, there isn't any sort of "window type" or "class" value telling you what kind of window to put into the panel. The docking system just handles the panel containers...not the contents. So when the docking system tries to locate a specific panel UID and it doesn't exist, CMUD needs to create the panel and then figure out what kind of window it was supposed to be (a MUD output window, a mapper window, a room properties window, an editor window, etc).

In previous versions, this was easy: if the UID matches the single UID for the mapper window, then create the mapper window. But now there can be more than one mapper window. Each has a unique UID. These UID values can be anything (they are actually Windows GUID values) so there is no way to tell the window "type" by looking at the UID. For MUD windows, CMUD searches the various Window objects to find the Window object with the matching UID.

Now, for the mapper window, I can search the list of Map Database Objects and find the object with the matching UID. That's fine. But the mapper window that I create should be connected to that Map Database Object and *not* any specific MUD session window.

When you select a session window, CMUD should look at the current Location object for the window, then look at the Map Database that the location object points to, and then see if there is a mapper window associated with that database object. If you select a different session window, or if you select a different location object in the session, then it should find a different map window.

From the end-user point of view, all of this is mostly transparent. When you initially click the Map button in the toolbar, CMUD should look at the current Location object in the current window context and find the Map Database object associated with it. Then it checks to see if a mapper window has been created for that map database. If not, a new mapper panel is created and displayed, and the Map button is highlighted (enabled).

If you click on a different session window, CMUD checks the location object in the new session, looks for the map database, and determines if a mapper window exists for that map database. If not, the Map button in the toolbar is turned off. If a mapper window is found, then the new mapper window gets the mapper focus. So if you have multiple map windows tabbed together, the map window for the session you just clicked on will come to the front. When you click back on the previous session window, the previous map window comes to the front.

The mapper window should only be removed from the layout when the map database object associated with it gets removed, not when any specific MUD session window is closed.

So, I think I've got it straight now. Now I just need to go through the code that I wrote yesterday and fix it so it's not looking at the session window, but instead looks at the Location Object and Map Database objects to determine which map window is which.

Then I'll need to figure out how this all relates to the Room Properties. Gee, my head hurts already :)

Posted: Sat Jul 11, 2009 5:53 pm

And down the rabbit hole I fall....

Removing the reference to the mapper window from the session window sounds fine and dandy. Until I started compiling and then found the old Database Module. You know, that other ancient module that I ported from zMUD? Remember the silly Zone and Room name fields you could put into the database that hardy anyone used? Well, the Database Module window is still tied to the session window (because that's how it was in zMUD). So when the Database Module needs to search for a room or zone name, it calls the map window object within the session window object. The Database Module has no concept of the new "Location objects".

Grrr... sometimes I wish I had never ported this crappy code from zMUD. I'm constantly amazed that zMUD even works at all with it's lack of modularity and spaghetti code interdependencies. What a mess this is.

So now I need to fix the Database Module so that is also uses the proper location object and map database objects.

This is turning into a bigger and bigger project. And I *must* release something today or else is going to be another couple of weeks, and the current beta is eventually going to expire.

Well, one other thing I'm doing to try to make my brain hurt less is that I ripping out all of the 2.3x mapper code that I still had with conditional compilation statements. The conditional compilation statements allowed me to compile a new 2.3x version of CMUD, but it also made the code twice as hard to read. There's no going back to 2.3x at this point, so I'm removing this code so it doesn't keep getting in my way and complicating everything. All of the 2.3x mapper code referred to the map window within the session window. With this code removed, then I can start doing a global search for references to this map window variable to fix stuff like the Database Module without it finding hundreds of matches that are all within the 2.3x conditional compilation sections.

It's going to be a long day.

Posted: Sat Jul 11, 2009 8:59 pm

Your making my head start to hurt just talking about it.
Good luck!

Posted: Sat Jul 11, 2009 9:32 pm

And even more:

The #MENU command executes a menu command (that's a bit redundant, isn't it). So now the MUD Session window needs to know which Map window is associated with it. Again, it needs to go through the CurLoc object.

The Room Properties window is even a bigger problem. I was hoping to leave it alone for now, but Nooooo! I have to mess with it too. Because there is yet another mostly un-used feature for adding "contents" to a room where it needs to access the current database module window associated with the current session. But the Room Properties window doesn't have any reference to any MUD session window. All it has is a tracking location. So now what? Am I supposed to kludge this by searching through all of the open sessions looking for one that has CurLoc equal to the location object being used in the room properties window? That just doesn't feel like the right thing to do.

Maybe I'll just disable the "Contents" tab for now. I doubt very many people are using that anyway. The whole reference between the Database Module and the Mapper is a complete mess anyway and probably doesn't even work in 3.08.

Posted: Sat Jul 11, 2009 9:39 pm

Nope, that doesn't work either. The Room Properties *needs* a reference to the session window somehow. For example, the compass buttons need to send directions to the MUD when you click them. The directions are stored in the Packages (English Directions), and it needs to send them over some network connection, which is defined in the MUD window.

So the Room Properties are also going to need to use the current tracking location and then search the list of sessions assigned to that location object for the first primary session that it finds (which is what the Location object itself does when it needs to send stuff to the MUD, like for speedwalking, etc).

Edited: Oh boy, even more fun. Now I'm looking at the code for the Map Configuration Wizard. Guess what? I needs a reference to a MUD session window too!

Posted: Sat Jul 11, 2009 10:08 pm

OK, I'm making a bit of progress now. At least I've got CMUD compiling again. And it loads the map for my test session! Woot! Now I have about 3-4 hours of testing and debugging because I'm *SURE* that it still has problems.

While I was working on all of this, I took some time to draw up the UML(like) diagram for all of this. The real geeks out there might appreciate this. It's just as complicated as you'd expect from all of my discussion above. But strangely enough, writing this down actually helped me a lot to get it all straightened out (well, except for the stupid old Database module issues).

One nice side effect is that all of this *has* cleaned up the code a bit. In the past, the routine to open a map window was actually duplicated in two places (but were not identical). 1) when clicking the Map button, and 2) when initially loading a session to set up the initial mapper panel. Now it's just in one single routine ShowMap(Value:Boolean) that is called from the docking system when loading a mapper UID window, and the button for opening/closing the map window just has the single line:

ShowMap( not(MapOn))

Getting all of the code for creating the map window into a single place was a good piece of work. Now I just need to make sure it still works when importing a 2.37 session, etc.

Time to go get some food so I can think straight again. I'll be working late on this tonight. I still really want to get something released, but I don't want to release a piece of garbage either.

Posted: Sun Jul 12, 2009 12:51 am

OK, I give up. I'm not going to rush this and end up with a piece of junk. I've got part of the mapper working again, and I actually got it to open separate map windows for multiple sessions for the first time. But I've been at this for too many hours today, and I still haven't handled the room property windows yet. Without the room property window, the mapper is pretty useless, so nobody will bother testing it anyway.

It's going to be Thursday before I get a chance to do more programming on this. But now that I'm past the main hurdle and am no longer beating my head against the wall trying to figure out the basic architecture, I think some time to think more about this will help a lot.

Sorry I didn't make the release *again*. I'm as frustrated about it as anyone else.

Posted: Sun Jul 12, 2009 1:23 am

Heh, the 3.xx beta series has had a LOT of core architecture changes, they arn't easy you've to stop thinking track a and start thinking track b.

Better & working nice >> faster releases

Don't stress over it, and thanks for keeping us in the loop.

And, nice diagram, I'm surprised it's not more... combobulated

Wizard Joined: 22 Mar 2007 Posts: 2320

Yeah, get it done right. Getting the mapper windows right will be important to the common users who will upgrade. We'll hold our frustration under control. As for the database interface, I say disable that for now. Don't tie yourself to any particular architecture with regard to the database, until you start on that project from scratch.

Posted: Sun Jul 12, 2009 4:32 am

can you use dot notation for the room properties?

MapID.zone.ROOM#?

Seems to build on the concept that rooms are just another class to hold settings in.

Posted: Sun Jul 12, 2009 6:21 am

You can use "dot" notation for some room properties using the zMapper COM API (which is available in CMUDPro even without zMapper). Download zMapper and install it to some directory and there is a zMapper.HLP help file with documentation on the COM objects and properties. I'll eventually get those entered into the online CMUD documentation also.

The syntax is something like:

#SHOW %map.GetRoom(ID).Name %map.GetRoom(ID).Desc

or you can use %map.CurRoom for the current room, etc. Lot's of stuff that can be scripted. I have no plans to make this advanced COM-based API available to normal CMUD users. Advanced map scripters have always been asked to use zMapper or CMUDPro. The Room ID value is unique across all zones in a map, so you don't need to specify a zone when accessing a room.

But this is a bit off-topic. If you have additional questions about it, please start a new topic.

Posted: Sun Jul 12, 2009 6:26 am

Posted: Sun Jul 12, 2009 9:10 pm

I actually meant that in reguards to a solution to the problem your having.
It was a suggestion more than a question, on how the room properties could know which map is was dealing with.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Posted: Thu Jul 16, 2009 7:10 pm

What makes the Room Properties especially complicated is that the RoomProp can be assigned to track a specific Location object, *or* to track a specific Map window, *or* track nothing at all (completely manual)

When the RoomProp is set to track a map window, the RoomProp updates based upon the currently selected room, and not the "tracking location" for the map. So in this case, the RoomProp doesn't have a Location object and therefore doesn't have a corresponding MUD session window.

Imagine the case of a single map window that is being shared by multiple session windows. When you click the RoomProp button in the map window, you want to create a RoomProp that is assigned to that map window and tracks the current room being selected. There are multiple sessions assigned to this, so which session gets assigned to the RoomProp window (if any)??

The Configuration window is also tricky because it the point it is called, there might not be any tracking location set up yet (a new, blank map). Somehow it still needs to determine what the active session is so it can capture the incoming text to perform the map auto-configuration. But again, multiple sessions might be sharing the single map window. How does it know which is the "active" session.

These are not un-solveable problems...they are just complicated to implement and make transparent to the end-user.

Posted: Thu Jul 16, 2009 9:42 pm

I had some time to program today and made decent progress.

I've got all of the code written now to handle the multiple Map windows, Room Property windows and the map configuration wizard. I'm in the testing phase now. Still finding a large number of bugs...some of which were also in 3.08. Especially creating new maps in new sessions and doing the initial map configuration in a new map.

The multiple window code seems to be working pretty well though.

The Room Property window tries to get the proper session by looking in either the assigned Location object, or the tracking object in the assigned Map window. If nothing is found, then it uses the current session window that has focus (or the parent window if a child capture window has focus).

For the Configuration Wizard, the current location object is used, and if it doesn't exist, it is created (which creates the initial Tracking location in the map window). This solves most of the problems with the mapper not having a Track location yet when you do the first configuration.

I also added some code for "enabling" and "disabling" location objects. Clicking the "Map Off" button in the mapper now disables the current tracking location. Doing:

#LOC name 0

also disables the location. Doing "#LOC name" will re-enable it (or using the #LOC or #TRACK commands in any way other than the above disable command).

Anyway, still work left to be done for tomorrow. Cross your fingers on a release!

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I would think that the RoomProp would just send any mud commands generated to its tracking location to handle. When it tracks nothing it has no place to send it and should disable the compass. When it tracks a Location it would send it to that Location, and the last session window that changed that Location would be the window the commands end up in. When tracking a Map window it should send the commands and the room they are generated with, the Map can then match that room to a Location or discard the commands. Basically if the RoomProp is looking at a room because a Location set it there then the commands would get sent someplace.

For your specific 1 map, many session example; the answer is no session get assigned to the RoomProp window, it is opened tracking the Map. It follows the selected room in that Map. If the selection is being updated with a Location, then the RoomProp is following that Location indirectly and the Map would forward the mud command to that Location. If the user click someplace else then there is no longer an association between selection and a Location the compass buttons can be disabled or just discard the commands.

I think the Configuration is much simpler. That window can not exist without a Map window. The commands will always be sent to the Map.

From one standpoint, the configuration does not successfully complete unless it creates a new room in the map. The requirements for the configuration to create a new room are to have a room on the map marked as the current location. Once again there is a Location connecting a session to the Map.

Since we can say it can complete without any Location, I would suggest following the InScope searching order, and search for settings of type location (including the window internal one). The first such setting found decides where the commands go.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I guess you already got to where I was headed.

Wizard Joined: 22 Mar 2007 Posts: 2320

Does this handle the case where a location object is in an external package shared by several sessions? Can multiple sessions actually share the same location?

Posted: Fri Jul 17, 2009 6:31 pm

No, the Location Objects *must* be stored within the specific session window. Only the *Map Object* can be in a shared external package. Each session window needs it's own location objects. But each location object can point to the same room on the MUD if you want.

Posted: Fri Jul 17, 2009 11:20 pm

OK, 3.09 is out for people to play with.

As usual, I'm just announcing it in the forums today. I'll update the AutoUpdate code and the other forums on Monday just in case any emergency fix is needed.

I spent all day testing this and playing on a live MUD with the mapper. I was able to successfully create a new session, start a new map, create a new configuration, map many rooms, speedwalk, use the Room Properties, etc. While I did a lot of testing, this stuff is so complicated and so many changes have been made that your mileage might vary.

As usual, please create new topics for bug reports. I'm not going to be around much this weekend, but I'll try to read posts when I can. Hopefully all of the basic architecture changes that I have made will make things more reliable and stable and won't prevent people from using it for MUDding (yeah, I probably shouldn't have said that...now I'll be cursed! )

Anyway, YES, there are STILL MORE BUGS on my list that I haven't had time to fix. So sorry if your favorite bug didn't get fixed. Right now I'm giving higher priority to bugs that also effect TeSSH and will be putting mapper bugs on a lower priority until I can get the Public Version of TeSSH released. I really need to start getting TeSSH sales to keep us going around here. But I did spend a *ton* of time on the mapper in this version to at least try to get it more useable.

Hope it mostly works for everyone.