Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » zMUD General Discussion Goto page 1, 2  Next
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Oct 20, 2005 10:24 pm   

Questions needed for zMUDXP
 
I'm working on the zMUDXP product and have two questions that need to be answered:

1) Does anyone have any trigger with a pattern that is greater than 128 characters or so? Seems that some databases have restrictions on index field length, and when a trigger doesn't have a short ID name, the pattern is currently used as the trigger "name" which needs to be indexed.

1a) How much of a problem would it be if each trigger required a unique ID name and you used that ID to refer to the trigger all the time. Currently in zMUD this short ID field is optional.

1b) If you have a really long trigger, post it so I can see an example and see if it is possible to shorten it.

2) Would it be a problem if zMUDXP didn't allow you to change most of the scripting "Special Characters"? In particular, the # command character, @ variable character, and % system variable characters. Allowing these values to be changed makes it very hard to share scripts with people, and script sharing is one of the areas that is going to be a big feature in zMUDXP.

2a) If you currently use different special characters for the above functions, why? Is it just a individual preference, or is there a good reason?

Thanks for your help answering these questions. I know that the forum represents a minority of zMUD users, but it's about the only way I have to gather this kind of information.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA

PostPosted: Fri Oct 21, 2005 12:55 am   
 
1a)You already have a routine to make things unique in the pattern (which, by the way, doesn't currently work on macros since macros not utilizing the shift-aspect keys are limited to one character and the unique identifier is two characters.) Any way to adapt it to provide a unique short id rather than tacking something onto the pattern? It could be something like "Trigger1" or even a numbering system like you use for buttons.

2)In what direction are you planning to go with the bigger sharing aspect? I mean, will it be sort of peer-to-peer where we just upload our creations and download at will, will it be more like plug-n-play (ie, sharing entire settings files directly), or did you want to stick to exporting to a file and share from there? However you do it, it might be that you (should you want this hardcoded into ZMud) could make a simple conversion utility that substitutes our personal special-character preferences to the standard default. To get really fancy and avoid the need to retranslate, the conversion utility could even allow us to go from one custom preference to another.

I don't mean to dump more work on you or get you into putting off features in favor of later and unguaranteed plugin stuff, but this might be something to think about.
_________________
EDIT: I didn't like my old signature
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Oct 21, 2005 1:27 am   
 
I'm not yet ready to release any details on the shared scripting stuff, sorry.

Just need to hear some opinions on the specific questions I posted for now.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Fri Oct 21, 2005 1:52 am   
 
1) I have a pattern that is 245 characters long:

^((At|By|On|In|From|Up) [^,]*,|(To )?The image of|To the images of others,|Through the trump image|From afar,( to| to everyone in the room,)?|Long distance to [^:]*:)?\s*(@wholist|Pattern Lens|Logrus Lens|Trump Scrying|You)([:,']|'s)?\s[\w'"].*

This triggers on most of the lines that are chat-related in AmberMUSH.

1a) If you require a short ID, assign a unique one automatically. If I want to really use it, I can always rename it.

2) I do need to turn many of the special characters off. I am playing MUSHes now, and '@', ':' and ';' are used to start commands, as well as '!' in AmberMUSH. Also, many user-defined commands use '.' too. I haven't redefined them, because I don't use those features, but I can see why I might.

This is a pet peeve, I guess. When I turn off a character, I only really want to turn it off for command line processing. I don't want to turn it off or change it in scripting. But by turning off ';' for example, I can't use it in a script. All I really want is to be able to say:

;'s eyes blink

without having to quote anything.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4548
Location: Pensacola, FL, USA

PostPosted: Fri Oct 21, 2005 2:25 am   
 
i have alot of {{@var}} where the variable once opened up would easily exceed that number of charectors...


and if you do:
~;'s eyes blink

it will ignore the ; for zmud processing and let the mud do it
_________________
Discord: Shalimar#3679
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Fri Oct 21, 2005 2:38 am   
 
My longest trigger pattern is about 120 characters and could continue to grow. I don't think it would be such a hassle to have each one have a required name. I'd have to get used to putting one again ( a minor adjustment ); I actually recall being surprised that you didn't require it before.

As for special characters... I've never changed them. I suspect few ever do. The scant reason's I can think of for ever wanting to change them are resolved by the fact that you can quote or escape characters as necessary to avoid any issues..
_________________
Asati di tempari!
Reply with quote
Auren
Newbie


