Zugg Software :: View topic

Posted: Thu May 18, 2006 4:58 am

OK, we need to have a discussion about "child capture windows" and associated packages in CMUD. I've gone around and around in thinking about this and just can't get my head around it. So, I'm looking for input on how to handle this problem.

Here is the issue: In zMUD you could create a "child" window using the #WINDOW command, or the #CAPTURE command. You could then send text received from the MUD to these other windows, or send commands to them using the syntax:

windowname: command

In zMUD, when you first create one of these child windows, zMUD loads a *.MUD settings file with the same name as the window. So if you do:

#CAPTURE tells

then zMUD will create a new window called "tells" and load the TELLS.MUD setting file into it. This settings file allows you to customize the colors of the window, set up triggers for the window, etc.

However, the child window can also still access settings in the main MUD window (that's what makes it a "child" of the main window). For example, if you access a variable in a child window script and the variable doesn't exist locally within the child window settings, then zMUD checks for the variable in the main MUD window.

OK, now let's think about CMUD. In CMUD you have "packages" instead of *.MUD settings files. In some ways, a *.pkg package file is similar to a *.mud settings file. Both can contain aliases, triggers, macros, buttons, etc.

However, rather than having a single *.MUD file for each window, CMUD lets you load a list of packages for your main window, and all of the packages are stored in a single in-memory database of settings. So, in a way, a package in CMUD is also like a "class folder" in zMUD.

Now, I can see two ways to handle child windows in CMUD:

(1) The first way is like zMUD. When a child window is created, it would load a package file associated with that window. The package would only be active for scripts running from that window, but the packages for the main MUD window would also still be accessible from the child window package. This is the most straightforward approach, most similar to zMUD, and probably the easiest to implement.

To summarize this option, the *window* caused the package associated with that window to be loaded. So the window comes first, and then it loads it's package.

(2) OK, there is another way to do this. In this second approach, a window becomes *part* of a package. In other words, if you want a "tells" window, then you load the "tells" package as part of your list of packages. When the Tells package is loaded, it then creates the child window (and any other windows that it needs), along with any needed triggers, aliases, macros, etc.

With this method, the package is loaded first, and it then creates the child window. Everything that is published by the package is accessible to the main MUD window. The child window has access to the package that loaded it, along with anything published in any other loaded packages.

This method allows package developers to include child windows as part of their functionality. For example, I can imagine a "Tells" package that contains the window along with all of the triggers needed to capture text to the window.

---
OK, at first glance these two options sound very similar. And even though (1) is what we are used to in zMUD, (2) starts to sound pretty appealing. And from the end-user point of view, there isn't much difference.

So I was going to implement (2) until I ran into a problem...what if you want more than one child window of the same package. For example, what if you wanted two different "tells" windows. With (1) it's no problem. Each window happens to load the same package file, so you have two copies in memory, each with their own settings, variables, etc, just like you want. However in (2) you can't load the same package twice. It would cause a conflict in alias and variable namings. A single variable name would be used in two packages and would cause confusion. Only one of the windows would probably end up working correctly.

Then again, why would someone ever want two different "tells" windows? They might have a "tell" window, along with a "guild" window and maybe an "auction" window. These are all pretty similar, with just slightly different triggers.

I think maybe I've just thought about this all too much and have gotten myself confused and twisted around. The problem is that the implementation of these two methods is completely different.

Perhaps I'll just implement (1) for now, since it's easiest and closest to existing zMUD code and worry about (2) later.

Comments are welcome.

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

I think if you considered a package as a "class" in the OO sense of the word, then #2 would fall in line fairly easily?

What I mean is, you write your "comms capture package" which is like writing the TCommsCapture class, then (using C++ syntax) you would go TCommsCapture tccInstance1 = new TCommsCapture( with some intiializers );

Bringing this over to CMUD and how these packages are kinda 'non-volatile' when you install TCommsCapture it asks you "what channel do you want to capture" and "what is its pattern" and then you could create a "Guild" and a "Tells" and a "OOC" instance of TCommsCapture, each with their own set of associated variables.

So maybe they get installed as /rainchild/commspkg/guild and /rainchild/commspkg/tells and /rainchild/commspkg/ooc?

I certainly think that per "main mud window" you're going to need to keep the packages separate - eg if I'm playing 2 different muds and using the "auto-heal bot" on both, you don't want the hitpoint totals getting confused between the two different muds...

So does that mean things like that needs to save variables to the main MUD window instead of its own package? ie do we save it as /@hp instead of @hp? Or should there be some kind of flag to say 'this is a volatile variable and needs to be stored for each instance of the package' and somehow manage it that way? ie it's stored in the main MUD window's package but it overrides /rainchild/healbot/hp

Packages may be a little trickier than we first expected.

As for chicken and the egg... won't the package call #WINDOW which means the package owns the window. But at the same time, the window will have its own child-package too.. so

TCommsCapture.pkg -> #WINDOW Tells which then loads Tells.pkg

Although be careful about naming conventions of packages, it probably be better for it to be MudName.CharacterName.TCommsCapture.Windows.Tells.pkg or something?

Magician Joined: 29 Nov 2005 Posts: 482

I will have to think on this more. My initial thought is i currently have anywhere from 7-15 different child windows like this

I.E. My comm
Auctions
Tells
Clantalk
Pktalk
Archon Talk
Betters
Gained
so on and so forth
I would like to make this one package that creates all the windows for the user and loads all settings needed for those windows. I would definatly want those windows as part of a package. I cant imagine why i would ever need to load the same package twice on the same character. For example two tell windows. I cant imagine why you would have that. Anything that needed to be done could be added to the original package and thusly no need for a second window that processes tells as well. I will think on it more and give a better reply. I am sure i am missing part of what you are trying to say since its like 4am

Posted: Thu May 18, 2006 8:29 am

Yeah, I should go to bed too ;)

