Zugg Software :: View topic - Wish-list for zMUDXP

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I would like to see better support for the WSH, Zugg. I've been trying to get things working using the #SS, #MSS, #SCRIPT, etc, commands, and it's just so ugly and painful. I want to able to to make script files, or modules, and include them in my scripts to call functions. I want to be able to format my script in an easy-to-read manner and to share it with others easily.

I've written complex scripts in both zMUD and MUSHclient, and I definitely feel that MUSHclient is many times faster in doing similar tasks. It's more lightweight and tied more closely to the scripting engine. The next set of benchmarks that are released should not be some abc123 triggers without script code behind them. There should be complex tasks implemented in similar ways on the clients being benchmarked, and then you'll begin to see what others see in clients like MUSHclient.

I'm not giving up on zMUD, though, especially now that I've seen it's possible to use Lua code in MUSHclient to control my zMUD (i.e., automapper capabilities).

SubAdmin Joined: 18 Nov 2001 Posts: 5182

My only wish list item is also in the area of speed. I would love to see zScript kick the collective dariere's of other scripting languages in this area. To do this I think zScript has to add a a compiled script layer. This allows the interpretive nature of zScript to still be around to handle those truly complex indirect references that other languages just do not seem to be capable of. The compiled layer would take all the static text text and convert it to a shorter token form. Currently zMud spends too much time copying the text of a script from one corner of memory to another, then inserting the text for early expansion references and parsing it once again. I would like to see it setup so a shorter form can be copied about, and most of the parsing is also shortcutted in this compiled form. The compiled forms could be built on load of the .mud and also any change to a script, with lines that have indirect and mutable references being left in interpretted mode. Just my ideas on how to implement a decent speed gain, I am sure there are better ways to improve the speed though.

Beginner Joined: 07 Oct 2004 Posts: 25

Portability.

I would sell my arm for a portable version of Zmud that I could just slap on a thumdrive and move to any computer without them taking my license.

Ok, maybe not my arm, I need that to type. But certainly my leg!

Posted: Sat Sep 10, 2005 8:55 pm

Sorry, the "portable" license you mention will never happen. After all, what's to stop you from just uploading the contents of your USB drive (or thumdrive, or whatever) to the Internet, allowing anyone to use zMUD for free. You will *always* need your license.

Apprentice Joined: 29 Jul 2003 Posts: 101 Location: USA

Actually a portable license could be done like MP3 players. Just have to find out what they use to ensure that you don't switch it from device to device.

And allowing the character files to be made into plug-ins and become complied code rather than interperated code would be great too.

Don't forget zChat.

Posted: Tue Sep 13, 2005 2:01 am

Umm, what??? "could be done like MP3 players"? I have no idea what you mean by this, but MP3 players are *hardware* not just software and they can do all sorts of copy protection checks that aren't possible with software. And USB drives are a lot different than MP3 players. MP3 players are *designed* for security and copy protection issues. Portable hard drives are not.

Think about it...you have data on a portable drive. You want this data to work when you plug it into any computer. So there is *nothing* to stop someone else from making a copy of that same data and using it on their own computer. There is no way to "lock" a license to a particular USB drive. There are probably some fancy "secure drives" that offer such features, but I can't support something that I don't have and can't test.

Wanderer Joined: 11 Mar 2002 Posts: 93

I have been an avid user of zMUD for many years and will continue to do so. I have also been playing with Mushclient lately though and there are times I have said "I wish zMUD would do it this way!"

1) A hardcoded Timer section.
2) Triggers to be given a sequence number for execution. In fact the entire model for building Triggers in Mushclient would be nice in zMUD
3) Plugin capability more versatile. In Mushclient I can select the things I want in the plugin from my aliases and triggers and scripts, and it builds a plugin that can be given to numerous people. I have used this feature endlessly to build plugins for my friends who refuse to see the light and join the zMUD group. It would be nice to have that same functionality in building zMUD plugins.
4) Regular expression aliases.

Wizard Joined: 14 Oct 2000 Posts: 1368

Wanderer Joined: 11 Mar 2002 Posts: 93

1)Mushclient has a section that is specific for building timers and holding them. zMUD calls them alarms, but they are the same function.
2)Moving triggers around has -never- changed their order of execution for me in the years I have used zMUD, and has been a source of grief for me many times when I have similar triggers and need one to fire before the other. I would prefer a system of saying this trigger is priority 1, and this trigger is priority 100.
3) I know how plugins work in zMUD. However, definitional terms aside they are the same thing. In Mushclient a plugin is a set of aliases, timers, scripts as you said, that are not adopted into the core scripting of the user. They are standalone. I could say use this plugin, or don't use this plugin and it has no effect on my core scripting. In zMUD you have to import scripts which add on to your core scripting and as you said is harder to remove for novice users.
4) Command Input triggers do not have the flexibility of Regular Expression Aliases. I am sure Larkin can explain this one in great detail.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

1. I don't mind the way zMUD handles alarms. I like that I can easily create temporary alarms or that I can make a static alarm and turn it on/off. I find the way MUSHclient handles alarms to be less intuitive, to be honest.

2. I love the sequence numbering in MUSHclient, and I use it to great advantage in building some of my more advanced scripts or just in keeping groups separate and still functioning properly. Turning off the sorting and organizing them manually is not an answer, since I give or sell scripts to others who wouldn't be able to figure out that they need to do exactly that. What a pain.

3. I like MUSHclient plugins, but they, too, have limitations. I like that it's easy to load the plugin as a collection of settings and pass it around to other people to use. I don't like that the settings cannot be so easily modified and re-loaded for some plugins, and that I have less control over sequence of execution when using lots of plugins.

