Another addition to the plugin: On the quest Free Spirits, the plugin makes you fly up if you ever get into combat...however, the issue is if the bot flys you above ~15-20 yards above ground level, it can't path back down. It then gets stuck until user intervention lowers it down. Can you add a line to make it drop back down? Maybe do "Fly up, sleep 1 second, fly down"
since version 2.0.3 the Bot will fly to the Spirits automatically, avoid combat and blacklist the free Spirits. So you can change your profile to: <CustomBehavior File="InteractWith" MobId="59231" IgnoreCombat="True" CollectionDistance="5000" WaitTime="300" KeepTargetSelected="false" /> I have it posted in the ChangeLog.
I have a problem with Free Spirits where the bot will go to free the spirit and it gets close and just runs away without actually freeing the spirit. This will keep looping forever.
have you stopt and start HB while you have the aura Spirit Void ? Then could errors occur *edit* and dont use the portal manually, HB must make that up itself.
Had the bug of no path available a couple times when the bot flies upwards (avoiding combat) but flies so high that it can't re-path down due to still being in combat (Serpents) I believe the CC is taking over and forcing dismount, but no path to ground can be created, but im not sure. Sometimes it flies to the ceiling (rarely) other times it flies just above the pathing threshold, and can't get back down.
maybe it helps if you change the code into this: PHP: if (Me.Mounted && (Me.Combat || (Tormentor != null && Tormentor.Location.Distance(Me.Location) < 10))){ WoWMovement.Move(WoWMovement.MovementDirection.JumpAscend); Thread.Sleep(836); WoWMovement.MoveStop(WoWMovement.MovementDirection.All); if (Me.Combat)Thread.Sleep(700); } if (CaptivePandarenSpirit != null && CaptivePandarenSpirit.Distance >= CaptivePandarenSpirit.InteractRange && Me.Mounted) { while (CaptivePandarenSpirit.Distance >= CaptivePandarenSpirit.InteractRange) { if (Me.Combat) { WoWMovement.Move(WoWMovement.MovementDirection.JumpAscend); Thread.Sleep(836); WoWMovement.MoveStop(WoWMovement.MovementDirection.All); if (Me.Combat)Thread.Sleep(700); continue; } Flightor.MoveTo(CaptivePandarenSpirit.Location); Thread.Sleep(80); } WoWMovement.MoveStop();} i dont have the quest/bug, could you test it?
Stupid me...I have updated your plugin numerous times to my SVN...but never to my Plugins folder...I will retest before making changes.
OK Barry, here's your next project! The mobs inside the cave for Shieldwall/Dominance quests. There are a few mogu, some ghosts, and a pair of "bosses". Some ground aoes (similar to the behemoth from GL) and a ground aoe similar to Earthquake from shamans, as well as several other avoidable spells. GOOD LUCK! And thank you for all the hard work!
Hi Brodie, that does not sound easy... did you mean these quests? http://www.thebuddyforum.com/honorb...plete-mop-daily-experience-35.html#post997052
Well not ALL of them but the downside I see in the cave is too much movement will throw the character off track, and then the CTM Nav will break...
The latest revision (645) of the MoP Complete Dailies contains an update for Pandaria Dailies v2, which causes problems with the Golden Lotus dailies. See attached log.
In my defense, that issue was there last night, and relates (if I remember right) to the line associated with Shadowmaster Sydow. Last night I added support to knock over mogu statues since the profile command to interact was insufficient. I will look into it more now that I'm awake and see what's up with Sydow.
Of course: There are 2 known issues I've encountered with InteractWith. (Sorry I have not posted an official bug report on them) 1) In Ruins of Guo-Lai, on Quests "Hard as a Rock" and "No Stone Unturned", the Mogu Statues in the area need to be Right-Clicked to activate. There are two outcomes: 1 statue (63447) will come to life and attack! The second (63556) will tip over and die. The issue is after the first statue is interacted with (whether its the first or second type) the second will not accept the interact command. It will loop endlessly saying it is interacting, showing in the logs that it is properly interacting, but no change occurs on screen. I went into the plugin and added a "If != NULL, then Interact" to both types. This fix was used with the flames in Mistfall Village, and every time you walk over one, it gets "right-clicked". This fixed the problem, since InteractWith already closed the gap to 1 yard (by Range), then the plugin takes over and right-clicks. 2) In Mistfall Village, I've noticed that any InteractWith commands to seek out multiple objects (examples: Flames on ground, Cornered Villagers) will report to the bot that it is interacting with a HUGE list of them all at once (shows: Interacting with: Cornered Villager, Cornered Villager, Cornered Villager, Cornered Villager, Cornered Villager, Cornered Villager, Cornered Villager, Cornered Villager, Cornered Villager, Cornered Villager) As it is interacting (with villagers) it moves around properly, does as intended, but never breaks the InteractWith command after completion. Even with a NumOfTimes="1", it will still interact endlessly between all Villagers, new and old at the time of execution. 2a) Secondly is the Flames on the ground for "My Town, Its on Fire". There are lots. And as I said above, if I use InteractWith, it makes a list of Flames a mile long (see above example with villagers). It will approach one of the flames.......pause for 5 seconds.....interact with the flame intended.....pause for ~20-30 seconds......then attempt to interact with the same flame again whether or not it is there. Even though there are MANY more around it, it will stick to one spawn and never move. I countered this with adding the Fire[0].Interact into the plugin ages ago, but it only works while the bot is in motion over flames, so i changed it altogether to farm for water buckets and use them...which does bring up another issue... 3...or C...or maybe III) UseItemTargetLocation: If items intended for use = 1, and is properly used, Custom Behavior then sticks, thinking 0 is a valid number of inventory items and tries to use endlessly. I have countered this by making sure it never drops below 1 in inventory (GetItemCount check) but it would be more efficient if I only had to get 1 at a time. Sorry for hijaking the post for a bug report.
the problem by the flames (2/2a) is, that the flames does not disappearing. I think they just change the animation state and the InteractWith behavior does not check this. That could also be the problem at the Mogu Statues (1). I have a new full time job and therefore I have not enough time to test and Programming everything.
Barry no one expects perfection or us o make this their full time job. The work you've done is awesome this far, and as a team we're only making it better!
Thank you, I do my best! But actually everyone wants "perfection", especially the creator. this is not different with you, right?! Also is "everything" maybe the wrong expression wise. I meant "everything" in relation to the "flames/Mogu Statues"
You got it. And yeah sure I want perfection. Who doesn't. Just don't complain about lack perfection in the first month or two. If everything could be released as perfection, there would be not v1.x, or r2+ svn's. Hey take a look at my update on my SVN. I got mogu statues working. I want to add something that will cause the bot to use items for specific mobs in the future, if you can help me out with that.
