Hi there. So let me get this straight.

[tsuujin]

I think he's asking for what I asked for: the option to see all elements of your system in a single view, rather than be restricted to only viewing aliases.

I spend too much time, myself, going back and forth between views when I design new system elements.

[demonnic]

For most of this, if you really really want to, you -can- make this happen. Quite a great many of your triggers can be scriipted in Lua rather than input into the gui. For that matter, all of your aliases, timers, keys, etc can be made using lua function calls, so that if you really want it all in one sheet, you can do that.

The one exception I can think of is I do not believe there is currently any way to truly work with some of the features of the trigger engine. Parent-child relationships aren't accounted for in the Lua functions available, I don't think. It's possible you could do something like that, if the api were expanded to account for it, but I don't know how difficult that would be to do.

But really, you -can- keep each thing contained in one file in the script editor. Which is syntax highlighted, though if you do it all in lua you could use any editor you wanted, with or without syntax highlighting.

[Heiko]

Anybody can submit a patch if he really wants this feature as long as the combined view remains an option because I'm sure that most people are happy with the way it's done right now. Keep in mind that the current GUI has been extensively discussed by many people with different client backgrounds in the starting phase of Mudlet.
My questions regarding a combined view as I have not been a ZMud/CMud user:
How do you want to handle the display of trigger chains and filters in a truely mixed view?
If you chose to use a giant tree view to display everything as seperate root nodes, don't you think that scrolling back and forth in a huge tree is *far* more time consuming than clicking a single button and switch to where you are working on directly instead of scrolling and searching?

[Knute]

The one exception I can think of is I do not believe there is currently any way to truly work with some of the features of the trigger engine. Parent-child relationships aren't accounted for in the Lua functions available, I don't think. It's possible you could do something like that, if the api were expanded to account for it, but I don't know how difficult that would be to do.

Actually, the Parent-child relationships ARE available. If you look at the permAlias, and the different permTriggers, the first option is the name of the trigger or alias, and the second is the name of the parent.

What isn't available is setting some of the other trigger types that are available in the gui, such as lua function. The issue that I see with that is that the permTriggers are hardcoded for various types: permRegexTrigger, permSubstringTrigger, permBeginOfLineStringTrigger. Those are the only 3 types directly available to scripting. So if you needed to set up a permLuaFunctionTrigger, you can't. At least not directly from the script.

When I asked how to do it, I was told to simply set it up through the gui. So the argument that it can ALL be done via scripting is a falsehood. At least at this particular time in mudlet's development, it is.

[Vadi]

People just don't understand that grouping in Mudlet serves more purposes than organization for the user, I suspect. The fact that alias groups can have regexes (which is -not- a UI bug) which will filter them down, triggers can be chained/filtered, and etc, makes organization of very different IO elements into one thing just quite confusing...

[Markus Ramikin]

Why is that mutually exclusive?

Besides, it's not "more" purposes, it's "different" purposes. As far as I'm concerned, the purpose of user organisation isn't served by this, by having a separate list of aliases (unrelated to each other), triggers (unrelated to each other) etc instead of classes/scripts containing everything relevant to a given purpose.

So this setup lets you filter through aliases. That's great, but if everything logically relevant to a given script was within that script's folder, you wouldn't need to filter through them in the first place. No other aliases would be cluttering up your view.

Also could someone please explain to me what I asked for before, how to export a script in a way that will work on someone else's mudlet. I mean, do I have to manually hunt down all those aliases and triggers that the script relies on and export those too, or what.

[Vadi]

Filtering in the sense of alias parsing. If you put aliases into one with a pattern, they won't be given a chance to match unless the parent matches.

[tsuujin]

My main complaint is that I structure everything as packages or objects. When I navigate to bushido->ui->Map I'd like to see -everything- related to the map. Triggers, aliases, scripts, keybindings. Everything. I find it harder to work on my system when I have to switch back and forth from scripts to triggers to aliases to see everything. Particularly because the views maintain different tree states, so when I start working on a system I have to navigate through my tree view three or four times to get where I want to be.

When a system gets large and confusing, much of that confusion can be eliminated by structuring everything into package-esque folders, and opening up that one particular folder contains everything that system does.

[Caled]

It took me a long time to get used to the mudlet script editor, which in my opinion is second in usability to only CMUD. You do get used to it; but it is a case of just becoming resigned to the fact that it has to be endured.

The biggest problem is sharing scripts. There are a couple of user-written scripts that allow for package-building (crucible and that one before that which is somewhere in the scripts section of the forum). I've never managed to get either to work though. If I want to share a script with multiple elements, I have to delete everything except those elements and then do a save as.

In CMUD I do something like this:

Package: AutoSipper
Class: Triggers
Class: Controls (Aliases)
Class: Scripts (Functions, variables and events )
Class: GUI

The "Package" can either be an actual package file, which is a self-contained file that can be published to the web through the menu bar, or it could just be another class, in which case I can right click that class and "Export" or "Save as XML" (It has been a couple of years and I've forgotten the precise process).

Perhaps the easiest solution, and I aim this suggestion at anyone with the ability and inclination to do as Heiko suggests and submit a patch, would be to add an an extra field to each element group (i.e. alias groups, triggers groups etc) where you can commit a group and its contents to a package.

Then up in the menu, "export package."

The convenience of the GUI system is another issue entirely, and while it would be nice you do get used to it as I said. I certainly don't want Heiko spending time on it rather than the mapper. I feel guilty saying that because I really wish I could help out myself.


Regarding the text display:
If that is really, really important to you, I suggest maybe learning Tinyfugue instead of Mudlet.

[tsuujin]

I just wish I could get the most recent codebase and just dig into it myself. I just don't feel like making that kind of change on old code.