What's new
By:
  • Visit Rebornbuddy
  • Visit Panda Profiles
  • Visit LLamamMagic
  • Visit Resources
  • Visit Downloads
  • Visit Portal

[Profile] Brutal Key Farm

When A4 Keywarden used stealth skills, the bot would have thought the warden had been killed and began portal.
So....The A4 success rate is very low.

Another problem, Sometimes, the bot met A2 Keywarden, but did not begin to combat, the bot continue to explore the map. . .

Profile 1.0.9
Trinity and QT has update to newest from git.
 
Last edited:
I updated my DB and brutal profile, I wish I took note as to how many keys I had prior to running lastnight, ran for 8 hours, woke up was still running which was a plus
[Keys] Counts:
Act 1 => 87
Act 2 => 121
Act 3 => 121
Act 4 => 130


The good news, my A1 keys were always lower due to the fact brutal stopped farming them. But it seems it was picking them up now.
 
infinity said:
Mind linking versions of DB / trinity / QT and GSR M3th0d ?
Click to expand...

I am at work I can post exact v later, but I am running ezupdater so newest trinity/QT, DB updated lastnight and I installed 1.09 BKF
 
something is off here. I ran the bot for 8 hours and only got 2, 1, 4, 5 keys respectively. Is anyone having the same issue?
 
Ive never had to actually post of these forums.... but Im wondering about the mechanics of "zerg" mode and whether or not it would be possible to edit something and have my DH run around in "zerg" while also spanning sentries when they are up? Then when a warden is found moving into combat as usual.

Great profile though ;)
 
Act 1 => 12
Act 2 => 12
Act 3 => 11
Act 4 => 11

working so good for now :)
 
I'm running the Zerg profile; it finds the Key Warden, but just stands there and does nothing and after a couple of seconds my character attempts to portal back to town.
Is there anyway to fix this?
 
Seems to have good results, but does anyone else have a problem with constantly getting stuck in the Oasis? It seems like I get stuck there before finding the warden more often then I don't.
 
It was working good at the begining but now same results with others :(
Version 1.0.9 normal runs

Keys] Counts:
Act 1 => 62
Act 2 => 63
Act 3 => 62
Act 4 => 47
 
This profile is amazing, i use it on my HC seasonal barb in T3. The only issue i have observed is sometime a loop stuck in Dalgur Oasis (act 2 keywarden) that can happen.

"[QuestTools][SafeMoveToTag] Initialized questId="312429" stepId="2" x="4137" y="4634" z="98" pathPrecision=5 MoveResult=Moved statusText=SafeMoveToTag: IsDone: False, PathPrecision: 5, StraightLinePathing: False, UseNavigator: False, X: 4137, Y: 4634, Z: 98, Position: <4137, 4634, 98>, PathPointLimit: 250, Timeout: 180, AllowLongDistance: False, QuestId: 1, StepId: 2, QuestName: Quest Id: 1, IgnoreReset: False, IsDoneCache: False, Behavior: null,
[Trinity] Blacklisting target GoldMedium ActorSNO=4312 RActorGUID=-1490681819 due to possible stuck/flipflop!
[Trinity] Blacklisting target GoldLarge ActorSNO=4311 RActorGUID=-1477115756 due to possible stuck/flipflop! "

This is the error message that i get when those stuck situations appear, they are very rare, like 1 each 2 hours or even less.

Any suggestions to avoid this?

Thank you.


Gio.
 
[Keys] Counts:
Act 1 => 41
Act 2 => 40
Act 3 => 40
Act 4 => 25

How can i fix this? profile 1.0.8

Thanks

EDIT: idk, but i think this is a questtools issue, cuz i tried another questtools, and bot dont pick some keys..
 
Last edited:
d3 gave error ..
following log

