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

Trinity - Barbarian Class

GilesSmith

New Member
Joined
Jun 2, 2012
Messages
1,564
Reaction score
34
Barbarians

These class-threads are for posting your questions, requests, or problems that relate specifically to a class, or skills within that class. There will also be recommended build-ideas that have been tested heavily within Trinity posted here in the first post, and there may be advanced tips on custom-tweaks you can make to skills people commonly request changes for with instructions on how to safely edit the code to your liking.

Build Ideas:

[table="width: 860, class: grid"]
[tr]
[td]
Charging-Frenzy-Barb:
h5XY7.jpg

This is quite a dynamic build - for example you can have "Leap - Iron Impact" instead of Furious Charge to turn it into a more typical barbarian build. "Sidearm" rune on frenzy instead of manic works exceptionally well at handling multiple adds. This build, both with charge or leap, works well for almost any gear-level barbarian, for botting.
[/td]
[td]
Tornado Whirlwind-Barb:
Zj37v.jpg

This build really requires a well-geared barb - with high DPS, high crit-chance, and high crit-damage.
[/td]
[/tr]
[tr]
[td]
Throwing Barb:
ngaIG.jpg

This build needs a moderate to high critical-hit-chance % to be effective.
Leap is optional - you may want to try furious charge, or wrath of the berserker etc.
[/td]
[td]
[/td]
[/tr]
[/table]

Customizing Skills:

To customize a skill, you can open the code (the ".cs" file) in any editor you like - even notepad will do! You must find the correct code, and then (carefully) make the changes suggested below, changing numbers or options as you like. If things go wrong and DemonBuddy/Trinity no longer start up, it just means you mis-edited the code - no problem - just try again with a fresh copy and be sure to be very careful!

(custom change suggestions to be added based on common player requests)
 
Last edited:
Throwing Barb:

Actually pretty good build but really need some AI improvements

Also barbarian should move through to the health globe no matter what and spam revenge even if WWing that moment
 
Going to repost this here, since it's more appropriate...

---

Update again!

Code:
// Rend spam
if(!bBuffsOnly && hashPowerHotbarAbilities.Contains(SNOPower.Barbarian_Rend))
{
	//Logging.Write("!Buffs and has ability...");

	if(iAnythingWithinRange[RANGE_7] > 0 || targetCurrent.fRadiusDistance <= 9f)
	{
		//Logging.Write("Range and target count...");

		if(GilesUseTimer(SNOPower.Barbarian_Rend) || 
		(iAnythingWithinRange[RANGE_7] > iWithinRangeLastRend && DateTime.Now.Subtract(dictAbilityLastUse[SNOPower.Barbarian_Rend]).TotalMilliseconds >= 250) ||
		(targetCurrent.iThisACDGUID != iACDGUIDLastRend && DateTime.Now.Subtract(dictAbilityLastUse[SNOPower.Barbarian_Rend]).TotalMilliseconds >= 250))
		{
			Logging.Write("*** Timers ***");

			if(playerStatus.dCurrentEnergy >= 20)
			{
				Logging.Write("****** Using Rend ******");
				iWithinRangeLastRend = iAnythingWithinRange[RANGE_7];
				iACDGUIDLastRend = targetCurrent.iThisACDGUID;
				return new GilesPower(SNOPower.Barbarian_Rend, 0f, playerStatus.vCurrentPosition, iCurrentWorldID, -1, USE_COMBAT_ONLY, USE_SLOWLY);
			}
		}
	}
}

After watching my Logging function calls spam the DB window, I realized the first two checks aren't necessary to report. They work fine (and spam like crazy when something is in range). I had to disable them.

As for the second-to-last ("*** Timers ***") and last nested if statement ("*** Using Rend ***"), if the second-to-last one passes, the last one always passes right behind it. So no problems there.

Here are my logs from Az kill:
[09:56:29.440 N] *** Timers ***
[09:56:31.182 N] ****** Using Rend ******
[09:56:32.292 N] *** Timers ***
[09:56:33.498 N] ****** Using Rend ******
[09:56:34.623 N] *** Timers ***
[09:56:34.623 N] ****** Using Rend ******
[09:56:35.767 N] *** Timers ***
[09:56:35.767 N] ****** Using Rend ******
[09:56:36.907 N] *** Timers ***
[09:56:36.907 N] ****** Using Rend ******

That repeats until the fight ends. However, he only ACTUALLY casted Rend twice, once at the start and very end.

I think I have found the problem. He's not actually USING Rend during those times, he's using Frenzy (or potentially Charge/Leap). At this point, I'm 99% certain the problem lies with the fact that abilities are chosen every 'tick', but when Frenzy is chosen, Rend still passes the check but won't actually be used (because of the Global Cooldown on abilties). Either that or it's the low default timers of Bash/Frenzy/Cleave conflicting with Rend's usage, although it could just be a priority problem.

