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

Posted: Wed Dec 07, 2005 9:51 pm

Volume controle for media, and perhaps an if check for volume would be nice, too. Based on percentage to max. So:

#alarm 16:00:00 {#if {%volume>55}} {#play alarm.mp3}

or

#action {^(%w) tells you 'wake up'$} {#volume 70;#play wakeup.mp3}

That sort of thing. I personally use a lot of audible alerting triggers to let me know when things are going on on my MUD, and it would be very nice if I could make the volume on some more prominent than others :P

Posted: Thu Dec 08, 2005 6:28 pm

Try using MSP commands to play your sounds. You can echo MSP commands to the screen, or use the #MXP command along with the MSP support in MXP (read the MXP spec for details). The MSP spec has volume control in it and works great in zMUD. Use the !!MUSIC command in MSP to play anything other than WAV files. The !!MUSIC command sends the file straight to the Windows media drivers, so if you have an MP3 driver installed, that's what you want to use. The !!SOUND command only handles 8-bit uncompressed wave files via an internal wav mixer in zMUD, so it won't handle MP3.

(if you are confused, start a different thread topic on this and I'm sure you'll get more help)

Posted: Thu Dec 15, 2005 7:13 am

I would like to see the 1 line buffer space removed... seems to fluctuate between 1-2 lines depending on how you have your windows... 0-1 would be nicer. This buffer line seems to appear in all the windows (status, child, editor), except for the main one... where it shows the prompt.

Beginner Joined: 23 Mar 2003 Posts: 28

As Larkin and others have stated, I also wish for RegEx Aliases.

On a similar note, I also wish the new ZMud will be able to evaluate multiline triggers (regex and otherwise) efficiently, quickly, and correctly.
This of course also includes the complex multiline triggers that you can construct using regex.
EDIT: I have to say though, even Mushclient failed in regard to multiline triggers. The behavior was very...erratic and it enforced a rigid structure to the trigger pattern (Ie: The EXACT number of lines the trigger will take up)

Automatic logging should be possible without the use of the onconnect and ondisconnect aliases and, as previously mentioned, HTML logging would be nice.

GUI changes would be nice too, like no more moving windows completely off the screen (I did that with one of my windows and I could never get it back :( ). Also, when Im looking at the triggers window and I alt tab into another program and then alt tab back, it'd be nice to still be in the trigger window and not the mud output.

The way variables are handled is also confusing and it'd be nice to have it simplified. Like, when I wrote scripts inside of a class that assigned to variables it was very erratic about where those variables were created. Sometimes it created it in that class, sometimes in the global, and then it switched and I had variables all over the place. Then the scripts got confused as to which variable to refer to (or I did) and weird things happened. (In the end I had to manually delete all the variables in the global and remake them all into the class) Anyways, it would be nice to be able to have documentation that tells me about the nuances of variables and their interactions with classes. Maybe have it so by default you can only refer to variables within the SAME CLASS as the alias/trigger/whatever you're writing, and then to use others to EXPLICITLY import it by specifying the class where it is located and the variables name. That would simplify things.

Also as said by Larkin, a system by which you can specify the priority of aliases/triggers/alarms would be nice. I was initially just going to say this for aliases but I think it should just exist for everything else to since it is very useful.

That's all that I can remember right now about ZMud that I wanted changed.

Posted: Fri Jan 27, 2006 10:06 pm

When a window gets moved off the edge of the screen, use the Reset Window command in the Window menu (or might be the Layout menu) to reset it back onto the main screen.

For multi-line triggers, I doubt things will change for a long time. The problem is that you can't just let the triggers look at an infinite amount of text in the scrollback buffer since this will take way too much time. So you need *some* sort of structure to your trigger.

With regular zMUD triggers, you can put a $ in them to represent a line-break. The better way to handle multi-line stuff is using the Trigger Conditions in zMUD where you can specify exactly what should be on multiple lines.

If it's just an issue of not knowing where the MUD will wrap a line, I'm planning some features to "unwrap" MUD text so that a trigger will think that everything is still on a single line. But this probably isn't going to work on every MUD since it's very hard to do. Anyway, just didn't want you to get your hopes up on this one.

Ragarding the variables, take a look at the Introduction to Classes section of the help file. It explains how variables are created relative to the current class and how you can force which class something gets created in. This can get complex, but understanding this is really important for complex scripts. And I don't plan to change how this works in CMUD. It's very well defined where variables are created once you understand it. If you want more discussion of this, post a new topic and I'm sure the Gurus can help you more with it.

Beginner Joined: 23 Mar 2003 Posts: 28

Fair enough on the variables and multi line triggers.

EDIT: Though on multi line triggers I think you could make it managable by having a "within x lines" parameter, please note the within, I'd have to see a remake of mushclients "x line" parameter, that...just sucked.

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

We have that already. It's called Within Lines. You then type a number in the Param field, which on the States tab is the very next field after the state type.

For a more comprehensive look at trigger state types, look in the help file under Trigger Command Options (there's a link to it from the #TRIGGER helpfile).

Beginner Joined: 23 Mar 2003 Posts: 28

Posted: Sat Jan 28, 2006 1:27 am

You should start a new topic to discuss this particular trigger. You really need to do this with 2 triggers. Since, as you said

Beginner Joined: 23 Mar 2003 Posts: 28

Posted: Tue Jan 31, 2006 10:48 pm

I would like to see

1) Improved support for other room exits types.

User defined "other" exit types and their commands eg in, out, hidden, password, crawl space, climb

Alternative icons for these "other" room exits, either pre-defined or user-defined.

2) Customisable room flags to supplement the room type.

