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

Fix for sprint bug spamming on town teleport

mylo

mylo

Member
Joined
Jun 14, 2012
Messages
128
Reaction score
9
Fix for sprint bug [NOT WORKING, DB BUG]

Have tested this to be working, tried 4 times with and without and seems to do the job:

Line 4679 Find:
Code: 
            if (!playerStatus.bIsInTown && !bGilesForcedVendoring && myAnimationState != AnimationState.Attacking && myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling)

Replace:
Code: 
            if (!bWantToTownRun && !playerStatus.bIsInTown && !bGilesForcedVendoring && myAnimationState != AnimationState.Attacking && myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling)

Voila, teleports first time :)

EDIT: This only works for the Trinity teleports, not the RadsAtom profile changes. The bug is actually down to the Demonbuddy AnimationState checks not working since a recent update, Giles code is perfect! :cool:
 

Attachments

Last edited:
didn't work for me (downloaded your attachment)
tested for when loading next profile
 
U guys need to find everywhere it calls SNOPower.Barbarian_Sprint and add an if when it trys to use it " myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling"
 
Last edited:
Yeah, I've found the issue now but not sure how to fix it.

It's because the profile transitions are handled by RadsAtom not GilesTrinity, so when RadsAtom is trying to change to next profile there is nothing to stop the OOC buffing routine of GilesTrinity, because RadsAtom is not telling Trinity to stop this. Afraid I don't have any experience of how plugins communicate, if it's possible for them to tell each other about this or what unfortunately so not sure I will be able to fix it, may need the plugin developers to take a look. I'll have a ***** as if they can call each others variables it should be possible, but very much guesswork at this point.
 
arielmz said:
U guys need to find everywhere it calls SNOPower.Barbarian_Sprint and add an if when it trys to use it " myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling"
Click to expand...

Found a place where this might work, just testing now, annoyingly it takes a long time to test as you can't force a radsatom profile transition with a full fury bar (e.g. not death)

For anyone else who wants to test the like I have changed is 6402:
old
Code: 
                        playerStatus.dCurrentEnergy >= 20 && GilesUseTimer(SNOPower.Barbarian_Sprint) && PowerManager.CanCast(SNOPower.Barbarian_Sprint))

new
Code: 
                        playerStatus.dCurrentEnergy >= 20 && GilesUseTimer(SNOPower.Barbarian_Sprint) && PowerManager.CanCast(SNOPower.Barbarian_Sprint) && myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling))
 
Last edited:
Unfortunately that code doesn't seem to work, back to the drawing board...

Code: 
(6399,25) : error CS0103: The name 'myAnimationState' does not exist in the current context
 
Last edited:
I suspect this is a bug with new DemonBuddy. My animationstat checks used to work fine, but the new versions of demonBuddy, they seem to do nothing. These checks here;

If (!playerStatus.bIsInTown && !bGilesForcedVendoring && myAnimationState != AnimationState.Attacking && myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling)

Used to stop it trying to buff if the cast-bar was up - eg if DemonBuddy was teleporting due to reaching a profile command to return to town etc. - but for some reason, they don't work anymore.

I can only guess that there's some issue with DemonBuddy's animation state checking on ZetaDia.Me as of the newer DB updates.
 
May have found a way around it, testing the following code now:

Code: 
                    // Special segment for sprint as an out-of-combat only
					AnimationState myAnimationState = ZetaDia.Me.CommonData.AnimationState;
                    if (myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling && bOOCBuff && (settings.bOutOfCombatMovementPowers || GilesHasBuff(SNOPower.Barbarian_WrathOfTheBerserker)) && 
                        !playerStatus.bIsIncapacitated && hashPowerHotbarAbilities.Contains(SNOPower.Barbarian_Sprint) && 
                        !GilesHasBuff(SNOPower.Barbarian_Sprint) &&
                        playerStatus.dCurrentEnergy >= 20 && GilesUseTimer(SNOPower.Barbarian_Sprint) && PowerManager.CanCast(SNOPower.Barbarian_Sprint))
                    {
                        return new GilesPower(SNOPower.Barbarian_Sprint, 0f, vNullLocation, iCurrentWorldID, -1, 0, 0, USE_SLOWLY);
                    }
                    // War cry, constantly maintain
 
GilesSmith said:
I suspect this is a bug with new DemonBuddy. My animationstat checks used to work fine, but the new versions of demonBuddy, they seem to do nothing. These checks here;

If (!playerStatus.bIsInTown && !bGilesForcedVendoring && myAnimationState != AnimationState.Attacking && myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling)

Used to stop it trying to buff if the cast-bar was up - eg if DemonBuddy was teleporting due to reaching a profile command to return to town etc. - but for some reason, they don't work anymore.

