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

Posted: Sun Aug 21, 2005 5:59 am

MUDs generally default to 80characters wide wrapping, since tts what most terminals can do. Some MUDs allow you to tell them how long you'd like your text wrapped, or even better, pick it up from your terminal size via telnet options.. And some, well, don't. Getting the client to remove/ignore or newlines would make the display suck IMO, so you'd probably need to do it yourself in the room description text, and anywhere else you wanted it.

Lady C.

Beginner Joined: 07 Oct 2004 Posts: 25

There is no settable wordwrap for the mud I play (yet) and I figured if anyone could pull off newline overrides with any kind of elegance it would be Mr. Zugg.

Thought I' throw it out there

Wanderer Joined: 25 Feb 2004 Posts: 98

Below are 2 bugs that I wish would be fixed, and 2 new command ideas for the Mapper:

1. When using the Mapper, Slow Walk, and #WALK the #PAUSE command does not update the mapper location as I believe it should.

2. Below, is an example in which the Mapper creates 2 Rooms although I only #TAG a single set of name,exit,prompt.
1. I input 2 "w" at once.
2. I enter the first room.
3. My Room Trigs are hit, which TAG the name, exit, and prompt 1 time.
4. The prompt does come in the middle of Tagging, but has #NOMAP...
5. After the TAGs are done, the Mapper creates a room to the west with the TAGed info, and enters it.
6. Before the second room trigger is hit, another room is created and entered.

I am trying to stop Step 6 from occuring because it can end up creating rooms without a Name or any Exits. It should wait until another #TAG is hit before creating the second room.

New Example:
w
w
Town (e,w)
Room Trig
> No map Prompt
Name: Town Exits: e,w
On Room Create!
On Room Enter
On Room Create!
On Room Enter

3. A new mapper command to delete a room from a script.

4. A new mapper command to delete an entire zone from a script.

Thanks Zugg for all the hard work you have put into Zmud!

Magician Joined: 23 Nov 2004 Posts: 364

sorry if its been said, but the ability to map rooms with multiple descriptions would be nice. like a room with 4 or whatever possible descriptions that will be detected. also the ability to make room costs into a variable so i can set a variable for several rooms to make it different paths for aparty or for me solo.

Newbie Joined: 08 Aug 2005 Posts: 1 Location: Atlanta, GA

This is a simple request but I'd like to MUD database to be updated. For example it would be nice to have it sort the muds by type or alphabetically. Also since it feeds from MudConnector it would be nice if had most (or at least more of MudConnector DB fields) e.g. MXP, MSP support, small size, role playing enforced etc. It may even be possible to do it now (if I updated the DB Schema, dunno).

Bottomline is whenever I search for a new MUD (since I do so intermittently) I have to go MudConnect to pick it then try and find it in zMud. Thinking as a newbie (who may not even try to go to the MudConnector website) it would be good to be able to search all those features from zMud.

Novice Joined: 31 May 2003 Posts: 49

i would like an import for the mapper ... more or less like the nexela's one (it is nexela's?) but integrated ...

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

Jolopez, Charbal wrote the map utility

VTech, This is a low priority bug which has been reported and should be fixed in the next version

Posted: Thu Aug 25, 2005 4:16 pm

OK I'm probably going to get flamed, but it seems to me that to really justify a new pay-per-version version of zMUD it really needs to add a whole new level of functionality. Most of the suggestions I've seen seem to be a little too cosmetic.

I know there's a hard core base of 'long live text-based MUD'ders out there, but I'm sure it's going to continue shrinking. With zAPP and eMobious etc under development, how much time do you really want to invest in upgrading an already excellent mud client?

Maybe you should consider being part of the revolution and look at developing a whole new client & server to support a more graphics orientated mud, developing a standard that allows purchasers of your 'server' edition (in the high price bracket range) to quickly deploy WoW or EQ2 like MMORPGS that run against your ready made client, could be far more fruitfull. You could look at all kinds of licensing models... like making the client free, but MUDs sharing a proportion of their registration fees with you, as you'd control the server and client code, development the client will be much simpler - once you've got the 3D graphics engine done.