Phew, this has been driving me crazy, hopefully we can figure out a fix. It can't be as simple as giving Rend higher priority over Frenzy (to an extent) can it, but making sure Rend isn't spamming TOO much, to avoid Frenzy never being used?

I bet that might work.

-Sym

p.s. Maybe when Rend is supposed to be used, a timer/bool is triggered that prevents any just about any other ability from happening for 0.5-1s or something?

p.p.s. The goal here would be to not have Rend spam unnecessarily (which most of your checks are accurate/correct). However, the "full fury" and "a lot of fury" checks are redundant would only cause problems if the priority issue was fixed. So default Rend time on a single target/same count targets should be 4-5s, others can be low, like the "new mobs in range" and "target switch" checks.

p.p.p.s. This all might be covered in the new version, if so ignore.

Please let me know if you want some assistance coding. I have no problem hoping on Skype or something and fiddling around.

---

Cleaner Rend Spam section (removing redundancies, making it easier to read, and prioritizing main if checks):

Code:
// Rend spam
if(!bBuffsOnly && hashPowerHotbarAbilities.Contains(SNOPower.Barbarian_Rend) && playerStatus.dCurrentEnergy >= 20)
{
	if(!bWaitingForSpecial || playerStatus.dCurrentEnergy >= 75)
	{
		if(iAnythingWithinRange[RANGE_7] > 0 || targetCurrent.fRadiusDistance <= 9f)
		{
			if(GilesUseTimer(SNOPower.Barbarian_Rend) || 
			  (iAnythingWithinRange[RANGE_7] > iWithinRangeLastRend && DateTime.Now.Subtract(dictAbilityLastUse[SNOPower.Barbarian_Rend]).TotalMilliseconds >= 250) ||
			  (targetCurrent.iThisACDGUID != iACDGUIDLastRend && DateTime.Now.Subtract(dictAbilityLastUse[SNOPower.Barbarian_Rend]).TotalMilliseconds >= 250))
			{
				//Logging.Write("****** Attempting to Rend ******");
				iWithinRangeLastRend = iAnythingWithinRange[RANGE_7];
				iACDGUIDLastRend = targetCurrent.iThisACDGUID;
				return new GilesPower(SNOPower.Barbarian_Rend, 0f, playerStatus.vCurrentPosition, iCurrentWorldID, -1, USE_COMBAT_ONLY, USE_SLOWLY);
			}
		}
	}
}
 
Last edited:
Something to be reposted as well (the only other Barb issue I saw), is that people were claiming that Sprint was being double or even tripled used at times in very, very short succession causing their fury to drop quickly. I haven't seen this, but I rarely use WW build.
 
Something to be reposted as well (the only other Barb issue I saw), is that people were claiming that Sprint was being double or even tripled used at times in very, very short succession causing their fury to drop quickly. I haven't seen this, but I rarely use WW build.

The upcoming v1.5 changes so much behind the scenes. Despite the (bizarre and frankly confusing) rumours on the old Trinity thread - I've done very little the past 6 days but work on this new Trinity build - while at the heart it's the same, I've re-worked a hell of a lot of the target handling, skill-selection, object-handling etc. to make everything a lot smoother, faster, and use a lot less CPU use. Hopefully in the process, any of these skill oddities will have vanished - though myself and others in IRC I asked, none of them every got a double-sprint issue - I know for a fact lag/bad latency can cause this though - if DemonBuddy sends sprint to D3, and D3 is slow to get the buff up - and next DemonBuddy loop it sees there is no buff yet, it can re-send the skill - by which time perhaps the first one will have made the buff appear in your D3 client. I've attempted to fix this, too, though. I've also made changes to the way Whirlwind itself handles, and it should whirlwind better, and use less fury.
 
Awesome man. I can't wait. I fucking love botting itself, but I get a kick out of min-maxing the bot to nigh perfection.

Looking forward to the update. If you ever need someone to test, let me know.
 
- Changes to "Leap" to be used on low-health, against elites, or against certain ranged units (change mainly made by forum user Bombastic)

Is it possible to have a checkbox to switch between this "New Leap" and the "Old Leap"?

-"New Leap" seems to decrease Items Per Hour, GPH and increase runtimes for those that are not having gear issues or farming on earlier difficulties.

-"New Leap" doesn't seem to be as mobile as the "Old Leap".

-"Allow out-of-combat movement powers" when ticked, basically causes a lot of backtracking such as leaping and charging at corpses or empty space.
 
Giles I personally wanted to thank you for your work to the botting community, without you I dont think this bot would function even a fraction of how well it does and not be worth using. Your continued work with this plugin is greatly appreciated by many please continue to do the great work that you do with this plugin.
 