First the user would define a list of room flags eg Has a store, Is dark, Can scavage forewood, Can enter wilderness.

Then for each room, user can tick which flags apply to that location.

On the map, either a single bitmap is used to indicate room has flags set, and holding mouse over location lists room name and its flags.
Or each flag has user-defined bitmap which are shown in map square.

Posted: Wed Feb 01, 2006 3:59 am

You can already do (1) "other" room types in zMUD. Post a question to the forum and I'm sure someone can help more.

For alternative icons, you need zMapper.

For (2) you can do this with the user-defined room types in zMapper. With the zMapper room types and the expanded COM-based programming that zMapper adds to zMUD, you can do lots of fancy stuff like you are asking about.

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

Not sure if this has been mentionned but:

A way to script so you can disconnect from a mud and not have the window pop up for auto re-connection.

I have an engineer character that has 3 tasks to do over 6 hours so I wish to disconnect in 6 hours and not reconnect.
Currently I am using an #ALARM with #DISC and #IG so when it tries to autoreconnect it doesn't log in. An hour later the mud drops the connection and it tries to relog back in for another hour of idle at "what is your name"

Then when I wake up I log back in and give it more tasks to do for the next 8-10 hours, at which time I wish it to disconnect again.

//

Also useful for places where you want to disconnect when you are dying of thirst/hunger/etc as you are not there at the keyboard.

Wanderer Joined: 01 Aug 2005 Posts: 76

I tell you what I'd love, I'd love for the auto-indenting feature in aliases and triggers to work correctly. As it is, its very buggy and idents strangely in different situations. The idea behind auto-indenting is to automate some of the formatting for the writer, to aid in reading the code. That is thrown out the window when the auto-indenting doesn't work right to being with.

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

Maybe a different way to refresh buttons.

When I unbutton every single button gets refreshed (This UI has about 50)

Maybe a way to only refresh the various button panels if the height has changed from a panel above it and/or just refresh the panel where the button has been deleted from.

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

Posted: Thu Feb 02, 2006 8:27 pm

TonDiening: You'll be able to change *any* preference in CMUD using the new %pref function. So, to turn off the auto-connection within a script, you can just do %pref("autoconnect",0) to turn if off, and %pref("autoconnect",1) to turn it back on again.

As far as button refresh, it's definitely something I'm looking into because it is one of the major slow-downs in the UI. zMUD doesn't know which buttons are related to which variables, so when a variable changes it has to update all buttons. In CMUD I'm thinking about some algorithms to keep track of the relation between buttons and variables to improve this.

Larkin: As I mentioned, you might want to start a regular thread on this. There are several tips on using "other" exits that can be suggested to help. I don't have any trouble with in/out exits at all.

Newbie Joined: 03 Feb 2006 Posts: 6

To be able to permanently turn splitscreen off so it doesn't activate when you scroll. Also when you do scroll up it will stay fixed on that text but will resume syncing the scroll with new text when you scroll all the way to the bottom like mIrc.

See this thread:
http://forums.zuggsoft.com/phpbb/viewtopic.php?t=23005

