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

Double Checking on Shrines/Pylons?

jubisman said:
It's hard to fix because neither me nor xzjv can reproduce this. It works fine for both of us, the bot uses the shrine/pylon/whatever and moves on. Besides, the code already has plenty of checks to determine whether or not an interactable object has already been interacted with. So yeah, this one will take some time, especially considering we're still dealing with the bad item data business.
Click to expand...
Hey Jubisman, I can make a video of it.
Very easy to do...just start record and do a Grift or Rift and sure enough the two applications fighting to take shrine are fighting it out. I love it when the bot is standing there at a dead shrine, taking serious damage, and it appears he is wondering why Blizz servers won't give him the buff! A dead shrine is a dead shrine.
If it makes a difference I'll send you the link to the video with DB console up.
 
There is only one reason why this happen:

Code: 
if (cacheObject.IsUsed)
                                {
                                    cacheObject.WeightInfo += string.Format("Ignoring {0} - Used.", cacheObject.InternalName);
                                    break;
                                }

In this part of code IsUsed is in false state after interraction. The reason why it can be is GetIsGizmoUsed have some wrong code (Trinity issue) or DB returns wrong data (DB issue). I'm trying to figure out this now by myself.
 
Keetsune said:
There is only one reason why this happen:

Code: 
if (cacheObject.IsUsed)
                                {
                                    cacheObject.WeightInfo += string.Format("Ignoring {0} - Used.", cacheObject.InternalName);
                                    break;
                                }

In this part of code IsUsed is in false state after interraction. The reason why it can be is GetIsGizmoUsed have some wrong code (Trinity issue) or DB returns wrong data (DB issue). I'm trying to figure out this now by myself.
Click to expand...

try to use Blacklist90Seconds instead of Blacklist15Seconds, problems almost solved:
Code: 
                            // If we've tried interacting too many times, blacklist this for a while
                            if (CacheData.InteractAttempts[CurrentTarget.RActorGuid] > [COLOR="#FF0000"]5[/COLOR] && CurrentTarget.Type != TrinityObjectType.HealthWell)
                            {
                                Logger.LogVerbose("Blacklisting {0} ({1}) for 15 seconds after {2} interactions",
                                    CurrentTarget.InternalName, CurrentTarget.ActorSNO, attemptCount);

                                CacheData.InteractAttempts[CurrentTarget.RActorGuid] = 0;
[COLOR="#FF0000"]                                Blacklist90Seconds.Add(CurrentTarget.RActorGuid);
                                Blacklist90LastClear = DateTime.UtcNow;[/COLOR]

In some map, if you are unlucky in a detour, Blacklist90Seconds refreshed, then you'll get "double check" problems again. But it's rarely happen.
 
we could add "_forceTargetUpdate = true;" to tell Trinity to get a new target.
 
Last edited:
I add some code in Trinity:
1.add "Blacklist600Seconds" variable, when bot InteractAttempts > 5, Blacklist600Seconds will add "CurrentTarget.ObjectHash", then force currentTarget update;
2.Blacklist600Seconds only updates in "TownRun";
3.before bot interact with pylon/shrine/door/container etc. We will check whether Blacklist600Seconds contains "CurrentTarget.ObjectHash", this is most important one;

Now it's works perfect for me.

somtime if the InteractAttempts < 5, bot will still visit same pylon/shrine twice, it's not bug.

View attachment Trinity 2.14.44_chonger.zip
 
Last edited:
~Still hoping for an update to fix this. It got worse with the last update on monk. Double checks most...hangs about sometimes for 2-3 seconds and often revisits.
 
really annoyed by this problem, especially when under atks by elites while checking the pylon for 2sec -> dead. hopefully it will get fixed soon.
 
vtiancai said:
really annoyed by this problem, especially when under atks by elites while checking the pylon for 2sec -> dead. hopefully it will get fixed soon.
Click to expand...

This problem already fixed, here's my solution, plz replace the file in the directories specified below :
\Trinity\Combat\HandleTarget.cs
\Trinity\Cache\RefreshObject.cs
\Trinity\Helpers\GameEvents.cs
\Trinity\DbProvider\TownRun.cs
\Trinity\Configuration\Variables.cs

works fine with trinity 2.14.44.

View attachment Trinity 2.14.44.zip
 
chongeryan said:
This problem already fixed, here's my solution, plz replace the file in the directories specified below :
\Trinity\Combat\HandleTarget.cs
\Trinity\Cache\RefreshObject.cs
\Trinity\Helpers\GameEvents.cs
\Trinity\DbProvider\TownRun.cs
\Trinity\Configuration\Variables.cs

works fine with trinity 2.14.44.

View attachment 199483
Click to expand...

Work with trinity 2.14.496 ?
 
So, do I need to revert to .44 or is someone working on a fix for newest?
 
I feel like this issue is being ignored or has been forgotten?
 
lager said:
I feel like this issue is being ignored or has been forgotten?
Click to expand...

I read pretty much all forum posts, and definitely threads that have been here for a while. Once i can get a stable version it will include a blacklist work-around for this. I have reduced the interaction count and made the blacklisting persist properly. I was hoping that DB would be fixed so that actor attributes are correct, so that we could reliably check if the shrine is in a 'used' state. But who knows how long that will take :(
 
I'm using currenlty my own temporary soluiton without blacklisting:

I just check if my character have buff from that shrine/pylon and ignoring it.

In example powerd shrine:

Code: 
if (cacheObject.InternalName == "x1_LR_Shrine_Damage" && CacheData.Buffs.HasBuff(SNOPower.Pages_Buff_Damage))
{
                                    cacheObject.Weight = 0;
                                    break;
}
 
You must log in or register to reply here.
Back
Top