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

Trinity .26 potential fix for performance problems (took xxx ms)

S

SweSteve

New Member
Joined
Apr 8, 2014
Messages
19
Reaction score
0
in dbuddy\Plugins\Trinity\Movement you have a file called NavHelper.cs

Now, if you change row 202-205 to this, it will change the way the bot navigates and it will take less performance.
I'm not 100% sure how it affects the bots performance overall (time per run etc), but for me it works flawlessly

I'm sure rrrix will find a way to fix this in a neater way after some time.

Original Code:
Code: 
const float gridSquareSize = [B]2.5f;[/B]
const int maxDistance = [B]150;[/B] 
const int maxWeight = 100;
const int maxZDiff = 14;


Modified code:
Code: 
const float gridSquareSize = [B]5f;[/B]
const int maxDistance = [B]50;[/B] [B][/B][B][COLOR="#FF0000"]Edit: < this one can be tampered with, i'm using 100 right now and that works just a good[/COLOR][/B]
const int maxWeight = 100;
const int maxZDiff = 14;

Modfied file here:
NavHelper.cs - Pastebin.com

Been running YA Riftbot for 2 hours straight now without a SINGLE red line in the log window! Post results in this thread to see if you can replicate my good results
 
Last edited:
very nice fix!

const float gridSquareSize = 5f;
const int maxDistance = 100;

some of these annoying performance spikes are gone but not all.


looks like profiles who temper with the kill radius (>40) are a problem.
 
Last edited:
This seems to help a bit but most of the performance problems I get come from this.

[Trinity][Performance] Execution of the block NavigateTo took 1502.92ms.
[Trinity][Performance] Execution of the block HandleTarget.HandleBasicMovement took 1504.70ms.
[Trinity][Performance] Execution of the block HandleTarget took 1538.54ms.
 
This won't actually "fix all the performance problems", just FYI. Your avoidance capabilities won't probably work as well either.
 
Gorm said:
This seems to help a bit but most of the performance problems I get come from this.

[Trinity][Performance] Execution of the block NavigateTo took 1502.92ms.
[Trinity][Performance] Execution of the block HandleTarget.HandleBasicMovement took 1504.70ms.
[Trinity][Performance] Execution of the block HandleTarget took 1538.54ms.
Click to expand...

This is nothing to do with Trinity - this is the internal DB path finding taking 1.5 seconds to generate a path so the bot could move to its destination in combat.
 
rrrix said:
This is nothing to do with Trinity - this is the internal DB path finding taking 1.5 seconds to generate a path so the bot could move to its destination in combat.
Click to expand...

I figured as much.

Any reason why it needs to query the DB nav servers?

I am assuming it is a nav server problem because everyone gets the same 1500 ms duration.

Is it possible to just get the nav mesh ourselves and do A*?
 
The nav servers are no longer in the picture - DB is always using local nav now as of RoS.

We can read the nav mesh but it's very expensive (CPU) to do so and extremely complicated, i'm not really up for it :). DB already has A* built in, that's what this function uses. This is likely happening because paths are attempted to be generated around units, gizmo's, and AoE, and if there's no "clean" path it will have to do multiple iterations and it takes longer to do so.
 
Well I am glad to hear that it is client side now.

But why does it always take 1500ms?

Is there some setting we can use to make this timeout lower so our bot doesn't die in combat?
 
Gorm said:
Well I am glad to hear that it is client side now.

But why does it always take 1500ms?

Is there some setting we can use to make this timeout lower so our bot doesn't die in combat?
Click to expand...

Your bot will still die because it won't be able to walk anywhere :)
 
rrrix said:
Your bot will still die because it won't be able to walk anywhere :)
Click to expand...

Well actually no it won't. There are many times the bot would have lived if it attacked instead of doing absolutely nothing for 1.5 seconds.

It doesn't make sense for everyone to have the exact same duration of 1500 ms every time when we all have different CPUs.

If it is returning the best position early, then we should have the ability to set the timeout especially when the bot is in combat.
 
maxdistance = 50 is too small.

In big rooms with narrow hallways (like hell rifts or silver spire) I kept getting:

Code: 
[Trinity] Visited all nodes but objective not complete, forcing grid reset!
[Trinity] Visited all nodes but objective not complete, forcing grid reset!
[Trinity] Visited all nodes but objective not complete, forcing grid reset!

even though there was more map to explore.

Changing the value to 100 fixed it.
 
Aternal said:
maxdistance = 50 is too small.

In big rooms with narrow hallways (like hell rifts or silver spire) I kept getting:

Code: 
[Trinity] Visited all nodes but objective not complete, forcing grid reset!
[Trinity] Visited all nodes but objective not complete, forcing grid reset!
[Trinity] Visited all nodes but objective not complete, forcing grid reset!

even though there was more map to explore.

Changing the value to 100 fixed it.
Click to expand...

Those two things are completely seperate.
 
Gorm said:
Well actually no it won't. There are many times the bot would have lived if it attacked instead of doing absolutely nothing for 1.5 seconds.

It doesn't make sense for everyone to have the exact same duration of 1500 ms every time when we all have different CPUs.

If it is returning the best position early, then we should have the ability to set the timeout especially when the bot is in combat.
Click to expand...

The 1500ms is internal to DB, and is not controlled or set by Trinity, AFAIK it can't be set.
 
rrrix said:
The 1500ms is internal to DB, and is not controlled or set by Trinity, AFAIK it can't be set.
Click to expand...

Can you use your dev connections to make this available as a parameter? :D

I think it would greatly improve DB if you could lower the timeout to say 500ms if in combat.

I tried running it in another thread and joining it with a timeout but there's some kind of thread detection that prevents it from working.
 
rrrix said:
The 1500ms is internal to DB, and is not controlled or set by Trinity, AFAIK it can't be set.
Click to expand...

Hello rrrix! My bot was doing Act1 Bounty, and inside the Cathedral, it was to kill a "Unique", he found the mob, but the mob was behind a door. The bot was trying to kill him until the Gold Inactivity activates. That is, he did not open the door to kill him. It is a issue on profile, trinity or DB?

Last DB Beta;
Trinity .26;
Last QuestTools;

I'm sorry for asking this here. And sorry for my english too.
 
rrrix said:
This won't actually "fix all the performance problems", just FYI. Your avoidance capabilities won't probably work as well either.
Click to expand...

I fully understood this when applying this "ugly fix". However, without this the game lagged like _hell_ and rifts was a pain to watch. I realize that the but i dumber, but since it does not lag its good "enough"

What causes these lag spikes?
 
You must log in or register to reply here.
Back
Top