The upcoming v1.5 changes so much behind the scenes. Despite the (bizarre and frankly confusing) rumours on the old Trinity thread - I've done very little the past 6 days but work on this new Trinity build - while at the heart it's the same, I've re-worked a hell of a lot of the target handling, skill-selection, object-handling etc. to make everything a lot smoother, faster, and use a lot less CPU use. Hopefully in the process, any of these skill oddities will have vanished - though myself and others in IRC I asked, none of them every got a double-sprint issue - I know for a fact lag/bad latency can cause this though - if DemonBuddy sends sprint to D3, and D3 is slow to get the buff up - and next DemonBuddy loop it sees there is no buff yet, it can re-send the skill - by which time perhaps the first one will have made the buff appear in your D3 client. I've attempted to fix this, too, though. I've also made changes to the way Whirlwind itself handles, and it should whirlwind better, and use less fury.

Lol Giles, since you found it odd, here's the line of code that I copied over your normal one which fixed my problem. Maybe you'll realise what was changed and what caused the issue (mind you, I play with 250 or so ms, and someone with 400+ stated they never had the problem).

Code:
// Sprint buff, if same suitable targets as elites, keep maintained for WW users
if (!bBuffsOnly && hashPowerHotbarAbilities.Contains(SNOPower.Barbarian_Sprint) && !playerStatus.bIsIncapacitated && 
(GilesUseTimer(SNOPower.Barbarian_Sprint) &&
((playerStatus.dCurrentEnergy >= 40 && !playerStatus.bWaitingForReserveEnergy) || playerStatus.dCurrentEnergy >= iWaitingReservedAmount) && PowerManager.CanCast(SNOPower.Barbarian_Sprint)))
{
return new GilesPower(SNOPower.Barbarian_Sprint, 0f, vNullLocation, iCurrentWorldID, -1, USE_COMBAT_ONLY, USE_SLOWLY);
}
 
Is it possible to have a checkbox to switch between this "New Leap" and the "Old Leap"?
-"New Leap" seems to decrease Items Per Hour, GPH and increase runtimes for those that are not having gear issues or farming on earlier difficulties.
-"New Leap" doesn't seem to be as mobile as the "Old Leap".
-"Allow out-of-combat movement powers" when ticked, basically causes a lot of backtracking such as leaping and charging at corpses or empty space.

Yes I missed the range-check out of the leap-code, this is my mistake. I've re-uploaded v1.5 with nothing but that one quick change in, so just re-download it (I didn't bother changing the version to v1.5.1 just for this one thing, so don't worry that the version # is the same!). Good spot!

BTW I'm going to be really nitpicking about your GPH/IPH stats - even though you are quite right the leap thing had stopped being used at range on grey mobs and that may well make runs less efficient - your GPH and IPH stats can't be very accurate yet, as I made the Trinity threadat 04:21, given time to notice, download, fresh-install DemonBuddy, install Trinity, at best you'd probably start at about 04:30... that gives you at best, 13 minutes total running time. Hourly stats in 13 minutes are really, really, really unreliable. 24h+ would give a better idea. Yes yes, super picky, but I do like to put things into perspective at times! :D

Anyway, go re-download and see, it should be back how it was, with bonus-leaps on certain ranged-mob greys only (which really shouldn't change much, it should just be an extra leap failsafe!).
 
Lol Giles, since you found it odd, here's the line of code that I copied over your normal one which fixed my problem. Maybe you'll realise what was changed and what caused the issue (mind you, I play with 250 or so ms, and someone with 400+ stated they never had the problem).

Make sure you have TPS disabled, and try v1.5. If you still get double-sprint issues, let me know - it likely will be latency (having high latency won't GUARANTEE it, it just won't help matters!) - and I'll sort something out for you - simply removing the ", true)" from the giles timer check should do the job, and removing the "! has buff" - and just making Sprint be based purely on a 2.8 second re-cast time regardless of buff status. Might end up slightly less reliable casting at times, but will prevent any chance of double-casts.
 
Is backtracking an inherent/inherited problem from DemonBuddy?

Even when my barb isn't chasing goblins, after combat, it went back at least 2 to 3 screens (worst case was 5 screens) to pick up nothing at an empty spot.
 
Is backtracking an inherent/inherited problem from DemonBuddy?
Even when my barb isn't chasing goblins, after combat, it went back at least 2 to 3 screens (worst case was 5 screens) to pick up nothing at an empty spot.

Assuming you haven't enabled Trinity's backtracker (which is something else altogether) - yes Db will go to the *LAST* waypoint in the routine/profile it was trying to reach, once all targets have been dealt with (so no combat/loot/shrines etc. left). I think this is purely so DB doesn't ever get "lost", but personally, I'd like to see it as an option that could be disabled, or tweaked in some way - there's definitely times when it's just not needed.
 
Hey Giles is there any advantage or disadvantages in making my TPS to maximum 15??

My comp can handle the extra load fine
 
Just noticed hes not destroying the big wagon at the beginning of battlefields in act 3, and sometimes there's another one in the fields that im pretty sure has the same ID.
 
Last edited:
Back
Top