After implementing the logging code, I've ran into several packs with arcane, and it doesn't appear to log anything to the DB window, or the actual logfile. Here's the log of this session, the last arcane pack I run into happens at [18:14:18.109].
edit; just to mention my logging is set to Diagnostic in the DB settings.
Wow, did I screw something up in that logging code I gave you? I don't think I did... hmmmm... I will get back to you on this. I have given myself the day off coding - I have done not more than 20 minutes work today, and have been enjoying my free time, having worked on the plugin heavily (12-14+ hours a day) every single day (weekend included) for the past 9 days or so! But tomorrow I will check this out, and see if I simply gave you the wrong debugging code, or if I have missed something horrible somewhere and have it NOT recording arcanes. Maybe the caching stuff? Maybe when an arcane ball *FIRST* appears, it starts off as an object type that is not treated as avoidance (eg a serverprop) - that is cached, and then when the ball "extends" it's laser beam, the object type changes - but by then it's already been cached. This might not be useful info to you but brainstorming ideas like this as I reply to people helps me remember possible solutions to look in to, so just ignore that if you didn't understand it, this will be useful to me when I read it back tomorrow
2 things,
First, I'm trying to figure out why the bot is not using rend reliably, and I don't think it has to do with the timings or the conditions to use rend (I have played around with these a lot). I notice that even when I play manually gasp, I sometimes does not cast rend when I am spamming it, which I think is caused be me getting hit but mobs with stun or knockback. What I think we need is some way to detect whether or not rend was actually cast. Ideally, there would be some way to check the animation state but a simple way would be to check the fury levels before and after attempting to rend. What do you think Giles?
That's great to hear that even playing manually it can fail to cast. I was starting to drive myself a little crazy with all the failsafes, double-checks I was doing - both reading the code, debugging it, and tweaking the code over and over to try and find causes of it not-casting for some people, sometimes. Checking a player's energy levels could be a sneaky little way of checking if some spells have been cast, for spells that always have an energy cost - but starts to get messy when players have gear that reduce energy costs of particular abilities, or certain runes or passives that reduce energy costs etc. - only a handful of skills would never change I would imagine. Recording "any drop at all" might work - but again, it's a bit dodgy. Since it happens when playing manually, I think we should stop trying to seek
absolute perfection, and just live with "good enough to bot act 3 exceptionally well" perfection.
Second, my bot always gets stuck in stupid places like
View attachment 53693 and although the unstucker does kick in, it is really annoying. My proposed solution is to check the "slope" from the player pos to the object (dz/dx) and if this is too high then it probably means the object is over a ledge and is unreachable. You could then temporarily blacklist the object for a few seconds or until you have traveled a certain distance. I would perhaps do this check every time a new target is selected.
Thanks for all the hard work Giles, and for listening to all the feedback!
There is actually already some Z-checking for objects - it helps prevent your bot targetting monsters that are on a lower-level/below a balcony from you etc.. I have to be careful not to set this cut-off-point too high as it can cause you to ignore a good shrine that's up a slight decline/incline on a hill etc. - and I've had to REDUCE that check for item drops (otherwise it would ignore an item that dropped at the top of the stairs while you were at the bottom). But it could probably be safely increased for objects like containers and shrines, as it's not a tragedy if it misses them now and then - getting stuck is worse (even if the unstucker resolves it).
does "hydra" work on wizards?
No reason it shouldn't. Always restart DB after changing skills though - as it does cache your skills, and changing skills with DB still up can cause it some confusion at times.
Guys, I've solved my problems.
I'm not totally sure, but it seems that setting TPS to 15 made bot reacting and fighting much faster.
I also have changed if (iLoopsSinceLastTargetUpdate > 8) to 4 and tried to force more frequent rend casting. Also set % of hp in avoidance settings to 55-60 in most cases.
Now I have again not more 2 deaths per hour.
Btw is it normal to have 8 FPS in background mode? How can I improve it? All graphic setting are at minimum.
Also it seems to me that health globes picking is not prioritized as it should be.
Hi Makaronnik. Your background FPS is way too low. This will have been causing your problems. Heavily increasing TPS, and changing that 8 to 4, will have helped DemonBuddy "make up" for the problems to some degree, but ultimately an FPS of 8 in Diablo 3 will cause the bot to act incredibly stupid, with or without my plugin.
Hey Giles,
is there a chance to put in something like "let inventory always open?"
i wanna see the loot, but everytime i must press I on every window :/
is there chance for this little option? ^.^
I believe this to be a risk. No player runs around with their inventory screen open while they play, because it gets in the way far too much and doesn't let you see everything that is happening. Learn to press i. Why you would want to see your inventory constantly, without even pressing i, is beyond me. Far more useful would be to look in the Trinity folder, and look at the item stash and item trash logs, surely?
my bot isnt using sweeping winds at all, no matter how many monsters are around and no matter if he used blind or theres elites. not sure why
if anyone has a fix please tell me
(EDIT: restarted bot and it works now, could be cuz of my relogger i guess???)
Could be. I'm glad you tried to restart the bot yourself. A lot of people that might post problems wouldn't even attempt that
Reloggers can cause issues, as I mention in the common problems of post #1 of this thread. I can't help you with specifics there, you'll have to ask in the relogger's thread, or try another relogger, or go without one until Radonic finishes his relogger!
Giles is there anyway to make the bot know if people are chasing after it instead of running away?
Only by constantly tracking positions of things, I'm not sure how useful that info is/what the purpose is to know if something is chasing something else?
Are Demon Hunters ever going to be supported? This is supposed to be the best plugin out there. Seems silly that an entire class gets excluded
Still using the 3 individual plugins and the work alright, but it would be nice to have the newer and improved one.
To me, silly is expecting a community dev to "Have to" support all classes and all users of the bot, just because his plugin is "the best out there". "You do the best work, how dare you not include everybody for free!". The moment DemonBuddy hire me and give me a wage, I'll start doing things that users of DemonBuddy want, rather than things I enjoy or that I want to spend time focusing on. As this doesn't look likely, patience will continue to be a much sought-after virtue. Still, if it gives you any comfort, yesterday I was "silly enough" to add a new settings tab into the AOE settings in my local-copy of Trinity I work on, add all the config file stuff in for DH, and add all DH skills to the internal skill dictionaries, in preparation for going through the skills and putting their usage-code/intelligence in. But don't take things for granted. You can make demands of the DemonBuddy team, as you paid for their product, but don't make demands of me. I can be expecting a rather sizable donation from you when I release the Demon Hunter update I guess, or would that be "silly" of me to assume people would donate for my time & work?
and although the unstucker does kick in, it is really annoying. My proposed solution is to check the "slope" from the player pos to the object (dz/dx) and if this is too high then it probably means the object is over a ledge and is unreachable. You could then temporarily blacklist the object for a few seconds or until you have traveled a certain distance. I would perhaps do this check every time a new target is selected.
