Page 1 of 2
Feature: Macrosupport for the new AdvLoot system
Posted: Mon Apr 13, 2015 10:14 am
by EqMule
I was just gonna do this and include in next zip, but as I dug into it, I realized that it's very involved and it will take me several hours of looking at the assembly as well as writing the code, debug etc to finish it.
I want to see if there is any interest in helping out by contributing to get a new TLO for AdvLoot, that can let us interact with the system from a macro in an easy way.
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Mon Apr 13, 2015 1:36 pm
by Randyleo
It would be more, but budget is tight right now.
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Mon Apr 13, 2015 7:35 pm
by warlock45
will be frank
truck died, money is tied up till next month/month after. Have to afford getting to work before my EQ addiction.
Paypal decided not to like me no mores, but will drop something via card when I can, for what it is worth. I know that is all " I will glady pay you tues..." but it is the best I got at this time =)
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Tue Apr 14, 2015 10:05 am
by JudgeD
I'd love to have something like this setup. If you don't make it, I will, and mine won't be as cool :)
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Wed Apr 15, 2015 5:42 pm
by EqMule
Not much interest for this one it seems, I'll work on it in off hours got personal loot done gonna work a bit on group loot now...
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Wed Apr 15, 2015 8:17 pm
by dewey2461
I'm still trying to figure out how the new system works so not sure how I'd go about automating it.
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Wed Apr 15, 2015 8:50 pm
by EqMule
/echo ${AdvLoot.PList[1].Name}
Output: [MQ2] Bone Chips
/echo there are ${AdvLoot.PCount} items in the personal loot list
Output: [MQ2] there are 3 items in the personal lootlist
/echo the item in index 1 has a StackSize of ${AdvLoot.PList[1].StackSize}
Output: [MQ2] the item in index 1 has a StackSize of 2
Alright at this point we know the item in index one is a stack of 2 bone chips
Now we can decide to do something about it:
/advloot personal/shared 1 leave
That will click the leave button...
/advloot personal/shared 1 ag
That will click the ag checkbox
And so on...
Finally you can do
/advloot shared set Eqmule
Or whatever other group member or Never or Leave on corpse or any of all the other choices in the combobox for shared loot and it will set it..,
So there... Automated... I'll try to release something for test a bit later... But this is basically how it works right now...
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Thu Apr 16, 2015 5:04 pm
by JudgeD
My pledge sent, thanks Mule
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Sat Dec 26, 2015 8:00 pm
by Ralindal
I've been testing this, and I noticed something odd.
I leave loots in the window and put them to "free grab", so the window is always open and there's usually some stuff in there that is on free grab.
What I've noticed is that when I get the SList.Count and I (reverse) iterate through the items, and loot the ones I want that it the index (let's stay item 12) does not match with the position you can specify for the /advloot command. So, ${AdvLoot.SList[12].Name} tells me "Diamond", and then I do "/advloot shared 12 giveto ${Me.Name}" and it turns out to be a different item than expected.
Here's the actual code so you can see there's no bugs in it:
Code: Select all
int lootCount = Integer.parseInt(session.translate("${AdvLoot.SCount}"));
for(int itemNo = lootCount; itemNo > 0; itemNo--) {
String itemName = session.translate("${AdvLoot.SList[" + itemNo + "].Name}");
LootType lootType = determineLootTypeFromIni(itemName); // IGNORE for everything except Diamonds etc..
if(lootType == LootType.IGNORE) {
session.doCommand("/advloot shared " + itemNo + " no");
session.delay(500);
continue;
}
boolean alreadyHaveLoreItem = session.translate("${FindItem[=" + itemName + "].Lore}").equals("TRUE");
if(alreadyHaveLoreItem) {
session.doCommand("/advloot shared " + itemNo + " no");
session.delay(500);
continue;
}
session.doCommand("/advloot shared " + itemNo + " giveto " + me.getName());
session.delay(500);
}
session.doCommand("/advloot shared set \"enable free grab\"");
session.delay(500);
I also noticed there is no way to set free grab on for a single item (although the UI offers it), something like "/advloot shared 5 fg"
--Ralindal
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Sat Dec 26, 2015 8:11 pm
by JudgeD
How often does this happen? I've done that same logic pattern via macro for awhile now and never had it fail.
Unrelated but I did this instead of a hardcoded delay:
Code: Select all
/delay 1m ${lootCount} >= ${AdvLoot.SCount}
Also, looks like you're writing a plugin? That's exciting :)
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Sat Dec 26, 2015 8:17 pm
by JudgeD
Ah, I might have an idea why this is failing.
I wouldn't loop through things with a hardset lootCount
Code: Select all
int lootCount = Integer.parseInt(session.translate("${AdvLoot.SCount}"));
This causes you to assume that the loot amount isn't going to change until the entire for-loop is done. If things get added in between looting and new items hitting, that might screw it up. Seems likely. Even if this isn't your break, you're not really traversing in reverse order if things get piled on above your old lootCount index.
I would re-evaluate on the fly instead, and grab it directly from SCount
In my macro, I just attempt to loot if SCount > 0. Then I set my "currentIndex" to SCount and quickly deal with it. That way each loop gets to re-evaluate AFTER the hardcoded loot delay has finished.
In your example, you have 12 items, and 500 millis per cycle, so 6 seconds of possible new items hitting your loot window before it's done. If you just looted something then get 5 new items, now your lootIndex is below your SCount.
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Sat Dec 26, 2015 9:16 pm
by Ralindal
The loot is triggered though after a fight finishes (xtarget is clear). Any new items that would be added would have to come from a new pull which certainly isn't going to die in a couple of seconds
I'll see if I can trace it down a bit further, or change it to use /advloot shared <name> instead.
I used to code from advloot.inc and converted it to Java (the reverse loop idea came from there). Also the /delay 5 in there is the same as 500 ms.
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Sat Dec 26, 2015 9:22 pm
by Ralindal
I'll try a start delay... perhaps the list is still populating with the items from the latest kill, causing this glitch.
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Sat Dec 26, 2015 9:24 pm
by warlock45
heh if nothing else, thanks for reminding me to make good on my donation for this.
Might be slow but I get there eventually...
Re: Feature: Macrosupport for the new AdvLoot system
Posted: Sat Dec 26, 2015 9:30 pm
by warlock45
your advloot list can change even when you are not fighting, as things get rolled on, or roll off the list.
I do not use a macro for assigning loot via the advloot system, but rather have been trying to build one toon as a master looter via the advloot ( IE doing it by hand mostly) but using the advloot commands to, at the very least, mark crap loot "/bcaa //advloot shared 1 nv" I do notice that the number of items sometimes gets off though, say when I do slot 5, it sometimes does slot 4 or 6. I find it is always accurate on 1 though.
It is not something that happens all that often for me so I have not overly worried about it, but it is something that is reflected across all clients when it does happen (IE is not a single toon's glitch)