Joined: 12 Jan 2003
Posts: 7

PostPosted: Fri Oct 21, 2005 3:34 am   
 
Oh heck yes. You'll find that a lot of IRE players (at least Achaea anyways, dunno if the message is like this in the others) have a trigger like this:
Code:
([A~*]?[ ~*]?[p~*]?[r~*]?[i~*]?[c~*]?[k~*]?[l~*]?[y~*]?[ ~*]?[s~*]?[t~*]?[i~*]?[n~*]?[g~*]?[i~*]?[n~*]?[g~*]?[ ~*]?[o~*]?[v~*]?[e~*]?[r~*]?[c~*]?[o~*]?[m~*]?[e~*]?[s~*]?[ ~*]?[y~*]?[o~*]?[u~*]?[r~*]?[ ~*]?[b~*]?[o~*]?[d~*]?[y~*]?[,~*]?[ ~*]?[f~*]?[a~*]?[d~*]?[i~*]?[n~*]?[g~*]?[ ~*]?[a~*]?[w~*]?[a~*]?[y~*]?[ ~*]?[i~*]?[n~*]?[t~*]?[o~*]?[ ~*]?[n~*]?[u~*]?[m~*]?[b~*]?[n~*]?[e~*]?[s~*]?[s~*]?[.~*]?)


The message is:
A prickly stinging overcomes your body, fading away into numbness.

...where any character, inluding the spaces and punctuation, can be randomly replaced with a *.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Fri Oct 21, 2005 9:05 am   
 
1: 220 characters. I know I could make 5 triggers instead.
^{Nothing can be seen here by that name|Ahh, I am truly sorry, but I do not see anyone by that name here|You cannot see that being here|I do not recognize anything called that here|You detect nothing here by that name}.$

1a: Seems to me that if you just take up to the first 127 characters that would work, the requirement that they be unique might be somewhat difficult with that method. I have a good number of #COND {} {do stuff with %line} {looplines}. Those might cause a problem with that method.

So I am all for having the ID field moved from optional to required. Just please make sure there is some sort of confirmation if we happen to try using the same ID twice. Also some of us have multiple triggers for the same line of text, where the behavior used for that line depends on which classes are enabled. This supports having the field be required since the indexing needs it to be unique.

2: I have never changed any of the special characters, but I have seen many muds use similar characters for shortcuts to channels, coloring, etc. It has never been a problem for me though since I know that simply starting a command in the command-line with a " will cause the line to be sent verbatim. I know it is documented in the help too, but many miss it.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Guinn
Wizard


Joined: 03 Mar 2001
Posts: 1127
Location: London

PostPosted: Fri Oct 21, 2005 11:19 am   
 
1) Don't have an example to hand, but I'd definitely have some with >128 chars. Things similar to Vijilante's, and also a number of ones that use variables with tens or hundreds of items in (e.g. ones that contain the names of all foods that can be made, to help with eating scripts etc).

1a) Would be no problem for me. ZMudXP could quite easily suggest a name if one hasn't been supplied, thus making it invisible to the user if they choose to ignore it?

1b) Don't have zMud to hand atm. I'm sure some could be shortened or split up, but there will definitely be examples that even after shortening would be >128 chars.

2) No problem for me. Perhaps a note in the options regarding special characters that reminds people to prefix them with ".

2a) -



Since it's a new product, I'd be inclined to aim more at making it fast, robust and feature rich. A slight learning curve isn't a bad thing, and there's always the forums to help people out. Go with what you think would make zMudXP work best once we've got used to it.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Fri Oct 21, 2005 4:37 pm   
 
When talking about trigger length, I'm just talking about the length of the pattern as seen in the Settings Editor. Using a @var that expands to a huge amount of text is not a problem. But it looks like there are already several examples where the trigger itself it already longer than the index limit.

So it looks like I'll need to assign unique IDs to all triggers. I don't want to prompt the user for a bunch of stuff because this is going to happen when existing settings files get converted into the new format for zMUDXP. And I don't want it to pop up hundreds of dialogs just to verify trigger ID for people with lots of triggers to import. So I'll probably just assign unique IDs within zMUD and then let people change them as necessary.

I had forgotten about that Achaea trigger mess with the * replacement. I'll have to think about whether there is a better way to handle that. Certainly is a pain. I really dislike MUDs that do stuff like that. Just annoys the players and doesn't actually stop scripting. But let's not get into that on this thread ;)

