TrailMyx's Advanced CLAw FULL - The Ultimate Autolooter - Public Release!

[TrailMyx]

Yeh, it's not all that bad.  Instead of redesign I opted for locating all the buttons that weren't being deleted before being redrawn and delete them first.  It's a bit of a hack, but it works I think as Cheffe originally intended before he change the rules after 15 years.

Give this version a try.  I'm not sure I got every instance, so poke at it until it breaks.

One of these days I need to play around with the props stuff like you have been Gad.

[TrailMyx]

The specific problem that jenovauh pointed out was with the buttons.  It was something that I brought up with Cheffe quite a while back, but he refused to do any kind of garbage collection on his end.  So it's basically possible to create 2 or more of the same buttons with the same name, but only one of the buttons retains the "Pressed" callback.  The other one becomes an orphan and become useless.  It became apparent when you look at the #MENUBUTTON variable.  It becomes non-functional once a new button of the same name is created.  Anyhow, still irked that Cheffe couldn't account for existing controls of the same name, but oh well.  It was his bug in the first place that we all though was a feature and utilized. In the long run, I have no idea how many scripts it broke.  I know it broke my Item Finder and the CLAw.  I'm sure there's many others.  Since there's so few scripters actively scripting anymore, it's extra silly.

[jenovauh]

Hmm, I can't seem to replicate either one of of your issues.  Which arrow are you clicking?  Are they the zoom arrows?

For the adding rules, are you talking about taking rules from the Rule entry and adding them to the Active list?  I think I see some odd behavior there.  Should be an easy fix.

Sorry for the last reply. I mean left and right arrow under Preview or History tab. The one that you can press to backward and forward to view item looted.

[jenovauh]

I tested the latest version you posted, it working well with the forward and backward button now. And i think I found another weird behaviour.

For example when i set rule to loot jewelry and save setup. Test it and it does not loot jewelry at all. But if i stopped the script at easyuo and start again. It will evaluated and loot them. Same for treasure map. Somehow some other rules that i did, after saving and include on the active rule. They does not work and have to stop script and start again.

[TrailMyx]

I'll make a note of that.  Since I don't really play too much, any play-style testing is just something I can no longer do.

One thing the script does do is maintain an ignore list.  Once an item is looted, it will be ignored until the script is restarted.  This list refreshes every 5 minutes or so.  Could this be what you are seeing?

[jenovauh]

I'll make a note of that.  Since I don't really play too much, any play-style testing is just something I can no longer do.

One thing the script does do is maintain an ignore list.  Once an item is looted, it will be ignored until the script is restarted.  This list refreshes every 5 minutes or so.  Could this be what you are seeing?

No i don't think that's the case, i did try to loot from monster from all different corpse and i check every item myself. I am currently testing the script again and found something i never see before. The added rules become some coding text making it invalid rules. i am trying to replicate it but it did happen again. Will post what is the coding text again. I remember it is something like RULE8NA..........

[TrailMyx]

I'll make a note of that.  Since I don't really play too much, any play-style testing is just something I can no longer do.

One thing the script does do is maintain an ignore list.  Once an item is looted, it will be ignored until the script is restarted.  This list refreshes every 5 minutes or so.  Could this be what you are seeing?

No i don't think that's the case, i did try to loot from monster from all different corpse and i check every item myself. I am currently testing the script again and found something i never see before. The added rules become some coding text making it invalid rules. i am trying to replicate it but it did happen again. Will post what is the coding text again. I remember it is something like RULE8NA..........

Well if you see that RULE8N kind of thing, it means your save file has been corrupted.  That'll definitely cause issues. 

I did some basic testing with maps and rings a little while ago, and I don't seem to have the same issues you are having.

[jenovauh]

Well if you see that RULE8N kind of thing, it means your save file has been corrupted.  That'll definitely cause issues. 

I did some basic testing with maps and rings a little while ago, and I don't seem to have the same issues you are having.
[/quote]

Maybe it is due to the rule file corrupted, but no idea how that will happen. I will delete the file and create a new one and see what happen.

[lit2fly]

The specific problem that jenovauh pointed out was with the buttons.  It was something that I brought up with Cheffe quite a while back, but he refused to do any kind of garbage collection on his end.  So it's basically possible to create 2 or more of the same buttons with the same name, but only one of the buttons retains the "Pressed" callback.  The other one becomes an orphan and become useless.  It became apparent when you look at the #MENUBUTTON variable.  It becomes non-functional once a new button of the same name is created.  Anyhow, still irked that Cheffe couldn't account for existing controls of the same name, but oh well.  It was his bug in the first place that we all though was a feature and utilized. In the long run, I have no idea how many scripts it broke.  I know it broke my Item Finder and the CLAw.  I'm sure there's many others.  Since there's so few scripters actively scripting anymore, it's extra silly.

