Elven Island - All Zone Quests

[Bill D Cat]

I'd opt for using /logs/charname/resume.xml (or whatever file format you decide on) to store the data. While there will be more directories and files this way, it is a lot safer if you are running multiple clients at one time.

[rock5]

That would still clutter the log folder with files. I was thinking of just naming the files differently and put them in one folder, eg.
/logs/resumes/charname.txt

[noobbotter]

I would agree that it would be best to have all the resume files in one place, eg. /logs/resumes/charname.txt

I think it would be nice if you were able to first, create a profile option like:

Code: Select all

<option name="RESUME"         value="true" /> -- true or false: true will allow resumes. false will turn off resume functionality.

That would allow you to set that profile option either for specific bots, or even in specific waypoints that you don't want any resume capability, you could simply set that profile option in the onload section to false.

Then during the onload section it would check the resumes setting in the profile and if resumes == true then it would open the logfile and compare the waypoint filename in the log against the currently running waypoint. If it's the same, it would resume at the waypoint it left off on. If the waypoint file is different than what's indicated in the log, then it would start at the beginning and overwrite what's currently in the logfile.

Like you mentioned, I don't know how much overhead it would case by updating that logfile for every waypoint, but that would be the easiest way to do it. If there were a way to have the code execute at the beginning of each waypoint automatically to update the logfile, then the whole resume function would practically be in the background.

[rock5]

I think it would be nice if you were able to first, create a profile option like:

Code: Select all

<option name="RESUME"         value="true" /> -- true or false: true will allow resumes. false will turn off resume functionality.

I thought of this too but what should the default value be? Should users be able to resume by default or do they have to set the options first?

Then during the onload section it would check the resumes setting in the profile and if resumes == true then it would open the logfile and compare the waypoint filename in the log against the currently running waypoint. If it's the same, it would resume at the waypoint it left off on. If the waypoint file is different than what's indicated in the log, then it would start at the beginning and overwrite what's currently in the logfile.

I'm not sure I completely follow this in the context of how we are saying it should work. The way we are saying it should work is, if you are running a chain of waypoints and MM crashes or you have to stop them part way through, you can just resume without having to know which file you were up to.

Code: Select all

rom/bot path:resume

When you resume there is no current waypoint file already loaded. If there is an entry in the log for that character then it loads that waypoint file and sets the waypoint number and continues where it left off. If you start a file as normal it still starts from the start (or closest waypoint) as usual. So the way the option would work is, if it is on then it saves the resume points, if it's off it doesn't. If you want only certain characters to save resume points then you would put the option in the profile. If you want resume to work for a particularly long and convoluted waypoint file you would put the option in the waypoint onload.

Like you mentioned, I don't know how much overhead it would case by updating that logfile for every waypoint, but that would be the easiest way to do it. If there were a way to have the code execute at the beginning of each waypoint automatically to update the logfile, then the whole resume function would practically be in the background.

That's the plan. Without an option it would be completely in the background. With the option, we have to decide how it's going to work. We could still decide to not have an option. We'll see.

[Bill D Cat]

Any progress in the planning/development of this feature? If not, I may take a look into what it takes to get it working this weekend.

[rock5]

Thanks for reminding me. Let me recap the plan for this feature as I see it.

If you have the "resume" option set then it records the file name and waypoint for that character in a file called something like logs\resumes\charname.log

You set the option in the profile like this

Code: Select all

<option name="RESUME"         value="true" /> -- true or false: true will allow resumes. false will turn off resume functionality.

or in the waypoint file onload like this

Code: Select all

settings.profile.options.RESUME = true

If you want to resume from where you left off you would start the bot like this

Code: Select all

rom/bot path:resume

I may also have to add a resume option in the waypoint list.

When it resumes it loads the waypoint file sets the resume waypoint then runs the onload, at which point it resumes where it left off. Of course this means that any waypoint files that set the way point in the onload will overwrite the resume way point. Can't help that. That's probably bad coding practice anyway. Waypoint files shouldn't force it to start at a particular way point because then you can't resume in the middle of a file, with or without this feature.

