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!
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"
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.
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))
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
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
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.
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
http://www.thebuddyforum.com/demonbuddy-forum/75980-beta-demonbuddy-daily-beta-builds.html Looks like DB it's fixed in the latest beta version.