4. Command input triggers are useful as pass-through catches to commands, so you can override some behavior, like turning off a folder when you conjure an illusion and then turning it back on again. They're terrible, however, at matching multiple triggers on the same command and successfully gagging the command (and not any text echo'd). I tried to use command input triggers to emulate MUSHclient's regular expression aliases, and it didn't work in nearly the same way.

I've written articles on the limitations of aspects of zMUD coding and the workarounds I found for most of them. I'm hoping that these limitations are addressed in the next generation of zMUD.

Wanderer Joined: 26 May 2004 Posts: 68

Posted: Fri Sep 16, 2005 1:38 pm

Dunno if it's been mentioned in all these pages, but what I'd like is for the Inherited settings to show up in setting when you click on the folder.
Normally, if you click on the folder in settings the entire folder contents are laid out in script format.
But, for inherited scripts it's never listed in either the zMUD script or Text tabs.
I've noticed that if the only non-inherited things in there are variables, they dont display either.

So, unless i got a screwed setting somewhere, and this isn't a bug, I'd like it as a feature :-)
I like seeing the layout of scripts and since an export puts it all on one line this is a nice way to see how things are laid out.

Wanderer Joined: 26 May 2004 Posts: 68

umm... view, inherited settings? or am i missing something?

Beginner Joined: 24 Feb 2005 Posts: 27

Be nice if the database allowed fields to be displayed in a format other than simply top-down when viewing a record.

Posted: Sat Sep 17, 2005 2:04 am

Posted: Sat Sep 17, 2005 6:13 pm

You guys should really start a new thread on this. This topic is supposed to be about zMUDXP and not about problems with the existing zMUD.

Vitae, your window was empty because you selected the Class Script tab and the inherited settings are *not* part of your script. Class Script only shows your own personal settings that have been added to a class. If the Class Script showed the inherited settings, then when you exported a class and then imported again you'd get duplicates. Anyway, if you want to talk more about inherited settings, please start a new thread.

I understand that you were making a request for a zMUDXP feature, and it has been noted.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

In the xp mapper, could we be allowed to include bends in selection groups? You currently can move them individually but if you need to move an entire room or group of rooms you can't also select the bend and move it with the rooms.

Novice Joined: 17 May 2001 Posts: 40 Location: Illinois

Would there be any hope of seeing support for more scripting languages included into future versions of zMUD? I'd really love to see TCL support personally, or Bash shellscript would be nice to use too. Just more common scripting languages like the addition of VBS.

Posted: Sun Sep 18, 2005 4:20 pm

zMUD already supports *any* scripting language that is compatible with Microsoft Scripting Host, which includes VBScript, JavaScript, PerlScript, Python, ActivePHP, etc. The same will be true in zMUDXP (with even more support for these languages via the zApp system).

Newbie Joined: 07 Oct 2004 Posts: 7

Advanced search: both by type (alias, trigger, etc.) and multi keyword.

The ability to scoll child windows without text being automatically redirected to them.

Better interface for multiline triggers. As it is now you can't easily tell the trigger is multistate without specifically checking, also I don't believe the search feature searches below either the first state, or though the non-active ones.

a smart wizard for chat/tells/etc. I can't believe we have to code this stuff from zero. Even a feature like #c+ {until color changes} might help.

Atreides asked for a search for duplicates, I would add a search for near duplicates would be also helpful. One trigger might have more information than another which fires on the same thing. Maybe a feature which groups smaller triggers next to their larger included ones?

More control over creating multiple child windows.

Mapper

On Nexela's comments about the mapper, consider adding in the following, not just flying and mounted, but water rooms. We need ways to effect large groups of rooms by type. Some characters might be able to swim while others can drown. Some might need to avoid

The mapper gaining information toggles. I should be able to toggle on legends (names of rooms, geographic type, room names, mob locations, famous npcs, etc.)

make the mapper its own application. Currently, if zmud is the current application then the mapper will also be in the forefront. Often I would like the mapper to be in the background and have a webpage showing game information, a forum, or a messenger visible.

A way to code the mapper to reflect where people are when you use various locate abilities. Even if it is something like peaks at thier location, shows it on the map and you can hit a key to return to your place, or double-click on the map to go to them.

Travel modes. Drop the assumption that people walk everywhere and build in system support for other modes of travel. Teleportation, flying, running, etc.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Sorcerer Joined: 10 Oct 2000 Posts: 706 Location: USA

Zugg,
I just had an idea for a feature. How about port forwarding integrated into ZMud.
It would be a monthly charge to have. You would need to set up a machine that subscribed users can use to forward too.

Posted: Sat Sep 24, 2005 3:34 pm

What would "port forwarding" be used for? I'm not going to do anything to bypass corporate firewalls if that's what you are talking about.

Newbie Joined: 16 Aug 2005 Posts: 8

Beginner Joined: 26 Sep 2005 Posts: 14

I have two ideas.

The first is to create an option to remove the split-screen child window for scrollback. I for one find it highly annoying most of the time and would like to be able to scroll my whole window backwards.

Second is a complex feature that would be very useful, in my opinion, for MUDs of various types that have consistent output formats.

There would be an editor of sorts where you could copy and paste a block of text, for example your score screen, or an inventory, or a status display of some kind.

You would paste it into the field and then you would draw boxes around all of the areas with text you'd like to have captured each time you type the command that brings up that particular status screen.

These fields could then be populated into text boxes on a user-built tab, so at any time a user could glance at their status tab, click a button to send their various commands and get all of their data fields updated, so that they can see their vital status, inventory, money, items, etc on one screen, and they didn't have to write code to capture the text they wanted, they just drew boxes around it and dragged and dropped some text fields.