2 questions come to mind, both regarding the option.

• 1. The option RESUME is deceptive. It implies that it will resume if set to true but all it does is enable the option. Maybe it should be RESUME_ENABLE or ENABLE_RESUME.
  2. I still don't know what the default value should be. Probably the best thing to do is get it working first and if it has a very small overhead I can enable it by default, otherwise I will disable it by default.

Then the question arises, if the overhead is so small that I make the default true then why have an option at all? Why not just have it on all the time? I'll see how it goes.

[rock5]

I added the feature to revision 771 of the bot.
http://www.solarstrike.net/phpBB3/viewt ... 653#p55653

I was happy how it was working with no options so I didn't include any options. It's always on.

[Bill D Cat]

Just updated to 771 and when I use the default menu system and select a subdirectory to pick a waypoint file to run, option 1 inside the subdirectory is always blank. Trying to select that option results in the error:

scripts\rom/bot.lua:550: attempt to concatenate field 'folder' (a nil value)

[rock5]

Ok, missed that. At least it's nothing serious. It will be fixed the next time I commit.

[rock5]

I've started sending some alts through this waypoint file, as a quick way to level. So far I've done 3 with more to follow. Here are some of my observations in no particular order.

• 1. This first one is not a bug with these files. Hasn't anyone else had CompleteQuestByName failures when specifying a reward? What's happening with me is, it successfully completes the quest and gets the reward but then it tries to open it again and ends up showing the static popup with the rewards. I had to add a larger pause in the CompleteQuestByName function to give it time to be "complete" so it didn't try to complete it twice.
  
  2. Because of the above, I sometimes had to restart at one of these quests where the reward was an earring. Because it had already equipped the earring, it got a "item is nil" error. It need to test if item exists before equipping. Granted, this only happens if you restart the script, but still...
  
  3. It consistently failed to catch the crab. I saw messages saying "out of range" and "can't see target" before it eventually attacked and killed the crab. I think it's because the crab is too deep. player:moveTo does go to targets in a 3D environment but, because the angle is shallow, it goes along the surface of the water instead of going down to the crab. A quick fix would be to use teleport and teleport down to the crab before using the item but that would require another userfunction. Or maybe it could use a different more accessible crab.
  
  4. it sometimes attacks, or attempts to attack, the frogs when collecting slips. I'm not sure why it attacks. It looks like it clears the target then spams attack skills in the MM window until it gives up. Occasionally it actually does target and attack the frogs.
  
  5. A couple of times it got stuck at the jug. The casting bar didn't clear. I had to do a /script ReloadUI() to clear it and then it happened again on the next character. It didn't happen on the third character after I restarted the client so maybe it was a one-off.
  
  6. Didn't equip Guardian's Glory Cape.
  
  7. A few times I came back and found it stopped at an npc because somewhere far back it failed to complete or accept some other quest. This makes it very difficult to get it going again because it may have completed other quests along the way. I think, in a waypoint file like this, failures to complete or accept quests are catastrophic so steps should be taken. It's too long a script to have loops that repeat until a quest is complete because there are so many quests but maybe you could have custom accept and complete functions that stop if they fail. That way if you come back to it and find it stopped, you only need to make minimal repairs before resuming.

I'll let you know whatever else I discover. I can also share my solutions if you like.

[noobbotter]

There are 2 or 3 sticky spots for me that I've seen the bot commonly get stuck at. One might be where you were talking about with the item is nil error. Around waypoint 70 or 71 it sometimes will fail to accept or complete a quest and then I have to go back and figure out where the first thing it missed was and try resuming from there.

Another one is the spot where it has to click on mounds of dirt and then water the plants when they grow. Sometimes the quest will get to a complete state and the bot gets stuck sitting there not doing anything. If I manually click on a mound, it will then see that the quest is complete and continue as it should.

Once or twice I've seen it get stuck at the fruit basket.