18:07:37.618 DEBUG TrinityDebug [Trinity] Used Power Walk at x="3970" y="4133" z="-2" dist=100
18:07:37.768 DEBUG TrinityDebug [Trinity] Used Power Walk at x="3970" y="4133" z="-2" dist=95
18:07:37.898 DEBUG TrinityDebug [Trinity] Used Power Walk at x="3970" y="4133" z="-2" dist=93
18:07:38.018 DEBUG TrinityDebug [Trinity] Used Power Walk at x="3970" y="4133" z="-2" dist=89
18:07:38.138 DEBUG TrinityDebug [Trinity] Used Power Walk at x="3970" y="4133" z="-2" dist=87
18:07:38.288 DEBUG TrinityDebug [Trinity] Used Power Walk at x="3970" y="4133" z="-2" dist=83
18:07:38.408 DEBUG TrinityDebug [Trinity] Used Power Walk at x="3970" y="4133" z="-2" dist=80
18:07:38.598 DEBUG TrinityDebug [Trinity] Used Power Walk at x="3970" y="4133" z="-2" dist=77
18:07:38.728 DEBUG TrinityDebug [Trinity] Used Power DemonHunter_ClusterArrow on -2050686958
18:07:38.928 DEBUG TrinityDebug [Trinity] Used Power DemonHunter_Sentry at x="3895" y="4199" z="100" dist=28
18:07:39.658 DEBUG TrinityDebug [Trinity] Target changed to 4267 // HealthGlobe (HealthGlobe) MaxWeight

View attachment 5988 2014-11-05 16.37.txt

Help me pls
 
Last edited:
xzjv said:
that is a shit load of keys lol

I think the low counts on A4 are an artifact of the way i'm checking against median. For example:

[Keys] Counts:
Act 1 => 43
Act 2 => 42
Act 3 => 42
Act 4 => 31
[Keys] Stats:
LF => 20.3
LQ => 33.8
M => 42
UQ => 42.8
UF => 56.3
IQR => 9

this would ignore A1 and do all 3 acts since they're not above median (42). So the lowest count doesn't get a chance to catch up.
Click to expand...

Ok, but how can i fix this? BrutalKey 1.08 here. How can edit your profile to compensate? Could you help? Ex: If I want to do only Act4 to compensate. It's simple?

[Keys] Counts:
Act 1 => 41
Act 2 => 40
Act 3 => 40
Act 4 => 25
 
Familiar problem here, Act 3 getting ignored for a total of 10 keys difference to other acts.

Currently testing HighestKeyCountId(keyActorID) from QuestTools\Helpers\CustomConditions.cs instead of KeyAboveMedian(keyActorID) as condition on BKF_data.xml lines 86,90,94 and 98. Not perfect workaround, but it's no longer skipping that act I was missing and hey it's 01:00am here ... :p

Still interested in learning what's "wrong" with that statistical approach on act skipping conditions or whatever is the problem.

[Edit]
Seems to work ok for me for the time being. Started out with
Code: 
[Keys] Counts: 
           Act 1 => 19 
           Act 2 => 15
           Act 3 => 7
           Act 4 => 26
[Keys] Stats:
           LF => -13,9
           LQ => 9
           M => 17
           UQ => 24,3
           UF => 47,1
           IQR => 15,3

and now it's at

Code: 
[Keys] Counts: 
           Act 1 => 30 
           Act 2 => 23
           Act 3 => 23
           Act 4 => 31
[Keys] Stats:
           LF => 11,4
           LQ => 23
           M => 26,5
           UQ => 30,8
           UF => 42,4
           IQR => 7,8
 
Last edited:
FrankNStein said:
Familiar problem here, Act 3 getting ignored for a total of 10 keys difference to other acts.

Currently testing HighestKeyCountId(keyActorID) from QuestTools\Helpers\CustomConditions.cs instead of KeyAboveMedian(keyActorID) as condition on BKF_data.xml lines 86,90,94 and 98. Not perfect workaround, but it's no longer skipping that act I was missing and hey it's 01:00am here ... :p

Still interested in learning what's "wrong" with that statistical approach on act skipping conditions or whatever is the problem.

[Edit]
Seems to work ok for me for the time being. Started out with
Code: 
[Keys] Counts: 
           Act 1 => 19 
           Act 2 => 15
           Act 3 => 7
           Act 4 => 26
[Keys] Stats:
           LF => -13,9
           LQ => 9
           M => 17
           UQ => 24,3
           UF => 47,1
           IQR => 15,3

and now it's at

Code: 
[Keys] Counts: 
           Act 1 => 30 
           Act 2 => 23
           Act 3 => 23
           Act 4 => 31
[Keys] Stats:
           LF => 11,4
           LQ => 23
           M => 26,5
           UQ => 30,8
           UF => 42,4
           IQR => 7,8
Click to expand...


Thanks and keep us informed. If possible, equalize the numbers, put some in the stash and continue testing.
 
You must log in or register to reply here.
Back
Top