 |
cuprohastes
Wanderer
Joined: 22 Oct 2006
Posts: 92
|
 Posted: Sat Mar 15, 2008 10:55 am
[2.20] Problem loading session (Trigger error)
|
On trying to laod a session I get:
| Code: |
Error in trigger pattern:
*. has (connected|disconnected)\.$
nothing to repeat (0)
|
This trigger was previously working. The error message is in a loop and will not be fully dismissed. |
|
|
|
|
cuprohastes
Wanderer
Joined: 22 Oct 2006
Posts: 92
|
Posted: Sat Mar 15, 2008 11:00 am
|
Update:
By holding the "enter" button down, I can get the dialogue box to dismiss fast enough that eventually the session will finish loading. The trigger has now been disbaled.
Incidentally I do like the new "test pattern" panel... I don't recall seeing it before and it's not in the Change log?
Anyway, the XML for the trigger is:
| Code: |
<trigger priority="300" regex="true" enabled="false" id="30">
<pattern>*. has (disconnected|Connected)\.$</pattern>
<value>#col grey
//speak %params</value>
</trigger>
|
|
|
|
|
|
oldguy2
Wizard
Joined: 17 Jun 2006
Posts: 1201
|
Posted: Sat Mar 15, 2008 1:48 pm
|
It should be ".*" not "*." and it will work fine. However, thats a bad way to match your message line. You should really enter in the entire message line you get from the mud.
|
|
|
|
|
Arminas
Wizard
Joined: 11 Jul 2002
Posts: 1265
Location: USA
|
Posted: Sat Mar 15, 2008 2:46 pm
|
Actually it IS in the change log.
It got mentioned when they were discussing these changes in the forums.
# New PCRE library for regular expressions improves trigger matching speed (thanks to Vijilante for his help with this)
# New %subregex routine properly handles substring references such as \1 within the replacement string. Do not use %pat anymore...use the proper PCRE syntax for string replacements. Named substrings also supported
This line is the one about the error message.
# Error messages from compiling PCRE patterns are now reported
I was expecting the error to show on the compiled tab but, I'm not going to complain, New toy!  |
|
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
 |
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Sat Mar 15, 2008 2:54 pm
|
Oldguy2 is correct that the pattern is wrong. The error message is correctly telling what is wrong and where. I did come up with this procedure to demonstrate the error box popping up repeatedly. Basically it appears everytime the trigger attempts to get compiled, and since there is an error the trigger fails to compile and tries again with the next line.
Procedure
1. Launch CMud
2. Close Sessions Window (ESC)
3. Enter at the command line
4. Hit CTRL-Q
This is actually a very nasty bug, because the compilation failure suspends all further trigger processing. This means that one bad trigger could cause your character to be locked up with error messages during a spammy period in the mud.
There are 3 things that need to be done, first is flag that the trigger failed to compile so the trigger is skipped until modified. Second is expand the display slightly to help the user find the trigger. Finally seperate the response to the error box from trigger processing allowing triggers to continue working.
This might be a good thing to put in a new feature...an errors window like the debug window. The error would get logged there, and if the window is not displayed then a visual cue, like an icon, would appear in the command line to indicate a new error was detected. This would eliminate the message box altogether and actually be an excellent way to display all manner of scripting errors. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Sat Mar 15, 2008 5:49 pm
|
Also, in reference to the pattern being wrong - you don't need the .* at the start anyway. If anything, it'll slow down processing. The pattern has (connected|disconnected)\.$ will work just as well, if not better.
|
|
|
|
|
cuprohastes
Wanderer
Joined: 22 Oct 2006
Posts: 92
|
Posted: Sat Mar 15, 2008 10:36 pm
|
| Quote: |
Posted: Sat Mar 15, 2008 5:49 pm
Also, in reference to the pattern being wrong - you don't need the .* at the start anyway. If anything, it'll slow down processing. The pattern has (connected|disconnected)\.$ will work just as well, if not better.
|
Just tried it. It doesn't work.
"Bob has connected."
Does not match. There is a reason for the wildcard. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Sat Mar 15, 2008 10:47 pm
|
Cuprohastes, I just double checked this since a trigger failing to match when it should would be a serious problem. Using this procedure:
1. Launch CMud
2. Close Sessions Window (ESC)
3. Enter at the command line
| Code: |
| #REGEX {(connected|disconnected)\.$} {#SHOW YES} |
4. Enter at the command line
| Code: |
| #SHOW "Bob has connected." |
The "YES" was properly displayed indicating a successful match. I would suggest you check over your settings to try to determine what caused your different result. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
cuprohastes
Wanderer
Joined: 22 Oct 2006
Posts: 92
|
Posted: Sat Mar 15, 2008 10:59 pm
|
It's working... I'm not sure why. I started a blank conjnection, opened it off-line ran those two lines - got a Yes - closed the window and CMUD crashed. Now the regexp in my problem connection is working.
|
|
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Sat Mar 15, 2008 11:00 pm
|
It's working fine for me as well. In fact, you can improve it:
| Code: |
| has (dis)?connected\.$ |
The only time you need a .* at the start or end of a trigger is when your script is interested in what it contains. A match can begin anywhere in a line unless it's anchored, so there's no need to match the extra part of the line. I'm not sure whether the regex engine understands the difference between captured and uncaptured wildcards for optimisation. I assume that it doesn't, and if that's the case your match will be much slower because instead of testing the character h against each letter from the beginning of the string, it tests . against each character of the string (which matches) and then backtracks from the end trying to match the character h. This means that your regex will be much slower to throw out lines that don't match (because it'll test the whole line against . before it starts checking for h at all) and quite slower for lines that do match (because in addition to testing . for each character, it'll then backtrack from the end, which is probably further from the point where the regex matches). So yeah, the only point of that wildcard is if you care about what it contains, and in this case you don't.
EDIT: Ninja :( |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Mar 17, 2008 5:33 pm
|
I'll try to improve the error handling so that it doesn't create a loop like that when loading your files. I want to change this so that the error message gets displayed in the main MUD window like other trigger pattern errors.
|
|
|
|
|
Arminas
Wizard
Joined: 11 Jul 2002
Posts: 1265
Location: USA
|
Posted: Thu May 08, 2008 3:04 am
|
This is mostly fixed in 2.24.
There is no lock or multiple pop ups, but there are no visual error messages either.
The error IS shown in the trigger testing tab though. |
|
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
|
|
|
|
