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

Unified GilesPlugin's Unnoficial Updates File

Status
Not open for further replies.
OK, further tweaked Sweeping Wind code. We fixed the spamming issue for users without Inna, but Inna users would have to wait until they reached 75+ spirit to initially cast it.

This ensures sweeping wind is always running for Inna users and not wait for the initial 75 spirit:

Code:
// Sweeping wind
                    if ((!bOOCBuff && hashPowerHotbarAbilities.Contains(SNOPower.Monk_SweepingWind) && !GilesHasBuff(SNOPower.Monk_SweepingWind) &&
                        (iElitesWithinRange[RANGE_25] > 0 || iAnythingWithinRange[RANGE_20] >= 2 || ((targetCurrent.bThisEliteRareUnique || targetCurrent.bThisBoss) && targetCurrent.fRadiusDistance <= 25f)) &&
                        // Check if either we don't have blinding flash, or we do and it's been cast in the last 6000ms
                        (!hashPowerHotbarAbilities.Contains(SNOPower.Monk_BlindingFlash) || (hashPowerHotbarAbilities.Contains(SNOPower.Monk_BlindingFlash) && DateTime.Now.Subtract(dictAbilityLastUse[SNOPower.Monk_BlindingFlash]).TotalMilliseconds <= 6000)) &&
                        // Check our mantras, if we have them, are up first
                        (!hashPowerHotbarAbilities.Contains(SNOPower.Monk_MantraOfEvasion) || (hashPowerHotbarAbilities.Contains(SNOPower.Monk_MantraOfEvasion) && GilesHasBuff(SNOPower.Monk_MantraOfEvasion))) &&
                        (!hashPowerHotbarAbilities.Contains(SNOPower.Monk_MantraOfConviction) || (hashPowerHotbarAbilities.Contains(SNOPower.Monk_MantraOfConviction) && GilesHasBuff(SNOPower.Monk_MantraOfConviction))) &&
                        (!hashPowerHotbarAbilities.Contains(SNOPower.Monk_MantraOfRetribution) || (hashPowerHotbarAbilities.Contains(SNOPower.Monk_MantraOfRetribution) && GilesHasBuff(SNOPower.Monk_MantraOfRetribution))) &&
                        // Check the re-use timer and energy costs
                        //(playerStatus.dCurrentEnergy >= 75 || (settings.bMonkInnaSet && playerStatus.dCurrentEnergy >= 5)) && GilesUseTimer(SNOPower.Monk_SweepingWind)) || (GilesHasBuff(SNOPower.Monk_SweepingWind) && GilesUseTimer(SNOPower.Monk_SweepingWind) && playerStatus.dCurrentEnergy >= 75))
						//(playerStatus.dCurrentEnergy >= sweepingWindEnergyCost) && GilesUseTimer(SNOPower.Monk_SweepingWind)) || (GilesHasBuff(SNOPower.Monk_SweepingWind) && GilesUseTimer(SNOPower.Monk_SweepingWind) && playerStatus.dCurrentEnergy >= sweepingWindEnergyCost))
						
						// Keep Sweeping Wind up for Inna users
						(settings.bMonkInnaSet && playerStatus.dCurrentEnergy >= 5) || 
						// OR Check the re-use timer and energy costs
                        playerStatus.dCurrentEnergy >= 75 && GilesUseTimer(SNOPower.Monk_SweepingWind)))
                    {
                        return new GilesPower(SNOPower.Monk_SweepingWind, 0f, vNullLocation, iCurrentWorldID, -1, 2, 2, USE_SLOWLY);
                    }
 
We need to take a look at the Use Timers for a lot of skills. By default they're fine, but if the bot ever picks up an Empowered Shrine or a Monk is using something like Beacon of Ytar that reduces cooldowns, many important skills will not get used when they are available simply because the wait timers are too long.

Does Trinity check for cooldowns? I see this line: PowerManager.CanCast(SNOPower.Monk_Serenity)
which leads me to believe that it will only cast if the cooldown is up, so why do we have wait timers at all? If the bot needs to cast Serenity it should absolutely cast Serenity as soon as possible. That's just an example, I'm sure there are plenty of other skills that would benefit from moving away from Use timers and just monitoring cooldowns.

I think that is because cooldowns have nothing to do with canCast... e.g. buffs that last 2min but have a much shorter cooldown.
 
Magi: I think you changed the code quite a lot more than you wanted.
It didn't wait for 75 spirit to cast it: (playerStatus.dCurrentEnergy >= 75 || (settings.bMonkInnaSet && playerStatus.dCurrentEnergy >= 5))
It waits for your DPS buffs, because Sweeping Wind takes a snapshot od DPS at the time of initial casting and uses that for ever and ever.

And the spamming was actually ORed with the whole 7 line condition, as an alternative. You pulled it in instead.
 
Magi: I think you changed the code quite a lot more than you wanted.
It didn't wait for 75 spirit to cast it: (playerStatus.dCurrentEnergy >= 75 || (settings.bMonkInnaSet && playerStatus.dCurrentEnergy >= 5))
It waits for your DPS buffs, because Sweeping Wind takes a snapshot od DPS at the time of initial casting and uses that for ever and ever.