As far as special characters, I really mean people who have changed them for their scripts for some reason. I understand the need to disable them on the command line for certain MUDs. But I'm not worried about the command line at this point. I'm mainly worried about people who might have a good reason to change them within scripts. I can't think of a good reason to do this, but that's why I'm asking.

And yes, "fast, robust, and feature rich" is definitely what I'm going for. But I also want to maintain as much scripting compatibility as possible. Without good compatibility with zMUD, a lot of people won't buy the new product. But yes, there will be a slight learning curve, especially for anyone that is exploiting any quirks or wierd syntax in the current zMUD. If your scripts pass the current zMUD syntax checker, then you have an excellent chance for painless importing into the new product.

OK, well, I'm glad I asked about the triggers. Looks like that's certainly something I need to deal with.
Reply with quote
darmir
Sorcerer


Joined: 10 Oct 2000
Posts: 706
Location: USA

PostPosted: Fri Oct 21, 2005 5:27 pm   
 
Here is an example I know a special character has been changed for Shadows of Isildur mud:

If you happen to use zmud (this script will also work for tintin++/wintin too - it assumes that \ is your escape character (i.e. what is by default ~ in zmud and what most of us who play SoI change to the tintin \ so that we can emote properly), here's a handy little script that won't even require you to change anything:

zMUD version:

#alias draw {#if (%pos(%0,"bow")) {remove %1;wield %1} {\draw %0}}

tintin++ version:

#alias draw {#if {[%%1] = [bow] || [%%1] = [shortbow] || [%%1] = [longbow] || [%%1] = [crossbow]} {remove %1;wield %1} else {\draw %0}}

The tintin++ version is slightly worse than the zMUD one just because of it's inherent limitations: I'm sure that you can adapt this to your own choice of mudclient with very little difficulty.
_________________
Run as hard as a wild beast if you will, but you won't get any reward greater than that destined for you.
Source: (Egyptian)
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Fri Oct 21, 2005 11:52 pm   
 
shalimar wrote:
and if you do:
~;'s eyes blink

it will ignore the ; for zmud processing and let the mud do it

OK, yes, that works, but I also need to be able to do:

page character=;'s eyes blink

or a number of other instances where the ';' is imbedded in the command line.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Mon Oct 24, 2005 6:37 pm   
 
I use several rather long patterns in my triggers, as a measure against illusions in Achaea. Illusions can only be up to 160 characters, so if the real message is longer, it's beneficial to trigger the entire thing. Even if I don't use all the text for my capture, I include extra lines just to avoid illusions that would throw key things out of whack in my scripts. For example, capturing my health, mana, etc values from my score (the easy way, without having to enable/disable a folder and use a timer as a failsafe, blah blah blah):

Quote:
^Health\:\s+(?Health:\d+) \/\s*(?MaxHealth:\d+)\s+Mana\:\s+(?Mana:\d+) \/\s*(?MaxMana:\d+)\nEndurance\:\s+(?Endurance:\d+) \/\s*(?MaxEndurance:\d+)\s+Willpower\:\s+(?Willpower:\d+) \/\s*(?MaxWillpower:\d+)\nStrength\:\s+\d+\s+Dexterity\:\s+\d+\s+Constitution\:\s+\d+\s+Intelligence\:\s+\d+$


Some affliction messages are quite long and complex, too:

Quote:
\w+ bows (?:his|her) head and mutters something\, then flings a tarot card at you\.(?: |\n)+A(?: |\n)+set of scales appears above your head and one side of the scale \nquickly descends\. You have a bad feeling about this\.$


Any chance it'll be easier to trigger multiple lines and do it correctly? What I'm after is a way to look for newlines (or wraparound) in varying locations, which I can only do to a limited extent with the (?: |\n)+ pattern right now.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Tue Oct 25, 2005 12:50 am   
 
2a) The only thing I change is the separator ';' to '|' because I use ';' on the mud regularly. I wonder, can you instead of storing the character in the script, why not store something like \xFF\x## where ## is the ID of the type of character. You can display it using the person's preferences, and because all the scripts are stored the same way, when you share them with that 'escape' sequence, it will automatically translate to each user's preference.

I would be frustrated if you made it impossible to change the separator character, but the rest don't bother me so much.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Oct 25, 2005 10:19 pm   
 
