TEST: genbot.mac w/ 3D Follow
Moderator: MacroQuest Developers
Ah I see, I'll take a look at the rangesub etc. and see what can be tweaked. Keep in mind though some of that can already be tweaked in your INI file as far as the minimum, maximum and fastmove distances are concerned.vaelin wrote:It did accept a nice variance, don't get me wrong. I'd like to hack a bit at the code and see if it could be improved slightly; I haven't looked at the positioning code for the botcombat things. Most of the more obvious oddities about positioning scripts have been a few things....
"exact-ness" ... script wants to be <12 but >8 distance away, and the end result is a lot of back-and-forth action, when in reality, most melee just get behind and stick there unless they are either too far away, or no longer behind. (barring the occasional max-range fight)
Positioning ... doing odd stuff when the back of the mob is unreachable.
Bear in mind I didn't have a problem so much with the /target stuff (beyond it being possibly detectable) ... it was the "I'm zoned, now I'll move forward a few paces" bit. Both are somewhat odd... but it's shaping up to be a really slick addon.
I'll also take a look at having it "give up" trying to get behind a mob if it is in a corner or unreachable spot and just stand in front of the mob.
I'm an idiot, and you're right, the range stuff is in the ini.
I always assumed (ass-u-me) that the range logic worked more along the "I'll inch forward if I'm getting -your target is too far away- messages" mixed with the "I'll strafe behind if I'm not" logic.
Forgive my newbness, I'll have to hack more in the melee bits and learn.
I always assumed (ass-u-me) that the range logic worked more along the "I'll inch forward if I'm getting -your target is too far away- messages" mixed with the "I'll strafe behind if I'm not" logic.
Forgive my newbness, I'll have to hack more in the melee bits and learn.
New versions of:
botcombat.inc -- Added new version of get behind code from cronic's beastlord script. Hacked it up a bit. Added some timers, one to try to get behind for 5 seconds. If you can't get behind the mob it waits 10 seconds and tries again.
bothealer.inc (Added a fix from a user post.)
personal.inc (Added fixes from a few users posts.)
botspell.inc (Added a fix from a users post.)
Lasher? Where are you I need all this in your thread its been fairly well tested.
botcombat.inc -- Added new version of get behind code from cronic's beastlord script. Hacked it up a bit. Added some timers, one to try to get behind for 5 seconds. If you can't get behind the mob it waits 10 seconds and tries again.
bothealer.inc (Added a fix from a user post.)
personal.inc (Added fixes from a few users posts.)
botspell.inc (Added a fix from a users post.)
Lasher? Where are you I need all this in your thread its been fairly well tested.
This thread is more for testing of movement feature additions, than spell casting. if you make your post to the main GenBot thread, I will take a look at it.crisdan wrote:Could someone please respond to my above post regarding buffing from shaman bot :>
[b]- Bad Karma
________________________________________[/b]
In our own quest for excellence, we should strive to take the time to help those who help themselves.
All others should [b]RTFM[/b]!!!!!!!!!
________________________________________[/b]
In our own quest for excellence, we should strive to take the time to help those who help themselves.
All others should [b]RTFM[/b]!!!!!!!!!
Can't thank you enough. But I'm a nitpicker, and I find bugs well, I guess...
1. If follower zones faster than the leader, follower targets an object, moves slightly, then never recovers and continues following, even if leader zones in later.
2. If leader zones faster than follower, no problems.
3. I would highly recommend no /face fast in transit. Those ping-pong NPC-type movements are HIGHLY obvious. I'm noticing less, but this practically has to be zero, since there's no "humanly" possible way for this to happen, and it's a dead giveaway. /face fast at the beginning is fine...
4. Are there provisions for casting in this? In other words (and this isn't what I had a chance to test) the following logic should be defined (I didn't notice any follow logic in the botspells):
a) casting only while within range? (in range = closer than the InitAPFVars final variable) This could pose a problem if for example a healer type is being beat on as they are moving toward the leader in a dungeon, so should perhaps be a variable
b) pause while casting, check distance if interrupted or failed, etc
Are the /face fasts are result of my crappy machinery? Not sure what triggers those.
1. If follower zones faster than the leader, follower targets an object, moves slightly, then never recovers and continues following, even if leader zones in later.
2. If leader zones faster than follower, no problems.
3. I would highly recommend no /face fast in transit. Those ping-pong NPC-type movements are HIGHLY obvious. I'm noticing less, but this practically has to be zero, since there's no "humanly" possible way for this to happen, and it's a dead giveaway. /face fast at the beginning is fine...
4. Are there provisions for casting in this? In other words (and this isn't what I had a chance to test) the following logic should be defined (I didn't notice any follow logic in the botspells):
a) casting only while within range? (in range = closer than the InitAPFVars final variable) This could pose a problem if for example a healer type is being beat on as they are moving toward the leader in a dungeon, so should perhaps be a variable
b) pause while casting, check distance if interrupted or failed, etc
Are the /face fasts are result of my crappy machinery? Not sure what triggers those.
Actually this is exactly the kind of thing I like to hear. Nothing wrong with constructive criticism and pointing out bugs. I'm fairly sure I have a way to fix your first issue. I'll look into it tonight.
The second issue.
You can shut off the /face fast in transit by changing this:
To this:
I'll have to test the pause while casting thing. I know that I looked through the botspell and bothealer code and I didn't think I noticed anything stopping the character while using afollow but I do recall with my cleric he'd pause and cast. I should be able to take care of this as well.
The second issue.
You can shut off the /face fast in transit by changing this:
Code: Select all
/call InitAPFVars 1 15 13
Code: Select all
/call InitAPFVars 0 15 13
I'll have to test the pause while casting thing. I know that I looked through the botspell and bothealer code and I didn't think I noticed anything stopping the character while using afollow but I do recall with my cleric he'd pause and cast. I should be able to take care of this as well.
advpath.inc updated.
Fixed the issue if the follower zoned faster than the followee. If it takes longer than 30 seconds for the person that you are following to zone in, it will shut off follow mode.
I also fixed another issue. I was looking for "port" named portals in the zoning code. Apparently portal stones can have "port" or "tele" in the target name.
Fixed the issue if the follower zoned faster than the followee. If it takes longer than 30 seconds for the person that you are following to zone in, it will shut off follow mode.
I also fixed another issue. I was looking for "port" named portals in the zoning code. Apparently portal stones can have "port" or "tele" in the target name.
Updated:
genbot.mac
botcombat.inc
bothealer.inc
personal.inc
These modules have been updated to allow you to leave the 3D follow turned on and fight, cast etc. It should wait til after combat is through and start following again. Please let me know if you run into any issues.
I still have the 'sit' command shutting off follow (Only if you actually send the bot the command to sit. Not if part of the code actually does an EQ /sit). I could have it do a pause (It would still queue up the path of the player/npc you are following) and then unpause (It would then play out the path in its entirety unless you are withing a small radius of the player/npc you are following, then it would shortcut and disregard the rest of the path.) when you issue a 'stand' but not sure if thats a good idea or not.
Please let me know if this is something you'd like to see or not.
genbot.mac
botcombat.inc
bothealer.inc
personal.inc
These modules have been updated to allow you to leave the 3D follow turned on and fight, cast etc. It should wait til after combat is through and start following again. Please let me know if you run into any issues.
I still have the 'sit' command shutting off follow (Only if you actually send the bot the command to sit. Not if part of the code actually does an EQ /sit). I could have it do a pause (It would still queue up the path of the player/npc you are following) and then unpause (It would then play out the path in its entirety unless you are withing a small radius of the player/npc you are following, then it would shortcut and disregard the rest of the path.) when you issue a 'stand' but not sure if thats a good idea or not.
Please let me know if this is something you'd like to see or not.
Hopefully I'll test the casting/combat stuff soon...
I turned off the fast fast flag. I remember now why I had that on, and I'll try to describe in the best way possible.
Here's my line: /call InitAPFVars 0 15 50
I want my bot to be range 50 from me, basically, or if within that, not moving. I can inch away so that I'm 51 ... he'll turn toward me .. start running ... then OVERSHOOT me by 50 and start circling around me endlessly. Face fast fixes that, but is almost just as bad.
I can reproduce this multiple times. I can say that it DOES work normally sometimes, but it's so unreliable that I can't really inch in a dungeon for example without fears that the bot will leap forward ahead of me and start circling around in a crowded room.
And as a reference when it does work fine and stops, the bot overshoots me. So if you think about it this way, I'll be running foward, wait a few seconds, then my bot runs right in front of me to obscure my view. Lol.
Very rarely does the bot stop a few paces behind me, would would be perfect.
Am I doing something wrong? If so could you explain those parameters to me a bit better? I read the intro description you put on them but it's not very helpful to me, I'm sorry... and simple trial and error doesn't seem to illustrate it well...
The no face fast toggle was perfect for the big stroke "moving across zone" issues, although I still catch the bot occasionally running in circles, which is really screwed up, but not as "hey-I'm-a-bot"ish as /face fast. Even happens when running in straight lines on hills. Boggle.
Is the script affected by a slow machine? I got one...
I turned off the fast fast flag. I remember now why I had that on, and I'll try to describe in the best way possible.
Here's my line: /call InitAPFVars 0 15 50
I want my bot to be range 50 from me, basically, or if within that, not moving. I can inch away so that I'm 51 ... he'll turn toward me .. start running ... then OVERSHOOT me by 50 and start circling around me endlessly. Face fast fixes that, but is almost just as bad.
I can reproduce this multiple times. I can say that it DOES work normally sometimes, but it's so unreliable that I can't really inch in a dungeon for example without fears that the bot will leap forward ahead of me and start circling around in a crowded room.
And as a reference when it does work fine and stops, the bot overshoots me. So if you think about it this way, I'll be running foward, wait a few seconds, then my bot runs right in front of me to obscure my view. Lol.
Very rarely does the bot stop a few paces behind me, would would be perfect.
Am I doing something wrong? If so could you explain those parameters to me a bit better? I read the intro description you put on them but it's not very helpful to me, I'm sorry... and simple trial and error doesn't seem to illustrate it well...
The no face fast toggle was perfect for the big stroke "moving across zone" issues, although I still catch the bot occasionally running in circles, which is really screwed up, but not as "hey-I'm-a-bot"ish as /face fast. Even happens when running in straight lines on hills. Boggle.
Is the script affected by a slow machine? I got one...
It's most likely the slow machine that is the culprit. Genbot does SO much and the 3D follow code polls whenever it can to check your distances. If it can't check the distance and catch it in the sweet spot I can see it doing what you are stating.
This: /call InitAPFVars 0 15 50
Would be bad in my opinion. What this would do is keep track of the person you are following if they've moved 50 locs (for lack of a better term). What might be more effective is:
/call InitAPFVars 0 10 13
Or something like that.. the lower you go with the 2nd parameter the less "accurate" it tries to be. Basically it would mean, if I am within $char(speed)/10 locs from the next location the person ran assume I'm there.
This should hopefully resolve your problem. You could try it even lower if you still have problems but it might become very inaccurate. Hard to say.
This: /call InitAPFVars 0 15 50
Would be bad in my opinion. What this would do is keep track of the person you are following if they've moved 50 locs (for lack of a better term). What might be more effective is:
/call InitAPFVars 0 10 13
Or something like that.. the lower you go with the 2nd parameter the less "accurate" it tries to be. Basically it would mean, if I am within $char(speed)/10 locs from the next location the person ran assume I'm there.
This should hopefully resolve your problem. You could try it even lower if you still have problems but it might become very inaccurate. Hard to say.
Ok, I'll test out the actual movement parts on a speedier machine before I offer critique of it, I understand how that could screw up processing. I have been twoboxing on one machine lately, so I agree, it's most likely the problem.
I would recommend a flag for "moving after zoning" though, if that stays in. The bot, when zoning faster than the leader, still zones in, moves forward about 40-50locs... that could be bad in some zones.
I know you can probably just say to not zone into those areas with this script on, but I think it'd be more appropriate when zoning into a new area to have the bot wait and not do anything til the leader zones.
I would recommend a flag for "moving after zoning" though, if that stays in. The bot, when zoning faster than the leader, still zones in, moves forward about 40-50locs... that could be bad in some zones.
I know you can probably just say to not zone into those areas with this script on, but I think it'd be more appropriate when zoning into a new area to have the bot wait and not do anything til the leader zones.
vaelin,
I put in a fix for the zoning thing yesterday. Are you even on the latest rev?
I'm not saying this to be rude, but please check your revisions and verify you are on the latest version before saying "x is broken". The reason is that I end up wasting time looking for something that is probably already fixed. Thanks.
I put in a fix for the zoning thing yesterday. Are you even on the latest rev?
I'm not saying this to be rude, but please check your revisions and verify you are on the latest version before saying "x is broken". The reason is that I end up wasting time looking for something that is probably already fixed. Thanks.
Updated:
genbot.mac (Just changed the turbo value to use max turbo. This isn't a problem if the macro isn't misbehaving, which it doesn't seem to be.)
advpath.inc -- Changed 2 instances in the script where I could use $spawn(id,distance,3d) instead of calculating 3d distance via macro calculations. (These get called a decent amount so it might help with performance a little.)
genbot.mac (Just changed the turbo value to use max turbo. This isn't a problem if the macro isn't misbehaving, which it doesn't seem to be.)
advpath.inc -- Changed 2 instances in the script where I could use $spawn(id,distance,3d) instead of calculating 3d distance via macro calculations. (These get called a decent amount so it might help with performance a little.)