Elven Island - All Zone Quests

[Bill D Cat]

Looks like my Yrvandis Hollows waypoints will be delayed indefinitely. My hard drive took a dive and will no longer boot my computer. I'm in the process of replacing it, and hopefully I can use it as a slave drive to recover the data, but no promises. Worst case I'll just re-create the whole thing, and probably even improve on it since I know where all the problematic quests are now.

Wish me luck!

[y2krazy]

Looks like my Yrvandis Hollows waypoints will be delayed indefinitely. My hard drive took a dive and will no longer boot my computer. I'm in the process of replacing it, and hopefully I can use it as a slave drive to recover the data, but no promises. Worst case I'll just re-create the whole thing, and probably even improve on it since I know where all the problematic quests are now.

Wish me luck!

That suuuuuuuuucks. T.T

Sorry for your loss, Bill. Looking forward to the improved scripts, however long they may take.

[Braziliano]

testing yer scripts matey , will keep u updated

[Bill D Cat]

Update for Yrvandis Hollows: I've recreated the first of three waypoint files for this zone and have reduced the overall runtime from 65 minutes to just under 45 minutes. This first file will handle all the quests in and around Morfantas City, and should get your character to level 7 by the time it is done.

I'm working on the second waypoint file now, which will finish all the remaining zone quests up to the point that you enter the instance. The third waypoint file will attempt to solo the instance and complete the remaining zone quests before taking you back to Snoop and ending. I didn't want to actually transport to Varanas yet, as the individual player may decide to pick up their second class before leaving the zone.

I hope to have the second file complete by this weekend, and the third sometime next week. Hopefully this time I'll have better luck with the elite at the end of the instance.

[y2krazy]

Update for Yrvandis Hollows: I've recreated the first of three waypoint files for this zone and have reduced the overall runtime from 65 minutes to just under 45 minutes. This first file will handle all the quests in and around Morfantas City, and should get your character to level 7 by the time it is done.

I'm working on the second waypoint file now, which will finish all the remaining zone quests up to the point that you enter the instance. The third waypoint file will attempt to solo the instance and complete the remaining zone quests before taking you back to Snoop and ending. I didn't want to actually transport to Varanas yet, as the individual player may decide to pick up their second class before leaving the zone.

I hope to have the second file complete by this weekend, and the third sometime next week. Hopefully this time I'll have better luck with the elite at the end of the instance.

Sweet! Looking forward to testing it out, Bill!!

[Bill D Cat]

I always feel like I can do something better the second (or third) time I try. So far that's been true for my rewrite of this set of waypoints. I've customized a few more functions, dropped the requirement for userfunction_profilechange and enhanced my own userfunction_questHelpers. So far, I've recreated the EI_01_InTheValley.xml file and managed to streamline it enough to cut the runtime from 45-50 minutes down to 35 minutes. I'll be working on the second file over the next few days and hope to have all three done by the weekend. And as requested, I've made much better use of the player:mount() calls in the waypoint file.

Stay tuned for further updates.

[Bill D Cat]

Just finished the rewrite of EI_02_SporeGrove.xml and optimized a lot of the quests. Runtime is also reduced from 45 minutes to 35 minutes. Starting work on EI_03_SabineanCave next. Having the new features in createpath.lua has really helped this process.

[Bill D Cat]

Just completed some extensive testing of my rewrite, and have all three files ready to go. Is there any interest in me updating these files, or is everyone happy with the originals? The new files use my userfunction_questHelpers file and can complete the entire zone in just under 2 hours. I've streamlined a lot of the combat, and removed all the points in the original waypoints that had the potential to cause your character to get stuck.

[noobbotter]

I never do elves but I might just to check this out.

By the way, I don't know if you're interested or not, But when I was writing some leveling scripts for Coast of Opportunity (only got from 30 to 33), I had created a way where it would create a log for each bot and the only thing in the log file would be the name of the waypoint file it was working on, the waypoint tag name of where it had left off, and the travel method being used. That came in real handy because I was able to stop the bot and I could easily resume him another day and he would continue where he left off (as long as I stopped him at accepting or completing a quest, or wherever else I set a save point).

I took the code that did the logging and stripped out most everything else and thought I'd share it here. It might come in handy. Maybe it will spark your imagination on how you could build in savepoints into your waypoint series that you are putting together.

The files I'm attaching are stripped down but if you want to see what I had for lvl 30 thru 33, which is where I stopped, let me know.

[Bill D Cat]

I can see this easily evolving into a userfunction. I will take a more detailed look at it when I get home from work and see if I can incorporate it into my questHelpers file. There are a few ideas that come to mind on how I can make use of this in my longer waypoint files.

[rock5]

What if we added the feature to the bot? Maybe we could resume a character with

Code: Select all

rom/bot path:resume

[Bill D Cat]

For waypoints such as mini-games inside an instance, this would not really be a feasible option.