Though it would be much more work, it could be much more lucrative, and more importantly sustainable.

Anyway it's just a sugestion so please don't anyone shoot me

Posted: Sat Aug 27, 2005 1:39 am

I want to see:

Find/replace functionality for trigger modification.

Alternative exit types, such as water links which the mapper can SWIM properly through.

To the last poster: This is a wishlist thread. Please don't start derailing it.

Posted: Sat Aug 27, 2005 10:23 am

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

I'd like to see a major expansion of the zChat plugin incorperated.

One that would allow you to create your groups, and autoconnect if you'd like to them.

And being less buggy would be great too.

Newbie Joined: 29 Aug 2005 Posts: 5

I would like to see ZMud be able to connect to an irc server and join channels. I like the scripting and parsing that zmud is capable of and would love to chat using it. I know it can connect to an IRC server, but it needs to be able to join a channel. I think this functionality is probably fairly easy to develop. Maybe even in a form of a plugin.

Beginner Joined: 19 Aug 2005 Posts: 28

Wink,
Very nice idea! I'd use that too.

What I would like to see in addition to this is support for the SSH protocol. Also the ability to lose the Mud Connector DB, even if it's still there but just not shown. This would remove the "stigmata" of "game" from zMUDXP and make it a viable (in their sight) option for businesses to purchase as a telnet/SSH client.

Apprentice Joined: 06 Apr 2004 Posts: 173

1.) The command input should be on a different thread. Zmud locks at times as a result of having text being processed.

2.) A special switch on an alias called -inline- that will inline all the code that is typed from a specified alias (This would increase the speed of many of the aliases. My current system in ZMUD is at about 590kb and is kinda slow because I have set/reset aliases do all the work. I wouldn't get rid of the aliases though because it's a natural debugger.)

Apprentice Joined: 06 Apr 2004 Posts: 173

I'm not sure if this was changed, but as I recall, %match and %regex didn't have a case option, this would be very handy.

Apprentice Joined: 06 Apr 2004 Posts: 173

Apprentice Joined: 06 Apr 2004 Posts: 173

I share my mapping files between multiple characters, what would be nice if you could somehow disable certain path types based on a named command...
such as #SPEEDWALK wormhole 0 which would turn off access to the wormholes by the auto walk commands

Novice Joined: 29 Oct 2004 Posts: 34

I'd like to see buttons more customizable. Such as being able to determine their width/height by percentage. Also, I'd like to see the position of the buttons saved in settings/exports.

Apprentice Joined: 29 Jun 2001 Posts: 198 Location: USA

I would like to have some kind of controller support in such a way that the controller buttons could be mapped to MACRO keys.

Beginner Joined: 03 Sep 2004 Posts: 23

Some extra user definable fields for the mapper... A room maybe PK_OK or FAST_Regen or FLY_Only whatever, but each mud is diffrent and the ability to add fields and values (like with the database module) could prove useful to many players, simarly more user definable exit types would be equally useful, not all muds are NEWSUD plus one other command (Very similar to what you have in ZMAPPER)

Speaking of the database, an easier method to input/lookup data. Lots of time is spent explaining how to setup databases and refrence them. I would be willing to bet a large majority of the users do not use the database feature simply because it is overwhelming to them.

A method of tracking other ZMUD users who share a common map would also be nice (perhaps using zCHAT) so you could tell where party members were in the game based on thier mapper.

Ability to save logfiles as html format, would let you post your logs to web much easier if you choose to (helpful for having other trouble shoot a script as well)

Add some fixed fonts for the installation Very Happy

perhaps some users would donate some they created as well as just pointing out some licence free fonts that could be bundled. Really simple an throws a bit more flavor into the client.

A bit more power when it comes to arrays the built in arrary command is easily over run and to my knowledge there is no multidimmensional internal array system in zmud.

Local Variables to help keep down alot of the trash variables that accumulate.

Script/Settings packaging utility (It would make alot of the trouble shooting easier if you could compress all your settings in a single binary file that could be upload to the forum for other to trouble shoot script problems)

Better script importing feature that would allow users to import other client scripts easily

