advpath.inc
Updated a bunch of my ${String's because Wassup was making fun of me
advpath.inc -- follow/record/playback pathing include file
Moderator: MacroQuest Developers
You don't have the latest version if you are getting those. Those are cause by having quotes in /echo messages and they should all be removed from the latest version. I'll double check it though.
To your other question, no I don't have anything like that in there. I'll look into trying to add that as a parameter if/when I get some free time.
To your other question, no I don't have anything like that in there. I'll look into trying to add that as a parameter if/when I get some free time.
First, thank you for this .inc. I love to use it as I can't stand staying in one zone too long.
One thing I've noticed is that the part that allows the bot to follow it's master through a zone doesn't work as well as before the MQ2Data version.
Some examples where it works intermitently; zoning from nro into oasis. PoK to North Freeport.
An example of not working at all; Zoning out of Nro LDoN's.
Finally, this is prolly more of a request as I don't see anything about this in the code; Is it possible for the bot to follow it's Master through the use of the LDoN Magus's? Perhaps have it watch the master for text used when in a zone with a Magus and use the same text, or perhaps /who the master till it sees the zone it went and use that if it wasn't near to see /say text? Just a thought.
One thing I've noticed is that the part that allows the bot to follow it's master through a zone doesn't work as well as before the MQ2Data version.
Some examples where it works intermitently; zoning from nro into oasis. PoK to North Freeport.
An example of not working at all; Zoning out of Nro LDoN's.
Finally, this is prolly more of a request as I don't see anything about this in the code; Is it possible for the bot to follow it's Master through the use of the LDoN Magus's? Perhaps have it watch the master for text used when in a zone with a Magus and use the same text, or perhaps /who the master till it sees the zone it went and use that if it wasn't near to see /say text? Just a thought.
Do me a favor and the next time you are zoning out of an LDON mission (get it from several different missions in Nro, Sro etc) and do a /doortarget before you are exiting out and post the name of the door that you see. It's likely doesn't have "port" or "tele" in its name, which is what I use for criteria for trying to zone.
As far as the magus thing is concerned I'd thought about this in the past but the problem is, the way that advpath is designed it is supposed to make it independant of standing right next to the person you are following. That's not to say that it isn't doable, but I'm not sure its worth it if it probably isn't going to work well. You have to be fairly close to someone to see the /say messages etc.
As far as the magus thing is concerned I'd thought about this in the past but the problem is, the way that advpath is designed it is supposed to make it independant of standing right next to the person you are following. That's not to say that it isn't doable, but I'm not sure its worth it if it probably isn't going to work well. You have to be fairly close to someone to see the /say messages etc.
Will do on the nro ldon door. It will prolly be tomorrow though.
As for the Magus's. How about; since the bot will follow the Master to the loc of where it last saw it, have it move to that point. That should be fairly close to the magus. Have it recognize if it's in a zone with a Magus in it. If so, instead of /doortarget, or if /doortarget comes up with a far away door, then do /target Magus. Then do the moveto code you have for the doors. Next evaluate /who mastername and scrape the zone name the master went to and put that in /say. Just a thought for the logic. That should maintain the location independence which you intended and I love.
As for the Magus's. How about; since the bot will follow the Master to the loc of where it last saw it, have it move to that point. That should be fairly close to the magus. Have it recognize if it's in a zone with a Magus in it. If so, instead of /doortarget, or if /doortarget comes up with a far away door, then do /target Magus. Then do the moveto code you have for the doors. Next evaluate /who mastername and scrape the zone name the master went to and put that in /say. Just a thought for the logic. That should maintain the location independence which you intended and I love.
Loose the quote on GotoFunc
ml2157,
Sweet macro. Been using it for a while with great pleasure.
Since the data change, it appears some of the var passing has changed as well. GotoFunction used to accept:
/call GotoFunction "-10.00 -200.00"
But now it doesn't, and gives you an error if you try. If you leave off the quotation marks it works fine, but the documentation states they are required. Might want to update the doco.
--Vexix
Sweet macro. Been using it for a while with great pleasure.
Since the data change, it appears some of the var passing has changed as well. GotoFunction used to accept:
/call GotoFunction "-10.00 -200.00"
But now it doesn't, and gives you an error if you try. If you leave off the quotation marks it works fine, but the documentation states they are required. Might want to update the doco.
--Vexix
Updated:
advpath.inc
generic mac file
generic waittilthere mac file
advpath.txt
Updated for new variable system.
Added "prtl" as a possible portal to look for when zoning out of ldon missions.
Fixed the RecordFunction calling method in the documentation.
Fixed the pattern: It now completely avoids the obstacle and door code. The reason for this is that you should be in an open location any when you are running this. What could happen before is if you chose too tight of radius to run and too many sides you would plot locations that are too close together and it throws off the obstacle code.
advpath.inc
generic mac file
generic waittilthere mac file
advpath.txt
Updated for new variable system.
Added "prtl" as a possible portal to look for when zoning out of ldon missions.
Fixed the RecordFunction calling method in the documentation.
Fixed the pattern: It now completely avoids the obstacle and door code. The reason for this is that you should be in an open location any when you are running this. What could happen before is if you chose too tight of radius to run and too many sides you would plot locations that are too close together and it throws off the obstacle code.