Rainchild, don't worry, each main MUD window is totally seperate. The in-memory database of packages that I talk about is actually created for each main MUD window. So if you are playing two different characters sessions, they each have their own packages and cannot communicate with each other. This is like in zMUD where each main window has it's own *.MUD settings and can't talk to the other session.

Now, zMUD added some syntax for accessing variables and things in other sessions which CMUD doesn't have at this time. That will have to come later.

So for now we just need to worry about Child Windows.

Oh, and also there will eventually be a "blurring" between these types of windows. In the future you will be able to attach a child window to a different host and port number, just as if it was a different MUD session. But this would still be considered a "child window" of the main session. It would allow you to have multiple characters all within a single main window and single set of packages. But that's a complexity that will be added later.

Posted: Thu May 18, 2006 4:02 pm

I think you have thought about it too much. Forget about the loading of two windows with the same name I can't see a reason for this. Having read your initial paragraph for each method I believe that number two is definitely the better method.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

I can't see any reason for having 2 windows of the same name. It would be confusing and counter-intuitive to the way most people would set things up and you probably won't find hardly any people using a setup like this in the field.

Posted: Thu May 18, 2006 7:20 pm

I may be missing something obvious, but taking Rainchilds OO analogy and turning into something a bit more CMUD-like...

Why not simply treat the child windows as a UI component in the same way that buttons and status windows are? That way it doesn't matter what the window is called or how many there are, as long as any that have the same name have different IDs. Wouldn't that allow option 2 safely?