For all other "open-world" waypoints this could prove to be a useful feature. We would have to come up with a command to insert into a waypoint to record the appropriate data for retrieval later. This sounds to me like the perfect time to consider replacing the mouse-click option in createpath.

Then the bot could look for the log, and if found it would read the data and resume the appropriate waypoint file. I think having only one resume point per character would be acceptable, since you probably won't be in a location in the game to resume a different waypoint than the one you last aborted. You could even edit the resume file and change the waypoint index if you wanted to start at a different point than the last one recorded. This would be similar to editing the start of the waypoint file and changing/adding the __WPL:setWaypointIndex(X) value in the onload section. But at least this way you won't have to edit the waypoint itself, and risk another character running off at random looking for that start point when they should be starting at the beginning.

If the bot doesn't find a resume log, then it just executes the waypoint file from the beginning.

It would then be up to the person who created the waypoint to enter the appropriate command at key places in the file so that it could be resumed. Of course, anyone else would still have the ability to manually edit the file and add the command themselves where they might need it. Adding the command to createpath would at least make it easier to implement the feature going forward.

We'd also need a command to clear the log for the waypoint. No point in finishing the whole thing just to have a resume point that points at the end of the file. I'm not sure if it would be a safe option to just have loadPaths() clear it, but it would be something to look into. This way chaining from one waypoint to another would clear the previous saved data and not try to execute the previous file on the resume.

[rock5]

For waypoints such as mini-games inside an instance, this would not really be a feasible option.

Well I was thinking it should check how far the resume point is and if it is too far then it should revert to going to the closest waypoint as usual. This would also handle if you moved the character manually out of the area. And there is still a need to record resume points in an instance. What if you restart the script while in the instance? You'd still want it to resume from the last waypoint.

We would have to come up with a command to insert into a waypoint to record the appropriate data for retrieval later.

I was thinking it could just automatically record the info at every waypoint. Saves users having to add a command and is useful with existing waypoint files too.

We'd also need a command to clear the log for the waypoint.

I'm not sure about that. If a file ends with an error command then resuming shouldn't restart that file. If you want to restart the file then you wouldn't resume. Lets say you have 3 chained waypoint files and the last one ends with an error command. If you have to stop it halve way through wp 2 then you can resume it and it should continue where it left off in wp 2. If it reaches the end of wp 3 then ends what would you expect it to do if you try to resume? Next day you would restart the waypoints by starting the first wp file again at which point it will start recording the resume point again.

[Bill D Cat]

What if you restart the script while in the instance? You'd still want it to resume from the last waypoint.

Possibly. But some of the mini-game waypoint files execute almost everything inside the onload section, and there wouldn't be a waypoint to move to in those cases. A waypoint file for other instances like DoD or Goblins would benefit from this.

As for the clear command, I think I was envisioning a system that only recorded waypoints at programmed points. That's why I thought the clear command might be useful. Something like the following scenario:

Waypoint file #1 has save points entered every 10 waypoints. At the end it chains into waypoint file #2 via loadPaths() and that file saves the waypoint data every 20 waypoints. If waypoint file #2 was aborted before it's first save, then a resume would reload waypoint #1. That's why I was thinking loadPaths() might be useful in clearing or updating the data.

But if you can record the data each waypoint automatically behind the scenes in the bot without the need for specific commands in the waypoint file, then the need for a clear command is nullified. The question then becomes, how often do you write that save data to a file on the hard drive? Updating the file at every waypoint might cause a lot of disk activity, and buffering the data beyond two or three points could end up loosing the most recent data if the waypoint is interrupted via CTRL-L or some other error that causes the bot itself to abort.

[rock5]

Possibly. But some of the mini-game waypoint files execute almost everything inside the onload section, and there wouldn't be a waypoint to move to in those cases.

True but lets think this through. Most of the mini games do have some waypoints from which they can resume from such as survival and cot. AT is one that doesn't have any waypoints. Lets see, if you are in AT and try to resume and the last waypoint visited was a waypoint outside the game, you can't go to that waypoint. In this case you would want it to reload AT. Also if you start with AT then there wont be any previous waypoint. In this case if you resume you would also want to restart AT. I think when a waypoint file is loaded it should become the resume file at that point. If there are no waypoints then when you resume it should just start the file as usual.

The question then becomes, how often do you write that save data to a file on the hard drive? Updating the file at every waypoint might cause a lot of disk activity, and buffering the data beyond two or three points could end up loosing the most recent data if the waypoint is interrupted via CTRL-L or some other error that causes the bot itself to abort.

I can't be bothered timing a file write at the moment but how long it takes will probably depend on how complex the save function is. We could use the exit callback but I don't believe it executes on all errors. With just a bit of testing, I've only been able to trigger it when pressing Ctrl-L after pressing Del to pause the script. I might ask Administrator what exactly is the purpose of the exit callback.