And the spamming was actually ORed with the whole 7 line condition, as an alternative. You pulled it in instead.

no shit lol. I did not know that haha. Looks like it was always waiting for 75 spirit or so to kick in...
 
Last edited:
Magi: I think you changed the code quite a lot more than you wanted.
It didn't wait for 75 spirit to cast it: (playerStatus.dCurrentEnergy >= 75 || (settings.bMonkInnaSet && playerStatus.dCurrentEnergy >= 5))
It waits for your DPS buffs, because Sweeping Wind takes a snapshot od DPS at the time of initial casting and uses that for ever and ever.

And the spamming was actually ORed with the whole 7 line condition, as an alternative. You pulled it in instead.

You sure about that? I looked at the code I removed and I'm not seeing anything that checks if your other skills are up. The stuff above it does like your Mantra's and blinding flash. What I edited should not effect it as those if statements preceed what I wrote. The stuff I removed was using the GilesUseTimer. And my guy will wait to cast sweeping wind at 75 everytime, even with my mantra's up using the old code.

EDIT - knowing now that Diablo doesn't update sweeping wind damage based on your current dps (who the hell do they have coding over there?!?) I'll need to monitor how the old code handled blinding flash with sweep. Mantra's are always up first so it's really only blinding flash to consider here. Blind flash needs improvement anyway as it only typically fires if there is a ton of enemies or used as defense.

EDIT2 - old code definitely doesn't fire blinding flash before initiating sweeping wind (it should if you are correct about how Diablo determines sweeping wind dmg). It waits until 75 is met.

EDIT3 - altering some additional code for inna's, temp hack:

Code:
//(hashPowerHotbarAbilities.Contains(SNOPower.Monk_SweepingWind) && playerStatus.dCurrentEnergy >= 85 && GilesUseTimer(SNOPower.Monk_SweepingWind)) ||

to:
Code:
//(hashPowerHotbarAbilities.Contains(SNOPower.Monk_SweepingWind) && playerStatus.dCurrentEnergy >= 15 && GilesUseTimer(SNOPower.Monk_SweepingWind)) ||
 
Last edited:
The old code has only the following condition for energy:
(playerStatus.dCurrentEnergy >= 75 || (settings.bMonkInnaSet && playerStatus.dCurrentEnergy >= 5))

Can't see how it could be waiting for 75 with this.
Maybe someone changed something else between version I am looking at and the one you are fixing?

Also, please do carefully check parenthesis.

The code I gave has
if( (shitload of stuff about mantras and initial fire up) || (if up, spam) );

