CMUD tests the "Text" in the IAC SB with the pattern in your trigger. So if you just put (*) as your trigger pattern, then it will match all text and you can reference it in %1. But you have all of the normal power of triggers here. For example, let's say that the MUD sends something like:

IAC SB 123 Hp: 100 IAC SE

Well, then you can create a Telnet Option trigger with a parameter of 123 (the option number) and a pattern of "Hp: (%d)" to capture this data. You can have as many triggers as you want for a given telnet option. So you don't need to use (*) and then parse the text yourself.

In other words, a Telnet Option trigger is just like a normal trigger, but instead of firing on normal text from the MUD, it fires on the suboption text from the MUD.

When you gag or substitute a line of text from the mud. If your system is very slow, or bogged down by settings in some way, you can actually see text appear on the screen before it is gagged or substituted. Solaras believes that the order of operations for triggers must be this. Text comes from server-> to the client-> prntscrn Printed to the screen-> Triggered from within the window and strip/sub from prntscrn.

Now, since we will now be able to trigger off of things which will never be seen by the screen AND also on text that WILL be seen on the screen will it be possible to remove or substitute text BEFORE it appears on the screen.

Edit: Zugg's post seems to suggest that we will be able to capture and trigger on text that we WILL see as well as on portions of the line that we will NOT see. Thus this question is a relevant one in my opinion.

I want to make a trigger for Farsee in Achaea on suboption 188 that takes the text:

You close your eyes momentarily and extend the range of your vision, seeking out the presence of Bob.
You see that Bob is at some shop.

and then subs that to my prntscrn as:

Farsee: Bob is at some shop.

So the first line would actually be gagged then the second line would be subsituted.

Now the way it currently works, that text would be displayed to the screen first(prntscrn), then the first line stripped from the display and the second line substituted. Which can be very fluid and nearly seamless, or can be seen happening each and every time.

I was asking if with the new telnet trigger options this would instead cause the text to be gagged/subbed -prior- to the output display.

CMUD triggers grab the text from the display so that your triggers are not effected by control codes sent from the MUD. This is the way zMUD and CMUD have always worked. In the early days, some MUDs tried to defeat triggers by inserting control codes (like nulls) to mess up pattern matches. By triggering on the actual screen output, zMUD/CMUD can match the exact text that you see on the screen, and the exact ansi colors that you see, with no messing around with the low level data.

This isn't going to change. You generally shouldn't notice the text being displayed. The default installation only updates the screen after five lines have been received, or at the end of a packet, and the triggers should be done before the screen updates.

It's possible that a future version of CMUD will have "raw" triggers that allow you to trigger on the raw network data. But then it would be up to you to handle stuff like ANSI color codes, packet boundries, and all of the other nasty stuff that you'd need to deal with to get a reliable trigger.