I doubt that porting to linux will happen anytime soon but how about a version that runs well under WINE? I currently use Linux and use VMWare to run ZMud and a couple other "gotta have apps"... but many users will not spend the $ for VMWare and WINE is free (Just a thought)

Graphic prompt substitution say your have 47/100hp have a graphic bar to represent that, that changes colors (think CPPIG but think of it in the mud prompt instead of in another window)

Bit flag decoder (56 = 111000) so you can look at each bit of the number (useful fo mud admins to be able to script a import/export feature for thier area files (to mapper and mob/object databases))

I know most of these issues can be worked around with current client however it is much harder to do and it's done with scripting instead of compiled code... Compiled code is a good thing when it comes to speed...

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

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

Posted: Mon Sep 05, 2005 3:02 am

I posted this to the wrong thread. So here it is anyhow.

If the trigger and script parser can somehow end up faster, I'd be over the moon. I don't know if that is possible or not, but a truth is that during the last six months, most of my scripting has been trying to get what I already have to operate faster. Either that or using what I've learned from doing so to write stuff that I've wanted to write for a long time but been unable to because it has created too much drag. At some times I find myself jealous of mushclient users, though not for long and not very often.

Something that would help in that, but is only partially related, is the way we can handle prompt triggers in zmud. The prompt section in preferences allows a simple prompt trigger, capturing variables, to run at a level that is much faster than a normal trigger. Unfortunately, it doesn't seem to capture non-numerical values, and it doesn't allow us to change/add to the prompt with a #SUBS command. If I could capture an alpha-numerical prompt with this AND add a timestamp to my prompt that is accurate to hundreths of a second, I'd be ecstatic. If I could change my prompt around I'd be even happier. I know it is possible as well.

Posted: Mon Sep 05, 2005 3:49 am

Why are you jealous of mushclient users? They just use the Microsoft scripting engine for scripting, which you can still do in zMUD too. Have you tried using vbscript or jscript in zMUD to see if some of your stuff is faster? zMUD scripting is optimized for many tasks, but Microsoft scripting can be faster in other cases, so it's worth a try.

Because of it's basis in zApp, you will see a lot more support for Microsoft scripting using vbscript, jscript, perlscript, or whatever in zMUDXP. In other words, you will see easier interaction between normal scripts and zMUD stuff like triggers, aliases, etc. And of course you'll be able to customize the user interface using normal scripting, just like in zApp.

Not sure why the prompt triggers run any faster...they use the same trigger engine that your normal triggers use. You can use the %secs variable in zMUD to get timing that is as accurate as Windows allows, which is about a millisecond.

Posted: Mon Sep 05, 2005 1:55 pm

Heh.. about being jealous of mushclient users, I'm not, really. I like zscript, and have no real desire to learn something else for mudding. Some people claim mushclient is faster.. I don't know whether its true or not, but thats what I was referring to (speed). It was just a joke, ... zmud -is- fast enough, providing I take care to do it all correctly. If I'm lazy, or am doing something new and havn't figured out how to do it best, the time taken to work through an alias (for example) can get a bit long. My central curing alias (IRE muds) seems to take about 0.1 secs to get through (timed with %secs at start and end). This sounds miniscule, but combat is fast-paced on IRE muds, particularly imperian, and I ended up having to add something that would limit the time between how often the alias could be called by triggers. . Just an example. I get told by the odd mushclient user I know that their client is faster and that if I switched I wouldn't have to worry about speed so much. The ease of use and features that zmud offers outweighs that benefit though, even if it really is as they say.

[edited to add:] Although.. to be honest, I did not realise that scripting in different langauges in zmud would make for faster script execution. I thought that feature was only there for those more comfortable with other languages. So... maybe I will give it a shot. I learned a little python a few years back and could probably manage to convert a couple of the 'choke point' aliases over to it. Thanks!

So far as prompt trigs go.. the timestamp is great. I have it going already.
#SUBS {prompt pattern} {H:%ansi(10)%1%ansi(white)/%ansi(13)%2 ~<%5 %6~> %time(hh:mm:ss).%secs}

Works great, and I'm addicted to it.. its so useful when working through logs of fights. The help file for #SETPROMPT