EverQuest 2 » BJScripts » Prestige - Quest Bot

Spent a good chunk of the day working on this... I've tried with speed buffs, without, and forced walk mode. I've messed with all of the various settings with no luck. The bot will just completely miss nav points by a mile. Can't figure this one out.

Ya this bug is a real downer... when I get lucky and avoid it my guys just run perfect. It's awesome. Just no way to get any consistent runs unless I find a way to avoid it or you find the bug. I'd love to help track this down in any way that I can... it's just hard without access to the actual code. Did you code your navigation from scratch or is it based off something publicly available? Maybe you could add some additional debug info as it is pretty limited right now. It would be nice to know what the current loc the bot is actually trying to get to and anything else useful. It does seem to output the distance to the next loc as you get closer under the p2p stuff. But those aren't very frequent as I assume navigation requires near real time monitoring of current location, velocity, etc to be able to hit the mark with any degree of accuracy. With this issue I would guess that it is either not setting the nav point correctly or for whatever reason the bot stops checking or getting nav updates to know when it should stop. Anyway, if you can dump some serious debugging info in there it might help to identify what is going on when it happens. 

Like I said before... I would focus my attention to the area where the bot pauses mid navigation to allow ogre bot to deal with aggro. The problem hits after the aggro is gone and the bot tries to resume to the rest of the current navigation path. I feels like it happens most when you are very very close to the end of the current nav path. Like if you stop just before or on the last nav point in the path... or if that path only has one nav point. I did test changing all of my nav paths to Ignore Combat = |TRUE| and it seemed help a lot... but I only did one run as I thought I'd found another solution. I might try doing that again for testing... not really a solution. 

I did notice some naming issues in the nav files that is a symptom of deleting or changing around the points after auto plot:

        <Set Name="Move15">
            <Setting Name="auto-1">Name: |auto-5| X: |48.866665| Y: |61.981133| Z: |-15.863050|</Setting>
            <Setting Name="auto-2">Name: |auto-1| X: |47.254021| Y: |67.377563| Z: |-35.856663|</Setting>
        </Set>

Wasn't sure if the "Name" value was used for something as this could throw things off. I fixed them and it seemed to help for a bit but then the bug just came back so I assume that this doesn't matter.

Run speed doesn't seem to matter much either with this... I've seen it happen with forced walk, 0%, full speed with mount. When it decides to get a brain fart it's just game over.

I do see with high run speeds that my toons will start to bounce between nav points... oh I missed my spot go back to the last one.... ok try again... oh missed it back to the last one... etc. P2P sensitivity adjustments seem to help with this. At high speeds you need a bigger number. However if you drop to forced walk and leave it at the default of 3 it will stop way short of the loc. Adjusting it to 1 when in forced walk it is right on it. But if you go back to normal speed it can't hit the mark with a sensitivity 1 and will start bouncing. For best results this value should really be dynamic based on your run speed or velocity. 

Just for the reccord I have been able to reproduce this on multiple computers. I also got a friend setup recenly with your scripts and we see the behaivor on his system as well. So I'm not totally crazy... something is going on here. 

Just let me know how I can help to get this figured out... 

Does your QB file that is giving you trouble have Search for Collectible in it?

Yes all of my quest files have been updated to include collectible. However they are usually right after a named kill. My nav issues don't happen anywhere near the collection lines.

I also considered it might be something odd with loot... but i've turned off move to loot a long time ago. Think I've also run it with all loot optionsoff as well.

Just a heads up on the nav issue... as a test I prepulled all of the zone trash before I started the quest bot. This way the quest bot could go though the zone without getting any aggro other than named encounters. I was able to string together 3 runs that were flawless by doing this. Pretty much just confirms that the area that needs attention is restarting nav after an aggro stop mid path.

Anyway, just an FYI. Let me know if there is anything I can do to help track this down. 

The name in the listbox has no bearing on the actual navigation.  It was first implemented for users to have an easy way discuss specific nav points.

I am trying to reproduce this in the guild hall with training dummies, but I haven't had much success.  First, I created a circle navigation path around the left room in the halas guild hall.  Then I placed dummies around the path, which I aggro'd on a second toon that was in group.  15/15 times the character running QB stopped for combat, dealt with it and then safely resumed navigation.

I did add a few additional debug messages and changed a couple of things with combat and navigation. Below are the changes:

• Previous combat behavior:  BJQuestBotController detected aggro while we were on a navigation step and ignore combat was false.  It would set a variable to true and when the navigation script reached the check for that variable it wait while it was true.  When combat ended, the navigation script would resume navigation before the controller script had cleaned up from being in combat.  In my guild hall test, I was actually navigating 2 additional nav points before the controller script was officially finished with "combat".
• New combat behavior: BJQuestBotController detects aggro while we are on a navigation step and ignore combat was false.  It sets two variables to true and when the navigation script reaches the check for combat variable it will wait while true.  It will also wait for the second variable which is controlled by the checkforcombat routine inside of BJQuestBotController to finish the combat routine before it allows navigation to continue.  In my guild hall tests, this seems to make more sense when reading the debug information.  I have attached a picture showing how the new debug will look.

Please note that when navigation is resumed after combat that it does not change the Current Nav Point.  Each Current Nav Point displayed in green is the bot moving on to the next navigation point because it reached the previous one within it's P2P Sensitivity.

Tried to reproduce the issue using the guild hall test multiple times... fixed. Ran Bilgewater Falls & The Hidden Caldera (the 2 zones where the bug hit most frequently) 4 times each... fixed. Also, ran a few other zones as well with zero navigation issues. I'm confident in saying that this bug has been squashed! This should greatly increase the reliability and consistency of the quest bot... I'm very glad we found and fixed this!

Oh ya, I'd like at least one entry in the 2015 BJScripts Bug-Finding Contest! Mabye 2 since I included drawings with my bug report ;)

I'm gonna have to find another bug to work on... cause I'm sure you are going to miss me nagging you about stuff every 2 hours. Haha