You used to be able to do this with an old version of zmud by dragging the SS bar to the bottom and messing with some scrollback/que setting.

Posted: Sun Feb 05, 2006 3:19 am

I don't have any plans to change the split screen function. The way to handle this is to drag the split bar to the bottom so that you don't see the live text. The fact that the scrollback stays frozen and doesn't unsplit when you scroll down to the bottom is something that I'll consider fixing.

But you are probably the only person I can think of who doesn't like the split screen feature in zMUD. It's one of the most popular features. The ability to see the live text while scrolling back, and having the scrollback frozen so that it doesn't scroll with the live text has saved me from getting killed many times as a mob enters the room while I'm reading the scrollback.

Actually, if you drag the scrollbar to the bottom, it *does* unsplit the screen. It's only the PgUp/PgDown keys that do not unsplit the screen. Also, there are several keyboard shortcuts to control the split screen: Ctrl-Z and the Scroll keys on the keyboard will both toggle it.

Newbie Joined: 03 Feb 2006 Posts: 6

Yeah dragging the scrollbar to the bottom unspilts but if you use the mouse wheel scrolling with it down to the bottom doesn't.

I like the spilt screen and use it occasionally but I find it easier to quickly scan large swathes of text scrolling up when I have all my screen to do it. Especially if I'm playing in a small window while doing other things. If it just unsplit by scrolling all the way down with the mouse wheel it would give someone the option to use it or not by dragging the split bar down and not have to actually click the scrollbar or use shortcuts.

Apprentice Joined: 11 Apr 2003 Posts: 119 Location: Sweden

I want local temporary variables in triggers and alias. Admittedly this is idea came to me because of my anal sense of tidiness and that I don’t want to have a ton of temporary variables littering around my settings or having to “manually” delete them every time in my scripts. But I thought about it some more and think that it will actually result in a speed increase.

An analogy:
Think assembler and the local registers you have available so you don’t have to do expensive calls to memory all the time you wish to store a value for a split second.

So how does this translate to zMUD (or well cMUD). To my understanding do you (in zMUD) do several more or less expensive checks every time a, normal global, variable are changed. For example: you check to see if the variable is used in any gauge or similar control that will need to be updated because of our change. These checks do not have to be done on any local temporary variables since they are exactly that, local and temporary for the script we are currently executing.

Granted any speed increase will only be noticeable in more advanced scripts and you might argue that not enough of your customer base is that advanced but I beg to differ.
I give you two reasons:

You don’t have to get terribly complicated to want to have a temporary variable, try for example to do a little formatting on a few variables and then display the string somewhere. Unless you are willing to do it all in one long unreadable line then must you divide the task into several commands and introduce temporary variables.
Secondly and more importantly is the introducing of the “script repository” that you have been announcing. This will without a doubt spread pretty advanced scripts to a large portion of the userbase.

Conclusion: More and more people will use more complex and advanced scripts, it’s in your best interest to provide us the tools to create scripts which will be possible to execute faster and local temporary variables is such a tool. This is of course unless you have an even better solution at hand.

Posted: Sun Feb 05, 2006 9:08 pm

Temporary variables and aliases (and any other type of setting) is definitely planned for CMUD and will probably be in one of the early beta releases. And you are exactly right...local variables will be much faster than normal variables.

Novice Joined: 06 Feb 2006 Posts: 48

I think it would be useful for the zmud mapper configuration to have an additional section for "weather" or something, as a lot of muds seem to have stuff between the actual room description and the room exits or whatever that will change, and it seems to screw up checking for room descriptions. Perhaps with an option to not check the last X lines of description.

Newbie Joined: 06 Feb 2006 Posts: 5

I dont know if it has been mentioned.. Theres 15 pages here to go through..

When using automapper:

1) Have the ability to change background color, and KEEP it at the same color setting each time we load it up
2) The ability to "print" out the maps with the printer (a really NEEDED thing for me)
3) Save the maps as a bmp, gif, or jpg image file, rather then use printscreen then paste onto a paint program
4) The option to turn off multi-level system. Instead of the up and down being put to a new level on the map, automatically make it go northeast and southeast..
5) Have the undo function with a toggle that allows you to chose how many times you want to undo ? (Say max 50 - 100 times of undo)

Thats about all I can think of for the automapper that would come in extreme handy situation for some mappers :)
Sharazani