Zugg Software :: View topic

Posted: Fri Nov 28, 2008 10:17 am

The package I am using is a copy of the package I use in 2.37. In that version all triggers fire successfuly. Under this BETA version no trigger will fire. Further, when I test any of the triggers using the settings editor, it returns "pattern doesn't match".

Posted: Fri Nov 28, 2008 11:53 pm

Give some examples of patterns and text so we can test.

Posted: Sat Nov 29, 2008 12:03 am

What he's getting at is he currently has two versions installed, 2.37 and 3.02. 2.37 works with the same packages 3.02 doesn't. Last night, I had him try:

#TRIGGER {This is a test.} {#SAY Fired!}
and
#SAY "This is a test."

and it didn't fire. Weird. Even a simple trigger should fire. Thought it might be the pcre*.dll file, but that didn't help either. Everything works for me, not him. :\

Charneus

Posted: Sat Nov 29, 2008 5:49 pm

I cannot reproduce any problem with this. Try creating the above triggers in a blank session to see if it's a problem with your package.

Posted: Sat Nov 29, 2008 9:09 pm

I re-installed 3.02B and in a blank session I added the following triggers:

Posted: Sat Nov 29, 2008 10:54 pm

Wonder if something that was installed in 3.01 was inadvertently taken out of the install for 3.02... either that, or the two versions are conflicting with each other in some way...

Charneus

Posted: Sun Nov 30, 2008 12:13 am

Well, if you imported that specific XML, then you're also importing the untitled window, which will contain those triggers. They'll fire only for text that appears in that window. You'll end up with two separate windows called "untitled" because the UIDs will be different.

Posted: Sun Nov 30, 2008 12:38 am

I didn't import the triggers, I created the triggers in a blank session just as I was asked. Since there were only two settings I found it just as convenient to get the XML from the widow setting.

Enchanter Joined: 11 Feb 2003 Posts: 511 Location: USA

I tried it out and the only one that didn't work for me was the command input one. don't know why as I was only using #SAY TEST as my test string.

Posted: Mon Dec 01, 2008 6:26 pm

OK, this is odd. Today when I run the tests above, they fail for me too. But they were working last Friday when I tried it. So something is definitely wrong. It looks like something to do with the new PCRE78.DLL not working properly, so I'm going to need to revert to the PCRE76.DLL until I can track this down.

Maybe Vijilante will have a clue as to why this isn't working. Rebooting my computer seems to have helped, so it's some sort of problem with the DLL getting stuck somehow.

Edited: Actually, rebooting didn't help this time. I don't know what is wrong. Maybe it's an uninitialized variable somewhere either in CMUD or in the PCRE DLL. I copied the previous PCRE76.DLL over to the CMUD 3.02 directory and then renamed it PCRE78.DLL and the same problem happened. In fact, it's almost like it's not loading the PCRE78.DLL at all. If I remove it, then I do get an error message saying it couldn't load PCRE. But my test scripts don't work in the same manner. So it's almost like CMUD is checking for the presence of the DLL, but not really loading it. Or only loading it sometimes. I know I ran my test script successfully last Wednesday when I released 3.02, so I still don't know how it worked then but didn't work now. But it's definitely something I will look more into and let you know.

Posted: Mon Dec 01, 2008 7:07 pm

This is driving me crazy. CMUD works fine on my system here from one directory, but not from another. And as far as I can tell, the files are identical. A fresh install definitely seems to have a problem compared to an existing install directory. But like I said, I haven't determined what the difference between the directories is yet.

Posted: Mon Dec 01, 2008 7:13 pm

FOUND IT!

Somewhere in CMUD it is still trying to use PCRE76.DLL instead of the new PCRE78.DLL. If you copy the PCRE76.DLL from your CMUD 2.37 directory into your CMUD 3.02 directory, then triggers will work. I am trying to track down the exact cause of this. The initial DLL loading is definitely looking for the new 7.8 version because it gives an error message if the PCRE78.DLL is not found. But somewhere else in CMUD it is still silently using the 7.6 version and is not giving any error when it can't find it.

So ALL triggers will fail unless PCRE76.DLL is in the same directory as CMUD.EXE.

Posted: Mon Dec 01, 2008 9:12 pm

So installing the new version over existing versions do not remove any files? I would have thought it did, but if what you say is true, then it doesn't because none of my triggers have failed to fire.

Interesting, though. I had suspected it was the pcre all along, but since I only script and not program, I couldn't be sure.

Still, glad you found it!

Charneus

Posted: Mon Dec 01, 2008 9:29 pm

No, installing over existing versions *never* removes any files. This is actually true for all software. Only if software uninstalls the old version first will it remove files. Uninstallers don't remove all files (especially user-created files), but in the case of CMUD, uninstalling 2.37 *does* remove the PCRE76.DLL file.

So this problem would only occur if you uninstalled 2.37, or if you installed 3.02 to a new directory. When I tested 3.02 here, it was in an upgrade-from-2.37 directory. It was only when I did a fresh install that I was able to reproduce the reported problem.

And yes, this might be related to that weird PCRE message that you got when you tried to revert to 2.37 (mentioned it in some post that I can't find now).

Anyway, it's fixed for the next version.

Posted: Mon Dec 01, 2008 10:37 pm

I re-installed 302B, copied PCRE76.dll to its folder in Program Files. I loaded the version and in an untitled session I added the test triggers. They work just fine, confirming your diagnosis. When Charneus told me about his PCRE problem and concerns, I tried renaming PCRE78 to PCRE76, which , of course, didn't work for the reasons you indicated. One thing that baffled me was that even though I was running two versions, Control Panel only shows that the 302B version is installed. Because of this, I was misled in my assumptions. Thanks for your work, Zugg, and thank all of you for your help.

EDIT: Live running appears to be fine.