Hmm, the separator character is actually one of the tougher ones to handle. I don't want to store something different. In fact, in the new zMUDXP, it messes with your scripts a lot less than in zMUD and stores your multi-line text exactly as you type it using a more traditional editor.

I think I can set up a way for each "settings file" to still have custom special characters. It gets a bit tricky at script execution time if you are using multiple scripts each with different settings, but I'll try to keep handling it the way zMUD does. But I can't promise this yet. I'm really trying to move towards a more traditional scripting system. For example, C doesn't let you change the {} characters or the ; at the end of the line.

What maybe needs to be easier is how to send "special characters" to the MUD more easily so that it doesn't impact the scripting. I guess I'd be interested in seeing a specific script example where you have lots of ; characters needed by the MUD and where you aren't just putting those strings in quotes. A ; within quotes should work fine.

I *have* considered changing the ~ escape character to the more traditional \ character. Not sure why I choose ~ years ago as the default. Maybe it's what TinTin used or something. But it's a bit of a pain when regular expressions use \ and zMUD uses ~. It can make trigger parsing really tricky.

As far as multiline stuff, I'm looking into it. What I'd really like to do is figure out a good algorithm for "unwrapping" the lines from the MUD so that you can control the wordwrap within zMUD itself, and then it would get handled as a single line no matter where the \n is in the text. But handling line unwrapping can get *very* tricky and it's pretty horrible when it fails. So the first version of zMUDXP certainly won't have that feature.

I'll post more about zMUDXP in a couple of weeks. I plan to announce the official name and get the new forums started with some specific posts on specific features to expect in the first beta version. I'm still planning for the first beta version well before the Christmas holiday.

Please continue discussing the questions that I posted. The more opinions the better.
Reply with quote
Larkin
Wizard


Joined: 25 Mar 2003
Posts: 1113
Location: USA

PostPosted: Wed Oct 26, 2005 12:00 pm   
 
In C, you can change any character, technically. You can use a macro to substitute one thing for another. It's probably not feasible to have a preprocessor step in zMUDXP that parses such macros on an import, but it may be an idea to consider. Just tossing it out there.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Wed Oct 26, 2005 2:32 pm   
 
The C preprocessor can substitute any identifier, but not punctuation/operators, but that is probably off-topic....

What I would suggest is separating the concept of the "script language" and command line processing. The language should be static. What people may need is to be able to use alternates on the command line.

So while you will always use ";" to end a command in a script, when entering a multiline command on the command line, you may choose to use "|" (or, disallow that completely, like I do).
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Wed Oct 26, 2005 6:29 pm   
 
That's a good idea. Generally speaking, most of us don't script at the command line (unless we're testing out new lines of script.) For those who wanted to continue tha functionality (i.e. scripting on the command line) then maybe you can start those lines with a special char sequence.. like '##'.

Bettery yet, have the option of processing special chars like ';' at the command line be turned off/on in preferences.
_________________
Asati di tempari!
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Wed Oct 26, 2005 6:39 pm   
 
Actually, you can already very easily control processing of special characters on the command line using the Parse option in the Settings menu. This option is also toggled with the Ctrl-R key and the Parse status is shown as an icon in the icon bar on the right side of the command line. So it's really easy to turn on and off quickly as needed.
Reply with quote
Tech
GURU


Joined: 18 Oct 2000
Posts: 2733
Location: Atlanta, USA

PostPosted: Wed Oct 26, 2005 8:10 pm   
 
Like I said in my Kudo's... I'll ask for a feature and then find out it's already there... Woot!
_________________
Asati di tempari!
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Wed Oct 26, 2005 11:56 pm   
 
I dunno, parsing should be able to be always on, eg when I log in, I type #CH, #PW (just because I'm too lazy to script autologin). I don't want to have to go Ctrl-R, #CH, #PW, Ctrl-R ...

On the command line I'm happy enough to use ctrl+enter to make a new line, in fact sometimes when I'm posting a multi-line note sometimes zmud will try to 'smart' up and puts the line separator between some lines (and not others) and in the end mess up the whole thing I'm trying to post (though, that might be fixed since we got spell checking, I'm not 100% sure).

My MUD supports its own internal newline character, eg "gt going!! & n & k cyclops" will parse mud-side into three commands, so I don't find myself using the zmud separator on the command line very often, which is why I remap it to '|' because I do use ';' often for MUD-stuff (especially when building, writing mud programs, and winky-smilies eg ;P and ;0).