The Telnet Triggers that we are talking about here don't have any of this trouble. The data sent by a telnet suboption is never displayed. You get the raw text into your trigger and you parse it however you want. If the MUD sends control codes with the suboption text, then you'll need to put those control codes in your trigger pattern. None of the commands that effect screen output (like #GAG, #SUB, #COLOR, #CW, #PCOL, #PSUB, etc) will have any effect when used within a Telnet Option trigger because nothing is normally displayed by a suboption. You *can* use stuff like #SAY or #SHOW to display something in one of these triggers.

Not to try and hijack the thread, but I notice text before it gets gagged a lot. The mud I play sends a simple 'who list' that I used zMUD and CMUD to grab to populate a caption, so every minute or so I'll be gagging 20 lines in a row, but I often see things appearing for a fraction of a second before they're gagged. The end result though is the text 'flickering' briefly fairly often.

Well, I *do* really care about stuff like this. So I took a look at the code and tried to reproduce this. I was able to find some cases where the gagged text was showing on the screen before it was deleted. I traced some of the Windows PAINT messages that update the screen to see if I could figure out where they were coming from. Turns out that when deleting a line, the part of the screen occupied by the line was "invalidated", telling Windows to repaint it when it gets a chance. But there was no way to determine exactly when Windows would perform this screen update. If the screen update happened to occur after the next line was received, but before it was deleted, then it would be displayed on the screen.

I have put some code into v2.0 to try and improve this. In 2.0, the screen won't get repainted while a trigger is being processed. After the trigger is processed, *then* CMUD invalidates the portions of the screen, and Windows then paints it. This *should* fix this problem. Hopefully it won't cause any new problems. Anyway, when 2.0 is released later this week, give it a try and see if it works better for you.

Except for the improvement to the Gag code mentioned above, and the new "Repeat within line" trigger option that I mentioned in the main CMUD forum, the rest of today was just spent on boring bug fixes. Nothing special. But nothing annoying either. For example, I fixed the problem where spaces were sometimes stripped when executing commands (like ones that started with the ~ character).

I still have about 30 bugs on the high-priority list. If they are all small and easy like the ones that I fixed today, then that's about 2-3 days. So it's looking good for something this week. Yes, I think it's actually *less* than a week now! That's progress

Good news on the gag fixes! I've frequently seen the 'ghosting' that Guinn mentions. I wouldn't be surprised if this ghosting is what causes people to think z/cmud is "slow" - it has the appearance of not even being able to keep up with scrolling! (Though that of course isn't the case). Good stuff!

Today's work was on "context". That is, making sure that everything executes in the proper class/module context. Especially regarding status bar and window items and buttons.

Triggers were already executing within the context of the window that received the text. But buttons and status bar items were not "connected" to the proper window. I have fixed this so that they also get their captions and execute within the context of the window that contains them.

This led to working on stuff that is stored in other modules (modules that don't have a window, like in another package). In v1.34, you couldn't put buttons or status items in external packages/modules. Well, you could, but they didn't work properly.

In v2.0, when a button is added to a window, or a status bar item is added to a window, the window is assigned as the "context" for that item. This now allows stuff in other packages/modules to work properly. It gets tricky if you have multiple windows. CMUD doesn't support having a button or status bar item appear in multiple windows. The new code that I added will help in that situation, but it probably won't work until I really fully support multiple instances of buttons. But at least it works now with a single window.

I also fixed the bugs with the status window not handling multiline items, and not expanding variables and functions properly. I also fixed a problem if you had a single status item with *both* the "Show in bar" and "Show in window" options enabled. I also fixed the crash that occurs when you close CMUD while the status window is open and docked.

The "context" fixes should also ensure that trigger alarms execute within the proper window when they fire.

The new way that I'm handling "context" for all of the settings is much cleaner than before, so if there are problems with it, it should be easier to fix in the future.

All of this work was only represented by about 5 items on my bug list, so there are still a lot of things left to fix. The only other big item on the list is dealing with the Package Library. That's one entry in my bug list ("Fix package library"), but represents a lot of problems and a lot of needed testing. I'm really going to try hard to have something ready on Friday so that you can play with it over the weekend.

Somewhat related to the context fixes, any word on a fix for items that are set to enable/disable on connect? I know that the issue is basically how to know when to enable/disable items that aren't directly "owned" by a window. Just want to make sure it hasn't been forgotten. That and the #RESET fix are the two things I'm really hoping to see fixed in 2.0 (not to mention all the awesome new features I can't wait to try out!)...

Larkin unless I'm missing something, can't you do that now? If you have the original post, point me to it.

What you can do is have an event on the Window (that connect/disconnects) and have that enable/disable the items you want to control. If you have multiple windows that connect/disconnect and you want different items to my controlled then you can have the events for those windows raise custom event's that you packages/modules listen to.

Or maybe Zugg can add a default parameter to the onConnect/onDisconnect events so that the name of the window that raised the event is a available in a local variable like $windowName.

Larkin, perhaps you can post the enable/disable on connect to the Discussion Forum or post a link to an old post if I missed it. The only settings that enable/disable on loading are classes, and classes should be enabling/disabling their contents correctly even in 1.34.

There are various #RESET issues on my bug list that I hope to get into 2.0.

Tech: In 2.0, the %curwin variable should tell you the name of the window that caused the trigger or event to fire.

Well, there was another entry on the bug list that was a lot more work than I thought it would be. It simply said "gauges don't work properly". There were various problems with gauges not getting updated when their variables changed. Also, if the gauge had a variable like "%mxp.hp" assigned to it, then it wasn't getting updated when the %mxp record changed. So MXP gauges were also totally broken.

Then, I found a bug that was also still in zMUD...if a gauge is the last thing in the button bar after several buttons, and you then resize the window so that the gauge doesn't fit, then when it gets wrapped to the next line of the button bar, it gets displayed on top of the other buttons. Guess nobody ever ran into that specific case in zMUD either.

Anyway, while I was testing all of this and fixing it, I was using a test session that had a button and status bar item defined in an external module left over from my testing yesterday. When I created a second child window (a Tell #capture window), then it tried to put the shared button from this external module into both the main MUD window *and* the Tell capture window. And this started causing all sorts of trouble.

Well, I finally gave in and properly implemented multiple button instances. As I mentioned above, I had laid the ground-work for this yesterday. So today I took it the next step and allowed buttons to be instanced in multiple windows. If you use a variable reference, like @hp for the button caption, it properly gets the variable value from the instance that the button is displayed in.

While I was at it, I fixed the same problem with status bar and status window entries. I also fixed the status window so that it will switch definitions to follow whatever window has focus. So each window can have it's own definition for the status window and it updates properly now. In my test, I created a common status bar and window item in an external module. I gave it the definition "hp: @hp" and fixed it so that the status bar and status window displayed the correct @hp depending upon what window was selected.

That was a lot of work...more than I expected. And certainly wasn't what I planned to work on today. But I'm sure some people will be happy about this. It will sure make external packages/modules a lot more useful now.

A fixed several other "quick" bugs, but I still have the "Package Library doesn't work" item yet to do. Hopefully I can finish that tomorrow, then spend Friday on other misc bugs. It's kind of mind-boggling how much stuff is fixed in v2.0.

Spent most of today working on the Package Library. I fixed the problem with \ characters being stripped. This turned out to be a server issue, so submitting a package in v1.34 shouldn't strip \ characters anymore either.

I also fixed the bug that was causing a new window to be created whenever a package was downloaded from the library.

Then I ran into a nasty bug. Any time there were settings within a parent (like trigger states, button states, or just stuff stored within a parent class folder), there was a possibility that the setting wouldn't be loaded correctly. The problem occurred when the child setting came before it's parent in the database storage. So, if a child trigger has a database ID of 10, but the Parent trigger had an ID of 11, then when the child was loaded, the parent record didn't exist in the internal cache yet, so the parent pointers of the child would be incorrect.

This could happen to any setting in a class if it came before the class in the database. For example, if the setting existed first, then you created a class folder and then drag/dropped the setting into the class folder. In this case, when the package was reloaded, the setting within the class might not behave properly.

The problem was much more apparent with multistate buttons and trigger states. In the case of buttons, you'd see the button states in the settings editor, but they wouldn't get displayed within the button's drop-down menu. With trigger states, you'd see the states in the settings editor, but they wouldn't actually work within the parent trigger. It was a case where the database was correct (so stuff displayed correctly in the settings editor), but the internal cache pointers were undefined, causing the settings not to execute.

I wrote a "fixup" routine that goes back after the entire package is loaded and fixes the cache pointers for any setting that had this problem. This seems to work now. This bug might have been the cause of a lot of really weird and hard-to-reproduce problems in 1.34.

That took a while, but I think the package library is working in v2.0 now. I'm still waiting to hear about any other package that weren't working. If you get an XML error when you try to install a package from the library, please post a note over in the CMUD Discussion Forum telling me what package in the library gives the error. I think there might still be some XML errors causing problems for some packages that I might not have fixed yet.

Larkin will be happy to hear that I fixed some of the #RESET problems today. #RESET now works with classes/modules in other packages, and it also supports the full //module/class syntax. I also improved the Execute option in the Package Editor so that it works with any setting, not just for Aliases.

I also fixed the problem with @{db.key} and optimized the compiler so that @{a} compiles to a direct reference to variable "a". I also fixed a related problem that was preventing stuff like @{%concat("db",".","key")} from working. So I think all of the indirect variable access issues should be improved.

I also improved settings that are stored within an external package/module so that when they reference a variable, a "soft" variable link is created, rather than a hard direct link. This allows settings (like buttons, status bar items, etc) that appear in multiple windows to properly reference the variable in the proper window. There was a case where the button was getting a hard link to a variable in a specific window compiled, and then it was caching this compiled value and not updating properly when used in a different window. Just another left over issue from the multiple instancing that I've been working on this week.

So now I just have a handful of misc bugs that I want to fix. I'm looking at some issues with the Styles, and with Undocked windows, and a few other things. I'll probably spend all day tomorrow as long as I can working on bug fixes. Then I'll work over Saturday to actually release the beta version. I'll only announce the beta version over in the CMUD Beta Forum, so keep an eye on that for the announcement. Then I'll take a couple of days off while people beat up on v2.0 and report all of the nasty problems with it ;)

More bug fixes today. I've lost track of everything that I've done today (although it's all recorded in my bug database for when I update the version history). I couldn't actually get undocked windows to fail at all, so I lowered that on the priority list to look at more closely later. I fixed several corrupted package issues where some "parent" pointers weren't set properly. When you load those packages in 2.0 they will get automatically fixed. Also fixed problems with windows in packages being created in the wrong package when loaded.

I found and fixed a nasty little problem with trigger states. If you were editing the main trigger when the state of the trigger changed, the settings editor could lose the trigger script. It wasn't really gone...it just wouldn't be displayed in the settings editor.

I also fixed some bugs related to using the ~ escape character in trigger patterns.

I'm going to continue to work on more bug fixes tonight, and then more tomorrow. And I'm still planning to try and get the release out tomorrow evening. Keep crossing your fingers, we are getting close!