Thanks for fixing the button issue. I also noted #MENUBUTTON became non functional after clicking some of the buttons and now you've explained the reason behind!

[jenovauh]

The specific problem that jenovauh pointed out was with the buttons.  It was something that I brought up with Cheffe quite a while back, but he refused to do any kind of garbage collection on his end.  So it's basically possible to create 2 or more of the same buttons with the same name, but only one of the buttons retains the "Pressed" callback.  The other one becomes an orphan and become useless.  It became apparent when you look at the #MENUBUTTON variable.  It becomes non-functional once a new button of the same name is created.  Anyhow, still irked that Cheffe couldn't account for existing controls of the same name, but oh well.  It was his bug in the first place that we all though was a feature and utilized. In the long run, I have no idea how many scripts it broke.  I know it broke my Item Finder and the CLAw.  I'm sure there's many others.  Since there's so few scripters actively scripting anymore, it's extra silly.

Hi TM, I found another issue on the backward and forward. If you enable preview mode, after evaluating and go to the preview tab to view items found, after click backward or forward, the same issue happen to the history view. Which portion of the script does that? Maybe i can edit myself to fix the issue. So sorry to trouble you again. Thank you so much.

[TrailMyx]

Hi TM, I found another issue on the backward and forward. If you enable preview mode, after evaluating and go to the preview tab to view items found, after click backward or forward, the same issue happen to the history view. Which portion of the script does that? Maybe i can edit myself to fix the issue. So sorry to trouble you again. Thank you so much.

I probably got 90% of the buttons, but I'm sure you point out one I didn't get.  I'll add that one to the list, and when I have a bit more time (probably this weekend) I'll sift through the script more carefully.  Work is kicking my butt atm though.

[TrailMyx]

Thanks for fixing the button issue. I also noted #MENUBUTTON became non functional after clicking some of the buttons and now you've explained the reason behind!

Yeh, it's an annoying issue and wasn't totally clear when it first came up.  I did try to talk Cheffe into fixing it on his end to maintain existing script compatibility, but I guess my argument wasn't compelling enough.

Here's a link to my request:

http://www.easyuo.com/forum/viewtopic.php?f=2&t=53155&p=431320#p431320

[Gaderian]

First, I think the dynamic lists make a really slick UI. I came to this EUO party late (I wasn't playing 12-15 years ago and was not fluent in the scripting language), but I have often embarked on some personal project in the past several years only to discover TM did it way back when. I will add that the recursion is something I never would have attempted - so definite kudo's on that aspect of this script.

I mentioned my attempts that have led me to think a redesign would be required to make it work. Specifically getting rid of any "menu delete" commands for buttons and adding a status of keeping track of whether the button has been already created within the script.

My work around for button issues is to create all necessary buttons in the original menu form creation.
Any buttons that are not needed with this initial menu creation, set the property to "invisible #false":

Code: easyuo

1. menu setprop BUTTONNAME visible #false

Then as a button would be swapped (deleted/created in the same place), set the old and new buttons to be appropriately visible:

Code: easyuo

1. menu setprop OldButtonName visible #false
2. menu setprop NewButtonName visible #true

This means that no buttons have the same name (because of delete/create logic) and the active buttons are available.

Following that recipe, I have no menu issues over #MENUBUTTON.

This recipe has the issue of the dynamic list creation means you may not know all the buttons required when doing the initial form creation. To get around this, setting a status that the button has been created would be a logical modification. Test for a variable which matches the button name (probably with a prefix) and either create or do the setprop visible options seems to me the best solution to allow the dynamic library to work seamlessly. Altering the delete of the button would be required.

IMHO that is the best way to deal with the current ruleset of EUO and it's #MENUBUTTON idiosyncracies.

Gaderian

[jenovauh]

Hi TM, I found another issue on the backward and forward. If you enable preview mode, after evaluating and go to the preview tab to view items found, after click backward or forward, the same issue happen to the history view. Which portion of the script does that? Maybe i can edit myself to fix the issue. So sorry to trouble you again. Thank you so much.

I probably got 90% of the buttons, but I'm sure you point out one I didn't get.  I'll add that one to the list, and when I have a bit more time (probably this weekend) I'll sift through the script more carefully.  Work is kicking my butt atm though.

Take your time TM, I just report any bug that i had found so other will know as well. Thank you so much for helping too.

[lit2fly]

TM, you mentioned Lower Requirements is not working in script comment and indeed that's also what I observed.

Do you have a bit of background what's wrong with it maybe I can help to do some digging in the code?