One note of what I have my bot do to save me some time... I've edited my copy of EI_02_SporeGrove.xml. Once my bot gets to waypoint #87 and turns in the Thunderbolt Pet quest, I have him mount up and travel back and do the Helping Them Grow dailies. Once those dailies are complete, he should be level 10, at which point it will travel to Varanas and get the transmutor. It seems to go a lot quicker to get to lvl 10 that way than to continue with the questline.

[rock5]

I'm getting so close to having a clean run through. I think the last one only failed once. That was my 6th character through. Hopefully by the end of today I will have a clean run. Then maybe I will share my edits.

Another one is the spot where it has to click on mounds of dirt and then water the plants when they grow. Sometimes the quest will get to a complete state and the bot gets stuck sitting there not doing anything. If I manually click on a mound, it will then see that the quest is complete and continue as it should.

Once or twice I've seen it get stuck at the fruit basket.

I've never had it fail at either of these quests.


I wish there was a Silverspring set of waypoints so I could keep leveling. Can't be bothered making it myself.

[Bill D Cat]

I wish there was a Silverspring set of waypoints so I could keep leveling. Can't be bothered making it myself.

Shhh! I'm working on it already... But that's for another topic.

[rock5]

Cool. Hopefully it will be ready by the time I've run all my alts through this script.

Are you going to make it so, regardless of which of your beginning scripts are used, it can do the Silverspring one? Or maybe the user (or you) can make some short linking waypoints.

[Bill D Cat]

I've got it set to it checks to see if you are near the elven transporter (Elf), in the class hall (Human), or still in Yrvandis Hollows (Dwarf), and branches accordingly thru a short starter waypoint.

As Elf or Dwarf you are taken briefly into Howling Mountains to do Lola's Epic quest series so that it can continue in Silverspring. All three classes will then converge at the Varanas Bridge to do the "Tour of Varanas" chain and then start out into the rest of the zone to try and get the Silverspring armor set and get ready for FA/BG.

[rock5]

You could also use the players race.

Code: Select all

if player.Race == RACE_HUMAN then
   ...
elseif player.Race == RACE_ELF then
   ...
else -- must be dwarf
   ...
end

[Bill D Cat]

I do both, just to be sure that the player is in the appropriate starting area so that I don't have them running off into walls or something. If you chain into the Silverspring waypoints right after one of the three starting area series, then there is no problem. But if, for example, you've finished the Elven zone and then manually moved into the class hall to pick a second class and try to start from there, then I have to account for you no longer being by the Elven Airship Operator.

[rock5]

Didn't get a chance to run any alts through yesterday because of the maintenance. I'm running one through now. Damn, it stopped at another quest. Getting closer to a clean run though.

2 things I wanted to bring up before I share my version.

• 1. There have been various versions of these files but there is no version information. Maybe it would be a good idea to start giving the files version numbers so users know if they need to update. Should I give my version a number?
  
  2. The same userfunction file is posted at each of your starter script threads right? That means if you have to update it you have to update all the places you have posted it right? Maybe because you intend these functions to be useful for users to use in other scripts, you could post it to it's own topic and use links to them in these threads. I ask this because I'll be proposing some changes to it and that would simplify things.

[Bill D Cat]

• 1. There have been various versions of these files but there is no version information. Maybe it would be a good idea to start giving the files version numbers so users know if they need to update. Should I give my version a number?

That's probably a good idea. I hadn't initially intended to keep updating these, as the zones aren't likely to change at all. The only changes I've noticed are the appearance of holiday decorations in Logar depending on the current patch. I've tried to avoid moving through the areas where they normally appear, but I haven't had the files released for a full year to run through every holiday event.

• 2. The same userfunction file is posted at each of your starter script threads right? That means if you have to update it you have to update all the places you have posted it right? Maybe because you intend these functions to be useful for users to use in other scripts, you could post it to it's own topic and use links to them in these threads. I ask this because I'll be proposing some changes to it and that would simplify things.

May as well make a separate topic for it. That way anyone else who may want to contribute to it can do so.

[rock5]

I hadn't initially intended to keep updating these, as the zones aren't likely to change at all.

True but there are always the possibility of small improvements and tweaks to performance.