Zugg Software :: View topic

Posted: Sat Aug 18, 2007 11:59 am

Question about telnet option triggers - they fire on IAC SB OptionNum Text IAC SE, but how would you refer to the Text once the trigger's fired? There's no way to put brackets round it and use %1.

Posted: Sat Aug 18, 2007 5:19 pm

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.

Wanderer Joined: 11 Mar 2002 Posts: 93

Will this allow for gagging/subbing before prntscrn?

One thing I have noticed with zmud/cmud is the order of operations, when using #gag or #(p)sub is server->client->prntscrn->strip/sub from prntscrn.

I am curious if this will remove the initial prntscrn and gag/sub first then do the prntscrn.

Posted: Sun Aug 19, 2007 12:10 am

What do you mean by "this"? We were just talking about telnet option triggers and since their text is never displayed in the buffer, it'd make no sense to gag or sub it.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I believe the question is this.

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.

Wanderer Joined: 11 Mar 2002 Posts: 93

Arminas is correct, my question was along this line.

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.

Posted: Sun Aug 19, 2007 4:19 am

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.

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

Posted: Mon Aug 20, 2007 8:10 pm

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.

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

Thanks Zugg Very Happy

Posted: Tue Aug 21, 2007 1:33 am

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 Razz

Magician Joined: 25 Oct 2000 Posts: 461 Location: USA

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!

Posted: Tue Aug 21, 2007 10:41 pm

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.

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

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!)...

Posted: Wed Aug 22, 2007 3:27 pm

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.

Posted: Wed Aug 22, 2007 5:25 pm

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.

Posted: Wed Aug 22, 2007 11:04 pm

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.

Posted: Wed Aug 22, 2007 11:57 pm

Wow Zugg!! That's great news! As you said while it was probably a big dent in your schedule but it makes 2.0 closer to a revolution than an evolution!!

I can see I'll get no sleep if CMUD's released this weekend.

Keep up the great work!!! Greets to the Mrs. and the cats.

Posted: Thu Aug 23, 2007 10:57 pm

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 ;)

Posted: Thu Aug 23, 2007 11:30 pm

Bah. You fixed my "pet" bug, the one with window creation when you download packages from the library. I'll have to find another one now Crying or Very sad

Perhaps something in the Lua implementation?

Posted: Fri Aug 24, 2007 1:36 am

Hey Zugg does that mean the problem I had with packages is fixed. Whenever I uploaded a package with a window, I wouldn't be able to download it. It would get truncated somehow.

Posted: Fri Aug 24, 2007 5:16 pm

Tech: If you remember the name of the package that gave you trouble, let me know so that I can test it. But in general, most of the bugs with downloading packages should be fixed in 2.0.

Posted: Fri Aug 24, 2007 5:45 pm

I think I removed it from the package library so I'll just retry it when 2.0 is released.

[Edit] I think you actually address my problem here, so I'm very hopeful.

Posted: Fri Aug 24, 2007 11:46 pm

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!

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

I know a good publisher, he should be able to handle your 2.0 bugfix list.

By the way, what happens if somehow you suddenly ran out of bugs to fix (cascading fixes from what you did make changes to)? You gonna go on holiday? Very Happy