you have
if( (shitload of stuff about mantras and initial fire up && (inna's && energy >= 5) ) || (energy >= 75 && timer) )

That will:
a) not spam when it is up
b) fire up when at 75 energy whenever, ignoring the whole mantra code

I am pretty sure it does not work as intended, even though it might work for your bot
 
The old code has only the following condition for energy:
(playerStatus.dCurrentEnergy >= 75 || (settings.bMonkInnaSet && playerStatus.dCurrentEnergy >= 5))

Can't see how it could be waiting for 75 with this.
Maybe someone changed something else between version I am looking at and the one you are fixing?

Also, please do carefully check parenthesis.

The code I gave has
if( (shitload of stuff about mantras and initial fire up) || (if up, spam) );

you have
if( (shitload of stuff about mantras and initial fire up && (inna's && energy >= 5) ) || (energy >= 75 && timer) )

That will:
a) not spam when it is up
b) fire up when at 75 energy whenever, ignoring the whole mantra code

I am pretty sure it does not work as intended, even though it might work for your bot


I am testing it right now on A3 MP4 20min 0 death and working good so far =)

edit: still great 0 deaths, working gooood
 
Last edited:
The old code has only the following condition for energy:
(playerStatus.dCurrentEnergy >= 75 || (settings.bMonkInnaSet && playerStatus.dCurrentEnergy >= 5))

Can't see how it could be waiting for 75 with this.
Maybe someone changed something else between version I am looking at and the one you are fixing?

Also, please do carefully check parenthesis.

The code I gave has
if( (shitload of stuff about mantras and initial fire up) || (if up, spam) );

you have
if( (shitload of stuff about mantras and initial fire up && (inna's && energy >= 5) ) || (energy >= 75 && timer) )

That will:
a) not spam when it is up
b) fire up when at 75 energy whenever, ignoring the whole mantra code

I am pretty sure it does not work as intended, even though it might work for your bot

Could definitely be missing a parenthesis...there are a ton. I'll keep an eye on it.

One thing I think we should change is blinding flash:

Code:
// Blinding Flash
                    if (!bOOCBuff && playerStatus.dCurrentEnergy >= 20 && hashPowerHotbarAbilities.Contains(SNOPower.Monk_BlindingFlash) &&
                            (iElitesWithinRange[RANGE_15] > 0 || playerStatus.dCurrentHealthPct <= 0.4 || iAnythingWithinRange[RANGE_15] >= 5 || (iAnythingWithinRange[RANGE_15] >= 1 && playerStatus.dCurrentEnergyPct >= 0.7) || ((targetCurrent.bThisEliteRareUnique || targetCurrent.bThisBoss) && targetCurrent.fRadiusDistance <= 15f)) &&
                        // Check if either we don't have sweeping winds, or we do and it's ready to cast in a moment
                            (!hashPowerHotbarAbilities.Contains(SNOPower.Monk_SweepingWind) ||
                             (hashPowerHotbarAbilities.Contains(SNOPower.Monk_SweepingWind) && playerStatus.dCurrentEnergy >= 85 && GilesUseTimer(SNOPower.Monk_SweepingWind)) ||
							 (hashPowerHotbarAbilities.Contains(SNOPower.Monk_SweepingWind) && playerStatus.dCurrentEnergy >= 15 && GilesUseTimer(SNOPower.Monk_SweepingWind) && settings.bMonkInnaSet) ||
                             playerStatus.dCurrentHealthPct <= 0.6) &&
                            GilesUseTimer(SNOPower.Monk_BlindingFlash) && PowerManager.CanCast(SNOPower.Monk_BlindingFlash))
                    {
                        return new GilesPower(SNOPower.Monk_BlindingFlash, 11f, vNullLocation, iCurrentWorldID, -1, 1, 2, USE_SLOWLY);
                    }

I didn't remove anything, just added a parameter for Inna users:

Code:
(hashPowerHotbarAbilities.Contains(SNOPower.Monk_SweepingWind) && playerStatus.dCurrentEnergy >= 15 && GilesUseTimer(SNOPower.Monk_SweepingWind) && settings.bMonkInnaSet) ||

Since 85 isn't necessary for Inna's, they can fire Blinding Flash right before sweeping wind at 15.
 
Last edited:
Hey, Magi, nice work you're doing, man. Could you put everything I should change in a single post after you're done?
 
thanks guys, yes I will make sure to include a proper version of sweeping wind lol. I screwed it up a few times so once I'm pretty confident it's working as it should, I'll let you know :P

These conditionals are a little ridiculous lol

Would love to clean it up but I'm pretty sure I'd be at it until Diablo 4 hits.
 
hmmmmm in UnifiedGilesTrinity_v0.41.zip my bots just watch how mobs killing him, he just run profile and do not attack -,-
 
hmmmmm in UnifiedGilesTrinity_v0.41.zip my bots just watch how mobs killing him, he just run profile and do not attack -,-
Are you sure GilesTrinity is enabled in the plugins tab? If so, I would recommend deleting the plugin and downloading it again. Maybe a fresh install
 
Sorry was my mistake, i didnt delete gilestrinity in settings and compilesassemblies. Now all good work. my gph up on 10-20%
 
I know is not essential, rather a aesthetics matter, but in a future release, could you make the User Interface a little larger? in several places, are parts of label text that is trimmed.

Keep up the good work :)
 
The latest version messes something up with tempest rush for monks. It doesn't activate anymore for me he goes back to walking

Thanks for all the work you guys have put into it
 
The latest version messes something up with tempest rush for monks. It doesn't activate anymore for me he goes back to walking

Thanks for all the work you guys have put into it
Well, that sounds bad. If anyone else confirms this I'll have to revert Tempest Rush back to v0.4 version
 
My logs are filling up with this garbage:
Code:
[17:40:51.920 D] Rule  matched all AND logical operators for item Massacre Axe of Assault
[17:40:51.920 D] Rule  was successfully matched for Massacre Axe of Assault
[17:40:51.920 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:51.920 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.000 D] Rule  matched all AND logical operators for item Massacre Axe of Assault
[17:40:52.000 D] Rule  was successfully matched for Massacre Axe of Assault
[17:40:52.000 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.000 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.050 D] Rule  matched all AND logical operators for item Massacre Axe of Assault
[17:40:52.050 D] Rule  was successfully matched for Massacre Axe of Assault
[17:40:52.050 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.050 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.120 D] Rule  matched all AND logical operators for item Massacre Axe of Assault
[17:40:52.120 D] Rule  was successfully matched for Massacre Axe of Assault
[17:40:52.120 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.120 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.170 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.170 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.250 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.250 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.290 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.290 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.370 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.370 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.430 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.430 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.500 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.500 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.550 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.550 D] Rule  was successfully matched for Steadfast Skain of Extermination
[17:40:52.620 D] Rule  matched all AND logical operators for item Steadfast Skain of Extermination
[17:40:52.620 D] Rule  was successfully matched for Steadfast Skain of Extermination

What the heck is going on?
 
My friend was usint UnityTrinity and said it sometimes do not pickup example legendary or i63 rare. He had only this plug and atom 2. Any1 having this issue? Could u check giles stats legend dropped/picked up?
I tested for 2h and it didnt picked up two i62 items [like 20 dropped / 18 picked up] (but maybe its generally small Trinity bug?).

Could loot radios increase in profiles fix it?
 
Status
Not open for further replies.
Back
Top