If I remember correctly (and I can't remember where I read it), Zugg said there aren't any trigger states in CMUD, but instead there are sub triggers - so you could have triggers treat child windows as a trigger that always matches text but only in the child window, so the sub triggers placed under it will only ever come into play for the child window. Or something less kludged that works out the same way.

Or, if the code can handle it, you could always make the child window a combination of UI component and folder. Give it a different icon in the editor and extra options appropriate to windows, and since it is a folder it can contain any other settings anyway.

EDIT: Corrected a typo and clarified sub-trigger bit.

Posted: Thu May 18, 2006 8:45 pm

Posted: Thu May 18, 2006 9:54 pm

I think at that point though they are child windows of seperate mud windows and so would not get mixed up. At least that's what I've inferred from what Zugg has said above.

Magician Joined: 17 Oct 2001 Posts: 371 Location: USA

I think, that #2 is the better solution. I've been building some fairly advanced zMUD scripts/plugins for Dragonrealms for a while now (off again, on again - mostly in the summers when I'm off from college), and child windows have always confused me. I think going with the second option would be less confusing than the first.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I will also support #2. All manner of graphical display items are handled by settings, and child windows should not be an exception. The point of 2 child windows by the same name should be handled carefully though.

I can see multiplaying 2 characters on the same MUD, and splitting off 'tells' by trigger into seperate windows. In this case those lines are completely independent of the MUD and the relationship is only to the parent window. That relationship needs to be reflected in the display of the window.

I might handle another channel on that MUD into a seperate window, but my multiplaying system would have both players seeing that channel. In this case I want the overlap and just one window. That means another user controllable item about whether it is a 'shared' window or 'exclusive'. Including an owner or parent window name in the title of the window is a big benefit, especially if it is done in such a way that one session can refer to another session's child windows. If I am playing 2 seperate characters at once it is because there is some relationship between the 2, and I do not a programatical barrier to be introduced simply because that relationship can not be understood.

In general, if someone is playing 2 separate MUD's (based on IP address) then any windows of the same name between those sessions should be treated seperately. They represent separate data streams. When both sessions are on the same MUD then those child windows may represent the same data stream. I think this is best handled through a user flag on the setting that creates the child window. Imagine 2 packet sets for the next series of examples.

A. Set 1 creates child window 'XYZ' flagged shared, working IP 127.0.0.1; Set 2 creates child window 'XYZ' flagged shared, working IP 127.0.0.1. Name, IP and both are flagged as shared, both sets share the child window, set 2 never creates another window.
B. Set 1 creates child window 'XYZ' flagged shared, working IP 127.0.0.1; Set 2 creates child window 'XYZ' flagged shared, working IP 127.0.0.2. Name matches, IP does not, and both are flagged as shared; child windows are treated seperately, set 2 creates its own child. They are distinct data streams because of different source IP's. Allow scripts to overcome this if it is really needed.
C. Set 1 creates child window 'XYZ' flagged non-shared, working IP 127.0.0.1; Set 2 creates child window 'XYZ' flagged shared, working IP 127.0.0.1. One or both of the windows was flagged non-shared; set 2 should create its own child, and naming aside set 2 should be able to send data to its child without any knowledge of set 1's child.

----
While those are my full thoughts on how it should really be able to work I haven't quite thought about how to do that. Rough idea is that a child window as a setting would have that shared flag. That setting would register the child window name for use with the existing @window.name syntax. At the same time the rules I sort of laid out would be used to determine whether to change the title of the existing window, create a new window, or create a new window with title changes to 2 windows so a user knows what is where.

The registration would determine where to look for a setting referenced by the @window.name syntax, and in the case of duplicates that duplicate would have to be spelled out during referencing; 'ABCDEEFG' creates child window 'XYZ' then seeks to reference a variable from child 'XYZ' created by 'DEFGHIJKLM'. Because the user is playing MUD's tha don't meet sharing rules outlined let them add the extra bit to interface the seperate child windows, or specify that 1 'guild' window will do through a #WINDOW ABCDEFG.name syntax. I really think the burden should be on those that play more then 1 distinct mud at once. In all other case a simple set of rules suffices, so long as overrides are available and documented.

The true rub is that even if child windows become a new category of setting, a series of default will have to be chosen for those instances when a new user finds and uses the #CAPTURE command and doesn't specifically create the child window setting. Those windows will have to be created on the fly and I think the rules I outlined will work with a default of shared for such instances.

Posted: Fri May 19, 2006 4:16 am

OK, I'll see if I can implement method 2.

As asira surmised, this is basically done by making windows a new "settings" type, just like buttons or status bar items. So, you'd have a package called "TELLS.PKG" which would contain a "window" item, along with a trigger to perform the capturing.

Any text received in this window would get processed with the package set as the current default. Sort of like using the #CLASS command. In fact, CMUD has a #PACKAGE command which is similar and is used to enable/disable packages and to set the current default package. Setting the current package manually is something that you'd probably never need to do. So when text is received in the window object, only the triggers within that package will see it and fire.

Vijilante, the idea of "shared" windows will have to wait. Right now each MUD session is completely separate. Almost in terms of running two separate copies of CMUD (but not quite). There is a lot more seperation between sessions in CMUD than in zMUD because of the database issues.

Rather than have two different sessions and then having a "shared" window, what I'd prefer to see people do is just open up multiple child windows and then attach each child window to a different hostname/port.

In other words, you would really set up a "package" for each of your characters. Associated with that package is your window for that host/port. Then you create a single "session" that loads the packages for each character. This gives you a connection to both MUDs, but within the same "session". Whenever you load that session icon from the main startup screen, you get connected to both characters.

Your window docking layout is associated with the *session* and not with the package. So you can have a "multiplayer session" that opens two different character packages with a docking layout that handles all of the windows, and you can have a separate "single player" session that just opens one character package with a different docking layout. This makes it easy and straightforward, unlike how zMUD handled multiple sessions. It also gives you *complete* flexibility over window layouts. In zMUD, you were forced to have multiple sessions in different "master tabs". There was no way to have one session docked right next to another.

In this scenario, you don't need shared windows. Within the "multiplayer" session, a window can be accessed by either package and you can have a master "tells" window if you'd like. If you want to keep the "Tells" windows separate, then name them differently for each character.

In any case, in method (2) you can't have the @window.name syntax. In method (2), windows do not contain settings. Instead, you would refer to the package that created the window. For example, if you wanted to access a variable in the "Tells" package that created the "Tells" window, then you use the normal @Tells/VarName syntax, just like accessing anything within a class or package. So the other advantage of (2) is that we don't need yet-another-syntax for referencing variables.

Of course, this also means that existing scripts that use the @window.varname syntax will break.

Handling the #CAPTURE command default isn't much of a problem. The window would just get created within the current package. All I need to do is make sure it doesn't process the triggers in the package for the window in this case or else there might be an infinite trigger loop.

Anyway, remember the rule: SIMPLE SIMPLE SIMPLE. I know that some of you are programmers, but we need to keep this simple. I'm not going to get into stuff like OOC right now.

Wizard Joined: 14 Aug 2004 Posts: 1269

I think option 2 is easier to understand, more logical (especially for people who haven't used zMUD) and more powerful, although it will mean more settings changes for some people.

Rainchild, a MUD can have more than 1 IP address (particularly if it has linked servers) so revolving around IP address won't catch every situation. Anyway, it doesn't sound like your approach is needed, using the method of naming the windows differently.

Newbie Joined: 17 Jun 2005 Posts: 7

I think that everyone can handle their second tells window being called tells2.

Beginner Joined: 18 Aug 2005 Posts: 15

I apologise if I'm re-iterating any of the above, its been a very long day, and I'm replying to Zugg's original post....

As I understand it (I'm tired, so tell me if I've got it wrapped round my neck), the questio concerns wether the parent window owns the derivation type, and then the 'child' window uses a derivation type within the parent to create itself, or, the chilc has its own personalised details.

This makes me think of inheritance, both single and multiple, and interfaces. what I would wish is multiple inheritance (not behind the scenes perhaps, but for the user/developer). To give an example (Ill use pseudo code rather than ZMud command to prove what i mean in abstract):-

#WINDOW Name package
- Creates a Window which uses that package, no inheritance

#CHILD Name package
- A child of the window it's being created from. the package is its first port of call, if the trigger/command isnt matched it looks to the parent.

#CHILD Name package parent
- As above, but becomes a child of the named parent, rather than the current one

All the above give the base inheritance (single inheritance if you like, or sngle interface)

Then have a 2nd line, identifying the Windoe by name, ID or whatever....

#INHERITS None/[package, package 2, package 3, etc]

This would extend the window/child, giveing it the abilities of the inherited packages, with the packages considered in order (first quoted to last) - ths could be built into the create command perhaps as a shortcut

#UNINHERIT PARENT/package
Tells the window to remove either the parent, of a named package from its consideration.

Sorry, I'm very tired, I haven't explained it very well, but I hope you could see how versitile this could be.... eg a plugin could script #INHERITS None at the start to start their window designs from scratch, but it's own child windows would be #INHERTTS Parent, or not

Yours,

Elkestra

Posted: Sat Jun 10, 2006 11:14 pm

Well, you'll see more of how this works when it's released on Monday.

First, I can't use the syntax that you mentioned because the #WINDOW command is already used in CMUD (compatible with the Window command in zMUD). The second parameter can't be a package name because that's normally used to specify the text to send to the window.

Using #WINDOW to create a window works just like in zMUD and makes it a child of the current package, unless a *.pkg or *.mud file with the same name as the window exists. If a pkg or mud file is found for the window, then a new package is created using the pkg or mud file, and the window then becomes part of the package.

The important thing I decided in the implementation is that windows are owned by packages. This is the reverse of zMUD. In zMUD, a window owned it's *.mud settings file (which is similar to a package).

So, windows are no longer children of other windows...they are children of packages. You don't create a window and tell it what package to load...you load a package that contains a window object.

I'll be adding some sort of command line syntax to make this easier in the future. But it was important to maintain some capability with the existing #WINDOW command even though things in CMUD work differently.

I'm sure this is one of the big things I'll be working the bugs out during the beta process. It's difficult thinking about this in the reverse way as zMUD.

Beginner Joined: 18 Aug 2005 Posts: 15

Sorry, I did say I was using 'pseudo-code', as in that it probably (almost certainly) wouldn't be #WINDOW etc, it was more to describe a methodology.

Apologies for the confusion, I was tired when I wrote the post.

Yours,

Elkestra