Zugg Software :: View topic - [2.25] ?Scoping? issue. Variables being duplicated next to each other.

Posted: Tue May 27, 2008 1:59 am

This has been happening for several versions now, but I have not been able to reproduce it reliably until now.
I still can't give you procedures, but I have a package to send to Zugg, in which the procedure will hopefully work.

In the above screenshot, note the maxH and maxM variables. They are set top autotype. No default values. Also the second trigger in the list of four. That trigger is:

<trigger priority="60" id="6">
<pattern><![CDATA[Health: &%dcurH/&%dmaxH Mana: &%dcurH/&%dmaxM$]]></pattern>
</trigger>

And that is the only place in script where those variable's values are set. This is a self contained package, and when I wrote it, I used different variable names to the ones I used to use for my autosipping, to prevent any problems from rogue/lost duplicate setting names.

After typing 'score' to see:
"Health: 3163/3740 Mana: 2960/3020"
The maxH and maxM variables are duplicated, as you can see in the screenshot.

If I delete the top one of each duplicated pair, and type 'score' again, they are duplicated again.

I am sending the package file to Zugg now.

Adept Joined: 27 May 2008 Posts: 299

I am having this same issue time and time again, very frustrating... I as well can't figure out the steps to reproduce the issue accuratly. The only fundamental difference in my setup compared to his is im using zscript for the pattern and not regexp. When im reassigning a var using var = 2 as well as when I use #ADDITEM it also seems to be duplicating the var's... It seems that if as soon as I load the package, I move all the variables from one class to another (and then back again if you so wish, but its not required) then they won't duplicate. Someone suggested I use the Absolute path... ie //module/class/subclass/var instead to try to fix the issue, but I havn't had a chance to test this yet.

Adept Joined: 27 May 2008 Posts: 299

Fixed. Well found a work around. If you use #VAR var value it works, without using absolute path... Although using the absolute path on the #ADDITEM did keep those from duping as well... Still had some duping when I used //Module/Class/Var = value. Still a bug tho, Should be able to just use var = val without any issues.

Wizard Joined: 26 Mar 2008 Posts: 1547

I've noticed a lot of added variables, particularly those doing with lists or databases or something. I figured it was a fault of mine, not the program. But I could be wrong, usually am.

Posted: Wed May 28, 2008 3:27 am

Posted: Wed May 28, 2008 7:34 am

I may be wrong about this and even if I am not, it may have nothing to do with the problem but it seems that your trigger is capturing prompt data, if this is the case then it should look like this...

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

It's not a prompt trigger. It's a score trigger. The %d in the &%dcurH tells the client to only capture a number, so it is a good idea here. Nothing wrong with Caled's trigger the way he's written it.

Adept Joined: 27 May 2008 Posts: 299

Yeah, as Larkin said the trigger is good. And of course if you create a variable within the script for the first time its going to populate it in the root class, unless specified otherwise. The issue here is the var's are created manually in their proper classes, then when they are assigned via script its duplicating them in the same class as the origional ones were put in. I managed to fix mine using a few work arounds like using #VAR instead of var = val and using absolute path for my #ADDITEM's. But, its still a bug.

Wizard Joined: 26 Mar 2008 Posts: 1547

I define all of my classes and such, though my scripts still reference variables in different classes.

Posted: Wed May 28, 2008 4:03 pm

I mentioned more in my email to Zugg, but I think the bug is not in the trigger, or even variable assignment, but that the package is corrupted, and specifically, those two variables.

There seems to be some interest in this thread, so I've uploaded the package to the package library. It is called 'CaledsAutosip' and you can test it in Aetolia on a freshly created newbie (all you need to be able to do is type "score").

The procedure is to open up the PE, find the duplicated variables (screenshots in OP is all you need for that), delete the TOP one of each duplicated pair (leaving the other two).
Then switch to the main window and enter "score" at the command line. Then check the PE again and the variables should be duplicated again.

I know that the way to deal with a corrupted package is to rebuild from xml, but this bug seems to appear elsewhere from time to time and is very hard to track down for Zugg. This package is only a few weeks old and is very small - so I am hoping Zugg can reproduce it and perhaps finally be able to nail an annoying bug that does occur for others yet with no apparent reason behind it.

Don't be too confused at the simplicity/inconsistency of the script itself - its a work in progress and I'm not actually using it yet. I am slowly getting around to building it as I decide exactly how I wish to write it.

Posted: Wed May 28, 2008 4:21 pm

I should go ahead and put my two cents in.

Anaristos, some education: Like Larkin said, %d is good to use here as it tells the trigger to only capture a number. If you were to use just &var, then it'd be telling the trigger to capture anything that follows that pattern. So, if for some odd reason, there was a line that said "Health: word1/word2 Mana: word3/word4," then that line would be captured as well.

Caled: Not sure about corrupted packages being the issue. If it is, then it's very easy to corrupt a package. I recently had a trigger that defined the class I wanted all my stuff to go into, then defined the variables below, then closed the class out. To illustrate:

Enchanter Joined: 09 Sep 2007 Posts: 605

Heh, I have a package in which all what you need to see this bug is just open your session offline and press a button! I'm not going to e-mail it to Zugg now though, as he seems busy last week.

Update: I should write my reply earlier as it cause Zugg magically appears on forum. Laughing

Posted: Wed May 28, 2008 8:11 pm

Posted: Tue Jun 03, 2008 6:46 pm

Arde, if you can still send me the package that shows this bug when pressing a button, please email it to me asap so that I can test to see if I fixed it or not. Thanks.

Enchanter Joined: 09 Sep 2007 Posts: 605

Zugg
sent it twice, my ISP' mail server did not want connect with your wolfpaw mail server Sad

But wait, I have receive a confirmation e-mail from support@... - its number is 27905. ("Thank you for your inquiry. Your request has been received and is being reviewed by our support staff. ") Have you see that e-mail? If no, I'll try another mail account.

Enchanter Joined: 09 Sep 2007 Posts: 605

Zugg
Ok, I sent test package from a free mail account. Please confirm when you receive it.

Posted: Tue Jun 03, 2008 8:01 pm

Yep, got it and the problem seems to be fixed in 2.26.

Enchanter Joined: 09 Sep 2007 Posts: 605