loadPaths() enhancement idea

[Bill D Cat]

I'm not sure if this will even be worth adding to the bot, but I can see a few cases where it might actually be useful. I was thinking of adding an optional third arg to the loadPaths() function that would contain either the waypoint number or a waypoint tag to resume at. If this option is used, then the return path could then become the name of the calling waypoint file to return to when finished. Leaving the third arg out of the calling command would just act as it currently is designed and won't break any existing waypoint files. So I think adding it could only be a benefit in the cases you need it.

Here's how I envision it working. I could create a long zone waypoint file like Elven Island, and in the middle of it I might want to branch to do a daily quest in another stand alone waypoint file. When I'm done with that, I would want to return to the first waypoint file and resume where I left off. What I'm thinking of is something like this.

First file:

Code: Select all

<waypoint x="123" z="456" y="789">
     loadPaths("MyDaily.xml","FirstWaypointName","DailyDone")
</waypoint>
<waypoint x="123" z="456" y="789" tag="DailyDone">
     resume the original waypoint file here...
</waypoint>

Second file: (MyDaily.xml)

Code: Select all

<waypoint x="234" z="567" y="890">
     do something here...
</waypoint>
<waypoint x="123" z="456" y="789">
     loadPaths("FirstWaypointNamel",nil,"DailyDone")
</waypoint>

[lisa]

I split up the other replies into a new topic, they were very off topic in my opinion.

[lisa]

Ok now for the topic at hand, I think an argument to say which TAG to start at would be ok and shouldn't be too hard to implement, the only real issue would be that waypoints are at the core of the bot and so it could cause many issues or it might not cause any issues at all.

Now for the part about which waypoint to do after that has run it's course that is an entirely new kettle of fish. The bot currently runs waypoints in an endless loop, when it gets to the last waypoint it goes back to the first and carries on, this has been the way it has worked for an extremely long time. To do what you want there would have to be a way to tell the bot the waypoint has finished and to go do something else, which loadpaths currently does.

So I don't think changing loadpaths to do this is the key.

If I understand you correctly you want to be able to tell the bot which files to load outside of the actual waypoint, maybe depending on the character, maybe depending on the class or account.
If it is dependant on character then you could use profile to tell the bot what to do.

Something along these lines.

pathingtable = {cot ="at",at="gotoheff",gotoheff="heffdaily",heffdaily="cot"}

in another profile you might have
pathingtable = {cot ="gotoheff",gotoheff="heffdaily",heffdaily="cot"}

then in the cot.xml when it is time to go to next waypoint do
loadPaths(pathingtable.cot)
so 1 profile would then load at.xml but the other would load gotohef.xml


As for when you crash and want to continue on from where you left off, Rock did a lot of work on that stuff, he would be best to comment about what bot currently does and ways to use that or improve it.

[lisa]

reading that again I think half my answer was for questions asked in the split up posts.

Anyway something you could try is to set the resume point when you do the load path.

Code: Select all

__WPL.ResumePoint = 22
loadPaths("FirstWaypointNamel")

not sure if there is an easy function to find the tag, there probably is but it would look in current wp file as opposed to the loaded wp file.

[Bill D Cat]

That's why I was thinking that a modification to the loadPaths function would work. It already checks for a resume point in the logs folder, and does the nearest waypoint comparison if it needs it. Adding another check for the waypoint tag should be possible without breaking existing files.

[rock5]

I was thinking of adding an optional third arg to the loadPaths() function that would contain either the waypoint number or a waypoint tag to resume at.

Even though it might be easy to implement, I'm not sure I like the idea. It seems to me you are saying, normally the "second file" will start from the closest waypoint but when coming from the "first file" you want it to start from the DailyDone tag. But the thing I don't like its it returns to the "First file" regardless. So to me that doesn't really make sense. If the "second file" is only meant to be used with the "first file" then you can add code in the onload to make it start from the correct waypoint as usual. Maybe I'm missing something. I haven't read the split posts yet.

Something along these lines.

pathingtable = {cot ="at",at="gotoheff",gotoheff="heffdaily",heffdaily="cot"}

in another profile you might have
pathingtable = {cot ="gotoheff",gotoheff="heffdaily",heffdaily="cot"}

That's a great idea. It's sort of like a more compact version of the idea I posted about controling the order of waypoint files.

As for when you crash and want to continue on from where you left off, Rock did a lot of work on that stuff, he would be best to comment about what bot currently does and ways to use that or improve it.

I suspect something was asked about this in one of the split posts. I'll answer it when I see it.

not sure if there is an easy function to find the tag, there probably is but it would look in current wp file as opposed to the loaded wp file.

I'm not sure but you might be able to set the waypoint number after loading the file, eg.

Code: Select all

loadPaths("FirstWaypointNamel")
__WPL:setWaypointIndex(__WPL:findWaypointTag("TagName"))

[Bill D Cat]

What I had envisioned doing was creating a full zone quest chain like Coast of Opportunity. During the course of this waypoint, I was thinking of branching off at certain points based on the character's level and running a daily quest from a stand-alone waypoint file. Once that quest was done, it would return to the point in the main waypoint file that it left off. In this case at the specified tag or waypoint number. Then it could continue on doing the normal quests without missing any because the file started over at the nearest waypoint which may not be the right one when doing the full zone run.

So this was supposed to be more like a GOSUB / RETURN kinda thing. The daily quests would be in separate files so if you wanted to only run those, you would not have to run the full zone waypoint. But the more that I think about it, the more I'm inclined to scrap the whole idea in favor of beanybabe's idea of just making the daily quests into functions. I can compile all the daily quests for a particular zone into one file and just call any of them from the main waypoint as a function. This would do exactly what I want, and allow me to resume the main quest chain when the daily was complete.