Edit: Forgot about aterror callback. That would handle the other errors.

[noobbotter]

Another thing you could consider is the idea of a different logfile for each waypoint. This would allow you to stop one waypoint, go do something else, run your minigame waypoints or whatever, then resume the first waypoint. This could easily be done by using the waypoint filename in the log filename. Naming each logifile something along the lines of player.Name.."-"..waypointfilename (don't know how to automatically retrieve the waypoint file name that's currently running).

[Edited] - I was just thinking... maybe a different logfile for each waypoint wouldn't be the best. For instance, When I run my bots through their dailies, minigames, mail items, clean out bags, etc..., it runs through several different waypoint files through the process. A single logfile would allow me to resume where I left off if there were issues or had to stop for some reason fairly easily. If there was a different logfile for each waypoint, then there wouldn't be an easy way to know where exactly I left off.


Either way, I'm glad to see I got the gears turning with what could be done with this.

I was thinking about this more last night when I was running a new character through the Elven Island scripts. After it hit about lvl 6, I had to stop for the night and was thinking it would be nice to be able to resume where I left off, though I didn't look at the code to see if it would resume at the nearest waypoint or if it forces it to start at the beginning.

Also wondering, does the Elven Island file run fine if you don't sit there and manually upgrade the skill levels upon level up? Also, Is there an easy way to have the bot automatically add new skills as they become available? I know you can level up skills in the onLevelUp section of the profile, but does anyone have the code already done that would check for new skills and when available, assign them to a keyboard number? That would be handy for lower-level leveling waypoints. Of course, it would be different for each class so I don't know how you'd do that.


[Edited] - I just saw your UserDefault.xml file in the Yrvandis Hollows posting and it looks like that may have answered my question about leveling up skills. I have always been using specific keyboard settings for the skills (eg, VK_1, VK_2, VK_3, etc...) and have never tried keeping it set as "MACRO". But looking at the skills in your default new bot profile, we are able to put in the skills we want that bot to use, even if they don't have them yet? That will sure save me some time.

[rock5]

If there was a different logfile for each waypoint, then there wouldn't be an easy way to know where exactly I left off.

Exactly what I was going to say. The main idea behind the resume feature is, if you stop and don't know or forget which file you are up to, you can just resume the last file.

[Bill D Cat]

I was thinking about this more last night when I was running a new character through the Elven Island scripts. After it hit about lvl 6, I had to stop for the night and was thinking it would be nice to be able to resume where I left off, though I didn't look at the code to see if it would resume at the nearest waypoint or if it forces it to start at the beginning.

If you have to stop the Elven Island scripts, just make note of which waypoint you were at. Then you can edit the file and change the command in the onload section to that waypoint number. It should resume from where you left off when you restart it. This discussion that you've helped start will make it possible to just restart the waypoint at that point without needing to edit the file.

Also wondering, does the Elven Island file run fine if you don't sit there and manually upgrade the skill levels upon level up? Also, Is there an easy way to have the bot automatically add new skills as they become available? I know you can level up skills in the onLevelUp section of the profile, but does anyone have the code already done that would check for new skills and when available, assign them to a keyboard number? That would be handy for lower-level leveling waypoints. Of course, it would be different for each class so I don't know how you'd do that.

[Edited] - I just saw your UserDefault.xml file in the Yrvandis Hollows posting and it looks like that may have answered my question about leveling up skills. I have always been using specific keyboard settings for the skills (eg, VK_1, VK_2, VK_3, etc...) and have never tried keeping it set as "MACRO". But looking at the skills in your default new bot profile, we are able to put in the skills we want that bot to use, even if they don't have them yet? That will sure save me some time.

The basic skills are leveled up for you with the levelupSkills1To10() command. But keep in mind, only skills that you get between level 1 and 10 that are not AOE based will be leveled up with this option. Any other skills you would have to include in the onLevelup yourself. The only caveat there is that you don't try to level ALL your skills up to your current character level, because you most likely will not have enough talent points to do so. You can add any/all of the skills you want to your character's profile, including elite skills. Start with the UserDefault file and customize it for each character, saving the new copy under each character's name as needed.

[Bill D Cat]

Updated the first post with new files for this waypoint series. The original file is still there if anyone is still running an older version of the bot that doesn't have the updates to getTEXT() and GetIdName().

[rock5]

I'm a bit preoccupied at the moment so I'm not sure when I can work on this idea but let me pose a question; how will we save the data, in one file or many?

If we save a file per character, then for users who have a lot of characters, it could mean a mess of files. Of course we could put them them in their own subfolder, maybe as a subfolder of 'logs'. The advantages of this is quick and easy file writes and reads.

If we have one file it would be tidier but the disadvantages are the problems with editing a file (you would have to load the whole file, edit it and then save the whole file again) and the possibility that more than one client will try to access the file at the same time.