-
Hail, we're RedGuides. We want you to play six (yes, 6!) EverQuest characters at once. We have scripts and a friendly community to help, please join our playstyle and say hello! 👋
- Thread starter ChatWithThisName
- Start date
Hey Bud,
Just an update, I know this is still being worked on. Wanted to bring up that items marked Delete are not being deleted. I've used /lootdestroy as well as manually editing the INI. Tons of trades drops are being collected that are marked.
Oh, and since I don't use =quest or looton=0 haven't run into what you were talkin about.
Regards,
~ Incog
- - - Updated - - -
Update: Um, ok, my bad, it looks like just one toon isn't getting items destroyed. I will troubleshoot.
Just an update, I know this is still being worked on. Wanted to bring up that items marked Delete are not being deleted. I've used /lootdestroy as well as manually editing the INI. Tons of trades drops are being collected that are marked.
Oh, and since I don't use =quest or looton=0 haven't run into what you were talkin about.
Regards,
~ Incog
- - - Updated - - -
Update: Um, ok, my bad, it looks like just one toon isn't getting items destroyed. I will troubleshoot.
I have noticed items that should have been destroyed too. When I can get time I'll try to figure out what I did to mess it up.
It is suppose to. I messed something up few days ago and have not quite figured out what. Real life kicked me in the teeth but I am hoping to have this resolved before the weekend depending on tomorrows patch. Look for new file on Friday if the patch doesn't mess things up too bad.
Edit:
You will need to insure the Loot.ini file setting StackPlatValue=0.
Last edited:
A one off: ML dies, before getting/accepting rez, mob in camp dies (prolly the one that killed him), then ML is rez'd. The loot in his personal loot window locks him out since he wasn't there at the time of the mob's death. It causes ML to hang. He does not proceed, code (in this case KA) is stopped/hung. I have to select 'Leave' (big red X) in his personal loot window for anything to resume. He woulda hung there indefinitely if I hadn't been there.
- - - Updated - - -
AND, if he is the cleric, TPW will ensue. Hot Tip: Don't let your clr loot. A lot like when Raz says don't have your wizzy loot, it will just reduce his DPS. Now all we got to do is iron out the loot=0 issue(s).
- - - Updated - - -
AND, if he is the cleric, TPW will ensue. Hot Tip: Don't let your clr loot. A lot like when Raz says don't have your wizzy loot, it will just reduce his DPS. Now all we got to do is iron out the loot=0 issue(s).
Really, your gonna make me kill my toons just to puzzle out how to prevent hangup if looter dies?!?
Please explain the loot=0 issue again. I seem to have forgotten.
Lol Mate, you told me about it, I hadn't used loot=0 up till the point I realized certain classes (clr and wiz) shouldn't be looting. This is my first wizzy (well, in the main grp - have a cpl heroics), and I just now wanted to turn off looting for the clr. So I'm not sure, have to go back thru conversations we've had to try and glean it.
And no, the real solution here is to not allow looting (certain classes), so you don't have to kill all your peeps...
I'll tell you what that is tho, it's that the looter can't loot his/her personal loot window due to lock-out. Just need a time-out and 'leave on corpse' or, some way to just give up on those items (prolly too late to 'leave on corpse'), or, if you can tell from code that the items are locked out, just automate hitting the red X.
* Update *
Hell, if you can hit the red X from code, then that might be a solution. Say if nothing has happened in some 30 seconds or so, and not in battle, give up, let the items go rot. You aint gonna get them if you haven't in x (30?) seconds. *shrug*
And no, the real solution here is to not allow looting (certain classes), so you don't have to kill all your peeps...
I'll tell you what that is tho, it's that the looter can't loot his/her personal loot window due to lock-out. Just need a time-out and 'leave on corpse' or, some way to just give up on those items (prolly too late to 'leave on corpse'), or, if you can tell from code that the items are locked out, just automate hitting the red X.
* Update *
Hell, if you can hit the red X from code, then that might be a solution. Say if nothing has happened in some 30 seconds or so, and not in battle, give up, let the items go rot. You aint gonna get them if you haven't in x (30?) seconds. *shrug*
Yeah, I remember. LootOn=0 in the kissassist file. It is interfering with the looting of items marked quest. It is more an issue with how kissassist calls looting. Easily fixed by adding a looting call to the main loop in kissassist. I did finally find what I messed up. NOTE TO SELF: do not drink and code at the same time. If me test group makes it through the rest of today, I'll post an updated file tonight, that includes some minor fixes and the new process for nodrop items.
EDIT - letting the master looter or any group member die just seems like a bad idea to me. I'll try to duplicate that over the weekend.
EDIT - letting the master looter or any group member die just seems like a bad idea to me. I'll try to duplicate that over the weekend.
Ok, glad you found/remembered it. I went back thru previous conversations and nothing jumped out at me so was beginning to think I mis-read something. I am currently not using =quest (combined with loot=0?) so hasn't been an issue for me. Although we might have concluded somewhere along the way that =quest solves a problem (lore drops not already in the INI?). Currently, I identify something, that's not in the INI, that drops, is lore, and I want, and manually add it as keep. No big deal since that is what I had to do with the old Ninja. I will have to get around to messin with =quest... just haven't yet.
Hope all is well!
Hope all is well!
Updated file: 6/23/16
corrected/improved several minor issues.
added selectable action for new nodrop items
added new loot.ini setting NoDropDefault=Quest|Keep|Ignore
pick how you want ninjadvloot to add nodrop items =quest, =keep, =ignore
quest is the default, if no setting item will be ignored and left on corpse
- - - Updated - - -
if you set StackPlatValue=0 in your loot.ini LORE items should be automatically set to =keep
nodrop items is now selectable. =quest, =keep, =ignore
corrected/improved several minor issues.
added selectable action for new nodrop items
added new loot.ini setting NoDropDefault=Quest|Keep|Ignore
pick how you want ninjadvloot to add nodrop items =quest, =keep, =ignore
quest is the default, if no setting item will be ignored and left on corpse
- - - Updated - - -
if you set StackPlatValue=0 in your loot.ini LORE items should be automatically set to =keep
nodrop items is now selectable. =quest, =keep, =ignore
Super work Mate! DLing now.
- - - Updated - - -
Dude, love ya Bro, but I rename my KA.mac so I can keep the previous 8.5.5 release and the beta KA9 and load whichever I wanna use (which has been for some time now kissassist9).
Ok ok, just like I wont ask you to kill all your peeps, I wont make you ask me to rename 9 to regular old kissassist. Here's what I'll do: I will rename KA8 to something that reflects ver 8.5.5 and rename KA9 to kissassist. Spose I shouldn'ta posted since I can fix this meselfs... but why pass up the chance to rib ya? Damn, have to update all my hotkeys now...
- - - Updated - - -
Rich (BB code):
/declare 'MacroVer' falied. name already in use/
ninjaloot.inc@677 (UseAdvLoot): /if (${Macro.Name.NotEqual[Kissassist.mac]}) /declare MacroVer int local 0Dude, love ya Bro, but I rename my KA.mac so I can keep the previous 8.5.5 release and the beta KA9 and load whichever I wanna use (which has been for some time now kissassist9).
Ok ok, just like I wont ask you to kill all your peeps, I wont make you ask me to rename 9 to regular old kissassist. Here's what I'll do: I will rename KA8 to something that reflects ver 8.5.5 and rename KA9 to kissassist. Spose I shouldn'ta posted since I can fix this meselfs... but why pass up the chance to rib ya? Damn, have to update all my hotkeys now...
Better fix so you don't have to rename macros or change hotkeys
change the code to
should work just as well else try
just remember to do it each time you get new update
change the code to
Rich (BB code):
(!${Select[${Macro.Name},kissassist.mac,othername.mac]})should work just as well else try
Rich (BB code):
(${Macro.Name.NotEqual[Kissassist.mac]} && ${Macro.Name.NotEqual[othername.mac]})just remember to do it each time you get new update
Maskoi warned me not to use variables from kissassist....
Now to try and cause the looter to lock up by not being present, wonder if I can do that without killing him...
Now to try and cause the looter to lock up by not being present, wonder if I can do that without killing him...
updated file: 6/29/16
Locked loot items should now be properly processed, no longer causing the macro to hang-up.
Locked items will be left on corpse, this will likely cause you to miss a desired item occasional.
Locked loot items should now be properly processed, no longer causing the macro to hang-up.
Locked items will be left on corpse, this will likely cause you to miss a desired item occasional.
macroquester
New member
clicky item of some sort... probable the fellowship/campfire thing. I rarely carry more then 6 bags of any kind.
Do I want to know the reason for this question?
Now you make me curious. No, I won't try it.... Yes, I will, sigh.
Now, it could be only an issue if ALL other slots are full of bags, don't know. Not sure I have tried the first slot and not had all others full with a bag. I mean I usually only fill that first slot with a bag if all others have bags. Otherwise there would be an 'exchange' item like a bow, or on older toons a greater lightstone etc... My monk uses the first slot for 'exchange' between a weapon and his throwing ammo. Exchange gets funky if thing you are exchanging is not in the first slot. But all that aside, a bag in the first slot is definitely causing issues that I hope you can replicate.
1) Quest items marked as destroy are not getting destroyed. Once we started having destroy issues they never went away for me. I attributed that to having not completely shut down and restarting PC for some weeks and that perhaps MQ2, or Windows, et al, was caching something. I did an MQ2 update (for the autologin) after a full shut down and was surprised I am still having the same destroy issues. Anything relating to Rogue quests i.e.: Pristine Privit, Purified Grade AA Taipan Venom, Pristine Delphinium, Immaculate Larkspur, Distilled Grade C Gormar Venom, etc (many more), all Rogue Quests, marked delete, and not deleting. They fill up bags at an alarming rate. I have the default QuestKeep=10, wonder if that might be a conflict with items marked =delete.
2) I know of at least one drop that is not quest, but rather a tradeskill item, that is marked for delete and not deleting: Smudged Runic Orphic Card. The Runic Cards have a whole family of crap that drops, with slightly different names, all marked destroy, not quest items, and not destroying. However the rogue quest crap is my biggest nemesis.
3) Up to till recently, once bag space was < 3, it would assigned a new ML. For probably a week now, it starts rolling on all loot rather than picking a new ML. The roll process takes a long time and it isn't long before there are corpses everywhere and 50 items either being rolled on, or waiting to be rolled on.
1) Quest items marked as destroy are not getting destroyed. Once we started having destroy issues they never went away for me. I attributed that to having not completely shut down and restarting PC for some weeks and that perhaps MQ2, or Windows, et al, was caching something. I did an MQ2 update (for the autologin) after a full shut down and was surprised I am still having the same destroy issues. Anything relating to Rogue quests i.e.: Pristine Privit, Purified Grade AA Taipan Venom, Pristine Delphinium, Immaculate Larkspur, Distilled Grade C Gormar Venom, etc (many more), all Rogue Quests, marked delete, and not deleting. They fill up bags at an alarming rate. I have the default QuestKeep=10, wonder if that might be a conflict with items marked =delete.
2) I know of at least one drop that is not quest, but rather a tradeskill item, that is marked for delete and not deleting: Smudged Runic Orphic Card. The Runic Cards have a whole family of crap that drops, with slightly different names, all marked destroy, not quest items, and not destroying. However the rogue quest crap is my biggest nemesis.
3) Up to till recently, once bag space was < 3, it would assigned a new ML. For probably a week now, it starts rolling on all loot rather than picking a new ML. The roll process takes a long time and it isn't long before there are corpses everywhere and 50 items either being rolled on, or waiting to be rolled on.
Working on the bag in first slot issue.... Do you have bags in all top level slots or is it just that a bag in first slot cause problem?
1. I am using three different loot ini files depending on the group, unfortunately I have to manually change this and have attributed some weirdness similar to what you say to forgetting to use the right ini file. Will have to try and replicate this.
3. That really should not be happening. Is the master looter also your group leader? And does more then one group member have LootOn=1 in the kissassist ini file?
Might have to capture some loot spam. There are two types, SpamLootInfo=1 in the ini file. There is also Debugloot which is normally turned off, you can turn it on using the command
or by editing the /declare Debugloot line in the macro itself.
Use the MQ2Log plugin and the command /mlog on
Assuming you escaped the current ban wave...
1. I am using three different loot ini files depending on the group, unfortunately I have to manually change this and have attributed some weirdness similar to what you say to forgetting to use the right ini file. Will have to try and replicate this.
3. That really should not be happening. Is the master looter also your group leader? And does more then one group member have LootOn=1 in the kissassist ini file?
Might have to capture some loot spam. There are two types, SpamLootInfo=1 in the ini file. There is also Debugloot which is normally turned off, you can turn it on using the command
Rich (BB code):
/varset Debugloot 1Use the MQ2Log plugin and the command /mlog on
Assuming you escaped the current ban wave...
How you doing bud? Doing aight?
Usually, when that first slot has a bag in it, all other slots are full.
I could have a corrupt loot.ini. I have looked it over thoroughly multiple times, but that doesn't mean it isn't corrupted somehow.
ML is not grp leader, could be, should be able to be, but over a week now has not been. Yes, all but clr and wiz have looton.
Ok, will endeavor to get debug logs.
No, did not escape the bans... might be the end for me...haven't decided yet. I am partially waiting to see what DB does.
Usually, when that first slot has a bag in it, all other slots are full.
I could have a corrupt loot.ini. I have looked it over thoroughly multiple times, but that doesn't mean it isn't corrupted somehow.
ML is not grp leader, could be, should be able to be, but over a week now has not been. Yes, all but clr and wiz have looton.
Ok, will endeavor to get debug logs.
No, did not escape the bans... might be the end for me...haven't decided yet. I am partially waiting to see what DB does.
I escaped, I have never bought any codes and the cheap kronos all appear to have been safe. I'm working about 3 years behind everyone else and that suits me fine. Once I learned to be my own group the social aspect of the game was gone for me, except redguides. It will be hard to see EQ die.
If it's a container that only holds certain items, such as the tradeskill bag. You should exclude it from counting as part of your inventory.
Rich (BB code):
ExcludeBag1=Extraplanar Trade Satchel
ExcludeBag2=NULLNewp, general bag, still working on it, have some fires to put out first heh.
- - - Updated - - -
Ok nothing new on the bag in first slot.
I was very hesitant to start over on my loot.ini as I had hundreds and hundreds of carefully set entries, months and months of work. File was almost 30k. But, in the effort of completeness, I created a new blank loot.ini and I'm still getting those damn rogue/tradeskills marked delete being saved. They are so prolific I want to turn loot off entirely. I would except there are diamonds man... Anyway, so it aint cause of a corrupted INI.
How do you think Ninja handles items in the INI with apostrophes in their names?
Sure is a headache filling up my bags with hundreds of tradeskills I don't care about... fuck rogues.
I hope to have details on the bag in first slot shortly.
- - - Updated - - -
Ok, oddly enough, running multiple groups, one group is deleting stuff marked delete (from the fresh INI) and the other isn't. It still smells of something caching but I have rebooted, and therefore restarted MQ2. One clue, although not sure how to decipher it, is the grp that is not deleting is behaving like it did with the old/original INI. meaning it would delete the Mutineer's Head, and nothing else. That is why I was thinking along the caching lines.
But with a reboot, MQ2 nor Windows would hold something in memory. I am baffled at this point but will continue to work on it.
- - - Updated - - -
Ok nothing new on the bag in first slot.
I was very hesitant to start over on my loot.ini as I had hundreds and hundreds of carefully set entries, months and months of work. File was almost 30k. But, in the effort of completeness, I created a new blank loot.ini and I'm still getting those damn rogue/tradeskills marked delete being saved. They are so prolific I want to turn loot off entirely. I would except there are diamonds man... Anyway, so it aint cause of a corrupted INI.
How do you think Ninja handles items in the INI with apostrophes in their names?
Sure is a headache filling up my bags with hundreds of tradeskills I don't care about... fuck rogues.
I hope to have details on the bag in first slot shortly.
- - - Updated - - -
Ok, oddly enough, running multiple groups, one group is deleting stuff marked delete (from the fresh INI) and the other isn't. It still smells of something caching but I have rebooted, and therefore restarted MQ2. One clue, although not sure how to decipher it, is the grp that is not deleting is behaving like it did with the old/original INI. meaning it would delete the Mutineer's Head, and nothing else. That is why I was thinking along the caching lines.
But with a reboot, MQ2 nor Windows would hold something in memory. I am baffled at this point but will continue to work on it.
first question.. are the items marked =delete or =destroy
2nd - have you caught any of the entries in the loot being changed
I ask because the macro reads and matches a string variable... it must match exactly, misspelling or using the wrong entry will result in the macro overwriting the entry to one of the five required. =keep, =sell, =ignore, =destroy, =quest|xx
the item name must be exact as well. I recommend using the commands /lootdestroy, /lootignore, /lootquest, /lootkeep, to make changes.
If you turn on loot spam, it should report at the very beginning what ini file it is using, unless it is the default loot.ini
It should also report what file it is using whenever it adds something new. Wonder if somehow you have more then one loot file causing issue.
Wonder if read/write properties of loot ini file could cause issues??
apostrophes I'm not sure, I know the macro will correctly write entries for item with apostrophes. I assume it would read them properly as well. I have never considered it to be an issue and have not paid any attention to it.
As far as file size, mine is over 50k. I have noticed the bigger the file the longer it takes to loot, but the difference is marginal, at least so far. I made couple new loot files for testing and have noticed the smaller file (under 30k) is slightly faster (10ths of second per item) then the bigger file. I don't think the file size will matter, although if the item is entered more then once... I expect the macro to use the first entry it finds. That might be something to check, make sure the particular item does not have more then one entry. I did actually do that once long time ago and remember it driving me crazy. It kept destroying something I wanted to keep.
2nd - have you caught any of the entries in the loot being changed
I ask because the macro reads and matches a string variable... it must match exactly, misspelling or using the wrong entry will result in the macro overwriting the entry to one of the five required. =keep, =sell, =ignore, =destroy, =quest|xx
the item name must be exact as well. I recommend using the commands /lootdestroy, /lootignore, /lootquest, /lootkeep, to make changes.
If you turn on loot spam, it should report at the very beginning what ini file it is using, unless it is the default loot.ini
It should also report what file it is using whenever it adds something new. Wonder if somehow you have more then one loot file causing issue.
Wonder if read/write properties of loot ini file could cause issues??
apostrophes I'm not sure, I know the macro will correctly write entries for item with apostrophes. I assume it would read them properly as well. I have never considered it to be an issue and have not paid any attention to it.
As far as file size, mine is over 50k. I have noticed the bigger the file the longer it takes to loot, but the difference is marginal, at least so far. I made couple new loot files for testing and have noticed the smaller file (under 30k) is slightly faster (10ths of second per item) then the bigger file. I don't think the file size will matter, although if the item is entered more then once... I expect the macro to use the first entry it finds. That might be something to check, make sure the particular item does not have more then one entry. I did actually do that once long time ago and remember it driving me crazy. It kept destroying something I wanted to keep.
Good points. I am in the habit of doing searches in the INI before concluding anything as I too had found once a dbl entry and insanity ensued. Right now, I have found zero dbl entries. If I find something in my inventory, I search the INI to see 1) if there are dups, and 2) what the item is set for.
The old INI does indeed have a number of apostrophes in it. I removed some of the items since I don't go in the zone that they drop from anymore. But they were too numerous and figured Ninja simply had to deal with them. I did not manually enter those, those are from /lootdestroy, /lootkeep (which are the only 2 I use). The only time I manually edit the INI is when I am doing a search and stumble upon something marked keep that I don't want, and change it to destroy (otherwise I would have to have one of the item on my cursor for the /lootdestroy function to work).
And yes, altho I keep sayin delete, I mean destroy, in all cases, have done many searches for errant words, delete being one of them.
On both ML's, /echo ${NinjaIniFile} returns Loot.ini, no folder, capitol L. However, I see that is set inside the include that way.
Yes, I have witnessed new entries being created in the new INI as I play. I have also witnessed /lootdestroy marking an item that had been initially created with keep to destroy. Well, that's on the ML that is working, not on the other grp. Other grp is still a mystery to me... and yes, same PC, same eqgame.exe, and same MQ2.
These are all good points you bring up: File is not read-only nor hidden. I can find only one of them (did a windows search from the parent MQ2 dir). There is a lootBAK.ini but /echo ${NinjaIniFile} does not return it.
This is the version string from inside the include: /declare NinjadVersion string outer 6.1
SpamLootInfo=1, is that the spam setting you were talking about, it has been on for some time now.
Oh, been meaning to ask, I have 1 toon that carries 2 extraplanar trade satchels. Most others carry 1, and some none. I have it set to only exclude one satchel but it always made me wonder how it dealt with the differences in inventories between toons.
It seems to be working really well right now on the one ML. I am really scratching my head on the other grp. I am still experiencing where the ML fills up, then everything goes to roll rather than choosing a new ML. But that's ok if it's destroying stuff since the bags wont get full.
Wait a minute, it isn't divided by grp, its divided by toon. I have toons in grp 1 that when I have them ML they do not destroy stuff. Only my main enjoys stuff being destroyed (I don't let the wizzy nor the clr loot, but anyone else is fair game). I wonder if there is a plugin or plugin setting conflict, something that is different between accts/toons. lemme take a new approach on this and look for differences between toons rather than the two grps. You mentioned wondering what impact there might be with turning off certain AdvLoot settings. Lemme compare the various settings between the various toons and get back.
- - - Updated - - -
Ima thinking a couple things; the inventories need to match, toon to toon, and 2) the bag exclusion might be funky.
I am not excluding any bag in the new INI.
The old INI does indeed have a number of apostrophes in it. I removed some of the items since I don't go in the zone that they drop from anymore. But they were too numerous and figured Ninja simply had to deal with them. I did not manually enter those, those are from /lootdestroy, /lootkeep (which are the only 2 I use). The only time I manually edit the INI is when I am doing a search and stumble upon something marked keep that I don't want, and change it to destroy (otherwise I would have to have one of the item on my cursor for the /lootdestroy function to work).
And yes, altho I keep sayin delete, I mean destroy, in all cases, have done many searches for errant words, delete being one of them.
On both ML's, /echo ${NinjaIniFile} returns Loot.ini, no folder, capitol L. However, I see that is set inside the include that way.
Yes, I have witnessed new entries being created in the new INI as I play. I have also witnessed /lootdestroy marking an item that had been initially created with keep to destroy. Well, that's on the ML that is working, not on the other grp. Other grp is still a mystery to me... and yes, same PC, same eqgame.exe, and same MQ2.
These are all good points you bring up: File is not read-only nor hidden. I can find only one of them (did a windows search from the parent MQ2 dir). There is a lootBAK.ini but /echo ${NinjaIniFile} does not return it.
This is the version string from inside the include: /declare NinjadVersion string outer 6.1
SpamLootInfo=1, is that the spam setting you were talking about, it has been on for some time now.
Oh, been meaning to ask, I have 1 toon that carries 2 extraplanar trade satchels. Most others carry 1, and some none. I have it set to only exclude one satchel but it always made me wonder how it dealt with the differences in inventories between toons.
It seems to be working really well right now on the one ML. I am really scratching my head on the other grp. I am still experiencing where the ML fills up, then everything goes to roll rather than choosing a new ML. But that's ok if it's destroying stuff since the bags wont get full.
Wait a minute, it isn't divided by grp, its divided by toon. I have toons in grp 1 that when I have them ML they do not destroy stuff. Only my main enjoys stuff being destroyed (I don't let the wizzy nor the clr loot, but anyone else is fair game). I wonder if there is a plugin or plugin setting conflict, something that is different between accts/toons. lemme take a new approach on this and look for differences between toons rather than the two grps. You mentioned wondering what impact there might be with turning off certain AdvLoot settings. Lemme compare the various settings between the various toons and get back.
- - - Updated - - -
Ima thinking a couple things; the inventories need to match, toon to toon, and 2) the bag exclusion might be funky.
I am not excluding any bag in the new INI.
The exclude bag should work even if you have more then one with the same name. Each top level slot is checked for each exclude bag name and the available slots are tallied up.
Check your advloot filters... There is still some strange things happening when items are filtered in game with advloot and through the macro.
New file being uploaded to correct an issue with switching the master looter when bags are full
Check your advloot filters... There is still some strange things happening when items are filtered in game with advloot and through the macro.
New file being uploaded to correct an issue with switching the master looter when bags are full
Hey Bud,
I haven't been letting the ML fill up lately, largely due to destroy working. As such, I hadn't really seen what auto-changing ML might do with the latest code.
I forgot last night to clear out some bags on one of my gps and the change ML fired. The next in line isn't really set up to loot as it didn't have large bags and quickly filled up. The next 2 in line are NOT set to loot. I haven't gone back to the code, but was wondering if the next in line has loot off, how many more times will it go up the chain?
In my case, after the 2 next in line with loot off there was another one that would have been an acceptable candidate to loot (meaning it had loot on and decent bags). It did not get that far. Everything went to roll.
I always wondered what would happen once a full cycle through the whole group was performed. I could see myself clearing out candidate 1's bags after ML assignment has been made to candidate 2 hoping it would just cycle back through to it once all others (that have loot on) have filled up. I have never let it go that long to see.
Whadaya think?
I haven't been letting the ML fill up lately, largely due to destroy working. As such, I hadn't really seen what auto-changing ML might do with the latest code.
I forgot last night to clear out some bags on one of my gps and the change ML fired. The next in line isn't really set up to loot as it didn't have large bags and quickly filled up. The next 2 in line are NOT set to loot. I haven't gone back to the code, but was wondering if the next in line has loot off, how many more times will it go up the chain?
In my case, after the 2 next in line with loot off there was another one that would have been an acceptable candidate to loot (meaning it had loot on and decent bags). It did not get that far. Everything went to roll.
I always wondered what would happen once a full cycle through the whole group was performed. I could see myself clearing out candidate 1's bags after ML assignment has been made to candidate 2 hoping it would just cycle back through to it once all others (that have loot on) have filled up. I have never let it go that long to see.
Whadaya think?
It is suppose to cycle through the entire group. Starting with the current master looter working it's way down the group count to the group leader. I only recently added code for it to start over at the top of the group count again. I have not been able to play long enough to really check this out properly. Currently I think it would simple keep trying, cycling through the group count, letting the loot pile up in the shared list window until it rots. It should never start rolling on everything. That has to be something happening from the in-game advloot filters.
I am finding the in-game loot filters override (take priority) over the ini file settings once the item is in the personal list, or perhaps the ingame system is simple so fast it doesn't get a chance to check the ini file settings.
I would check the group member that was master looter and make sure the advanced loot system 'use filters' option is turned off. I have not been able to reproduce the condition everything going to roll. If you figure out what's causing it let me know.
I did discover an error in the adding a nodrop item process. I think I'm going to update 6.1 one more time.
EDIT: I found another error in the master looter switch, mixed up the loop variable with the Master Looter variable.
New file uploaded.
I am finding the in-game loot filters override (take priority) over the ini file settings once the item is in the personal list, or perhaps the ingame system is simple so fast it doesn't get a chance to check the ini file settings.
I would check the group member that was master looter and make sure the advanced loot system 'use filters' option is turned off. I have not been able to reproduce the condition everything going to roll. If you figure out what's causing it let me know.
I did discover an error in the adding a nodrop item process. I think I'm going to update 6.1 one more time.
EDIT: I found another error in the master looter switch, mixed up the loop variable with the Master Looter variable.
New file uploaded.
It should work with KISS9. I have not yet tested it but I believe others have used it with KISS9. Let me know if you have any problems and I'll try to figure out KISS9 and how to adjust for them.
Need help...
Anyone know how to make Ninjadvloot 6.1 automatic add looted item to loot.ini?
By default it only record no drop quest item in FV server.
And loot tons of valueless staff, which I have to manual type in everything in ini file, which basically make this plugin useless.
Anyone know how to make Ninjadvloot 6.1 automatic add looted item to loot.ini?
By default it only record no drop quest item in FV server.
And loot tons of valueless staff, which I have to manual type in everything in ini file, which basically make this plugin useless.
Rich (BB code):
[Settings]
|======================================================================|
Version=6.1
AddNewSales=1
LootForage=1
LootMobs=TRUE
CorpseRadius=100
MobsTooClose=40
ReportLoot=FALSE
LootChannel=g
LootForageSpam=1
GlobalLootOn=1
CombatLooting=0
SpamLootInfo=1
QuestKeep=10
StackPlatValue=0
GMLSelect=1
ExcludeBag1=NULL
ExcludeBag2=NULL
LootLagDelay=0
NoDropDefault=Quest|Keep|Ignore