I can only guess that there's some issue with DemonBuddy's animation state checking on ZetaDia.Me as of the newer DB updates.
Click to expand...


Ah right, yeah I have just noticed that the place I lifted this code from was actually using those anyway and should have fixed the first issue without me having to put that code in. I guess as you say it must be a DB issue, so I imagine what I just posted won't help stop it happening when RadsAtom changes profile at all.

The first bit post adding the !bWantToTownRun does fix it for the Trinity town portals at least, but not sure how to fix for RadsAtom profile changes atm.
 
mylo said:
May have found a way around it, testing the following code now:
Code: 
                    // Special segment for sprint as an out-of-combat only
					AnimationState myAnimationState = ZetaDia.Me.CommonData.AnimationState;
                    if (myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling && bOOCBuff && (settings.bOutOfCombatMovementPowers || GilesHasBuff(SNOPower.Barbarian_WrathOfTheBerserker)) && 
                        !playerStatus.bIsIncapacitated && hashPowerHotbarAbilities.Contains(SNOPower.Barbarian_Sprint) && 
                        !GilesHasBuff(SNOPower.Barbarian_Sprint) &&
                        playerStatus.dCurrentEnergy >= 20 && GilesUseTimer(SNOPower.Barbarian_Sprint) && PowerManager.CanCast(SNOPower.Barbarian_Sprint))
                    {
                        return new GilesPower(SNOPower.Barbarian_Sprint, 0f, vNullLocation, iCurrentWorldID, -1, 0, 0, USE_SLOWLY);
                    }
                    // War cry, constantly maintain
Click to expand...

That shouldn't be any different to the current method - I do think it's some unreliability with animation state checking in newer DB builds.

But there is something - you should AVOID animation state checking within the GilesAbilitySelect function, because it does negatively impact speed (and open up more chances of null errors crashing the plugin and causing 1-2 seconds of "freeze") - which is why I didn't have the check there in the first place. You can work around this though by ensuring that the animation state is ONLY checked if "bOOCBuff" is true - so the code is never checked in-combat (since that sprint is never cast in combat anyway), eg;
Code: 
                    // Special segment for sprint as an out-of-combat only
                    if (bOOCBuff)
                    {
		    AnimationState myAnimationState = ZetaDia.Me.CommonData.AnimationState;
                    if (myAnimationState != AnimationState.Casting && myAnimationState != AnimationState.Channeling && (settings.bOutOfCombatMovementPowers || GilesHasBuff(SNOPower.Barbarian_WrathOfTheBerserker)) && 
                        !playerStatus.bIsIncapacitated && hashPowerHotbarAbilities.Contains(SNOPower.Barbarian_Sprint) && 
                        !GilesHasBuff(SNOPower.Barbarian_Sprint) &&
                        playerStatus.dCurrentEnergy >= 20 && GilesUseTimer(SNOPower.Barbarian_Sprint) && PowerManager.CanCast(SNOPower.Barbarian_Sprint))
                    {
                        return new GilesPower(SNOPower.Barbarian_Sprint, 0f, vNullLocation, iCurrentWorldID, -1, 0, 0, USE_SLOWLY);
                    }
                    } // Only do this if out of combat
                    // War cry, constantly maintain

Would be a safer way to achieve the same thing. But - really - I don't know why/how checking the animationstate at "abilityselect" function would be any different to the current position in the code deciding whether to look for a valid out-of-combat buff or not (the code that CALLS abilityselect out of combat)!

I'll see if Nesox is aware of any broken animationstate checking in these new DB builds or not, if he's no idea, then I'll have to bump him on my developer request here;
http://www.thebuddyforum.com/demonbuddy-forum/developers/66302-request-gettable-settable-zetadia-me-istryingtotownportal-value.html
 
Yep I agree entirely, seems to be a DB issue, I haven't checked but my profile should hit a change point soon, I assume adding the check won't have fixed it though seeing as it didn't appear to be working in the the first instance of it (since some DB patch, not entirely sure which)
 
It's just hit the RadsAtom profile change and as expected doesn't work with the added AnimationState checks, not sure if you have a direct line to DB or similar for bug reports, but these checks must be broken in the current version.
 
Just to confirm after speaking to nesox, it is because of new DB builds and new Diablo 3 patch changing where in memory the animation stuff was :)

AnimationState code is getting a major change next DB build, which will fix it but will break current Trinity code (so everybody will need to update to a new Trinity that has support for the new code).

I'll keep up to date on this one so the moment the DB build is released with the animation fix, I can get a Trinity update that works with the new build soon after, and will fix the casting-while-teleporting again :D
 
Ah great, thanks for the update, I'll stop worrying about this for now and make some lunch then! :)
 
You must log in or register to reply here.
Back
Top