I do occasionally use the zmud line separator when I want to mix a zmud command with something, like I might go 'say heading to medienne|#WALK medienne', or 'east|knock door|#wait 2000|east' but it's not very often that I need to use the zmud separator.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Thu Oct 27, 2005 1:50 am   
 
Zugg wrote:
Actually, you can already very easily control processing of special characters on the command line using the Parse option in the Settings menu. This option is also toggled with the Ctrl-R key and the Parse status is shown as an icon in the icon bar on the right side of the command line. So it's really easy to turn on and off quickly as needed.

That is true, but turning off parsing also disables aliases (maybe also input triggers?). Also, say you play a MUSH, that uses a ":' command at the start of a line, but you still want the ability to send to other windows? Remapping that character is really what you want to do. The same is true for characters like ";" especially since you may want to have an alias and use ";" as an argument (I do this, by the way--I have a "t" alias that is a flexible page command, so I need to be able to say "t Bob ;'s eyes blink"

So enabling/disabling parsing is not a general solution.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Thu Oct 27, 2005 5:11 pm   
 
Again, remember that special characters are not parsed within quotes. In your example, why can't you do this:

t "Bob ;'s eyes blink"

Doesn't that send the whole string to the %1 argument as desired?

Again, keep in mind the fundamental problem we are facing here. We want people to learn zMUD scripting. If everyone uses different syntax, then it's a lot harder for new players to pick it up. When we start sharing scripts with zMUDXP (and trust me, this is going to be a big deal), then it will be confusing if some scripts use ; and some use |

I agree that the command line can be handled differently. But it has been useful for new players to know that anything they type into a script can also be entered on the command line, and vise-versa. In fact, many people start scripting by just taking what they are normally putting on the command line and putting it into an alias or trigger. So having the same syntax is helpful.

If someone is on a MUD with a friend who has changed their special characters, then when asked for a sample command or script to do something, they might get a solution with different syntax that doesn't work when they try it.

Certainly this ends up being a big issue on MUSHes and other systems that are really programming/scripting languages themselves. These systems tend to use a lot more special characters compared to DIKU MUDs. So somehow zMUD need to be more flexible for handling these other MUD types and yet more standardized to allow easier sharing of scripts.

I've seen a lot of discussion so far about why changing special characters is useful. So I understand that now. What I need now is more discussion on how this conflict might best be solved.

So, how would you *like* this to work in a new MUD client? How would you like to see the MUD client handle the issue of putting scripting commands on the command line, vs the special characters that need to be sent to the MUD, along with having some sort of standardization for sharing scripts more easily.

Keep in mind that "converting" scripts is very difficult. It's not a simple manner of substituting all | characters with a ; character, for example. Such converters would be more likely to mess up a working script. So I'd like to avoid the conversion issue if possible. Also keep in mind that the more standarized the scripting language can be, the faster it can be. For example, right now I can't easily use a table-driven parser because the special characters might be different. Having to deal with variable special characters slows down the scripting for everyone.

So, keep your ideas coming.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Thu Oct 27, 2005 6:04 pm   
 
Zugg wrote:
Again, remember that special characters are not parsed within quotes. In your example, why can't you do this:

t "Bob ;'s eyes blink"

Doesn't that send the whole string to the %1 argument as desired?


Actually, Bob is %1, and the rest is the chat line. So if my character's name is Jack, the above sends the following to Bob: "From afar, Jack's eyes blink". Not sure that's really relevant to the discussion, but FYI...

The reason I use an alias "t" is to generalize the 3 kinds of tells in my MUSH: page, mp, and mp/h. It chooses the right one from the first arg.

One of the things I see about zMUD is that it is more targeted to MUDs rather than MUSHes. OK, that's probably where the market is.

If you've ever played a MUSH, you'd see just how much you use : ; @ &, and on my MUSH ! and . (period). You also tend to write prose as chat, including normal punctuation (including quotes). I want my aliases to act "naturally" and not require quotes (and then there's the problem of putting quotes inside of those arguments as well).
Reply with quote
yejun
Wanderer


Joined: 13 Jun 2005
Posts: 51

PostPosted: Thu Oct 27, 2005 7:27 pm   
 
For trigger pattern indexing, i think it might be better to use hash map. It is inefficient to compare two long text in general.
128-char limitation of text nowadays sounds too retro to me.
For setting file, i wish it would use a standard format, like xml, because xml parsing is fast and it is readable.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » zMUD General Discussion All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net