Controlling waypoint file sequence from one location

[rock5]

I don't think anyone has come up with this idea before but I thought of a super easy way to control the order you go through your waypoint files from one easy location.

The way it works is like this.

• 1. Set up all your waypoint files to load a variable of the same name as the file itself. The variable name can be anything but it will be easier to manage if you name it the same as the file. So if the waypoint file has my relog code with the "When_Finished" variable, eg. my survivalr5.xml then you would set it like so

  Code: Select all

  When_Finished = survivalr5

  Where you just load another file using loadPaths, for instance in your own mydaily1.xml file, you would use

  Code: Select all

  loadPaths(mydaily1)

  Note the absence of any quotes. These are variable not strings.
  
  Note: Optionally if you want to maintain the original sequence when not using my method then you can follow the variable with "or originalOption". Eg. If you originally follow survival with the AT minigame then, in survivalr5 you would change

  Code: Select all

  When_Finished = "at"

  to

  Code: Select all

  When_Finished = survivalr5 or "at"

  That means when you are not using my method then the variable survivalr5 will be nil so it will load AT as it did before.
  
  2. Once you have all of them set up, create a starting waypoint file where we will set up the sequence, lets call it starter.xml. At it's most simplest form it would look like this

  Code: Select all

  <?xml version="1.0" encoding="utf-8"?><waypoints>
  <onLoad>
  	daily1 = "survivalr5"
  	survivalr5 = "at"
  	at = "cleanbags"
  	cleanbags = "survivalnext"
  	survivalnext = "daily1"
      
  	loadPaths("daily1")
  </onLoad>
  </waypoints>

  In this example, after settings the variables it loads the daily waypoint file "daily1". At the end of the daily it has loadpaths(daily1). daily1 holds the file name survivalr5 so it is actually loading survivalr5. At the end of survival it loads AT, at the end of AT it loads "cleanbags" which might be a waypoint file that just chears the inventory maybe by mailing, selling and deleteing stuff. Cleanbags then loads survivalnext which is a file I created to change character in a separate file, then lastly it loads the first file again after changing character to repeat the chain again. So just to be clear how it works, daily1 = "survivalr5" means that survivalr5 will be loaded after daily1.
  
  This example loads the starter waypoint file only once to set the variables then loops through the files until finished. But this file can be as complex as you like. Lets say you want your main characters to do a different sequence of files than your alts. Here is a more slightly complex starter file

  Code: Select all

  <?xml version="1.0" encoding="utf-8"?><waypoints>
  <onLoad>
  	player:update()
  	if player.Name == "main1" or player.Name == "main2" or player.Name == "main3" then
  		-- Sequence for main character
  		harddaily = "survivalr5"
  		survivalr5 = "at"
  		at = "cleanbags"
  		cleanbags = "survivalnext"
  		survivalnext = "starter"
      
  		loadPaths("harddaily")
  	
  	else
  		-- Sequence for alternates
  		easydaily = "survivalr5"
  		survivalr5 = "at"
  		at = "goblins"
  		goblins = "cleanbags"
  		cleanbags = "survivalnext"
  		survivalnext = "starter"
      
  		loadPaths("easydaily")
  	end
  </onLoad>
  </waypoints>

  In this example notice we end the sequence by coming back to the starter file. This is so we can choose which sequence to use for each character.

I hope that was clear enough. The idea is simple though my explanation might be a bit long winded. Tell me what you think.

Disclaimer: The code is untested and in fact the idea itself is untested, though it should work in theory.

[Bill D Cat]

So in effect, you are scripting the scripting. You then only need to edit your starter file to make changes to the sequence you run through the files. Another benefit to making this look less bottish would be the ability to set up parallel sequences and use a random number generator to pick which to run next. Of course you'd have to have things set up correctly to move between the waypoint files in such a manner as to not go running off in a random direction looking a total fool. Starting/ending near a common transition point or a snoop position would be best to help chain them randomly.

[rock5]

I don't think I would ever randomize the sequence. Maybe have more than 1 path and then randomize which path to take might be a better idea. Or maybe have more than 1 set sequence that you know will work then randomize which one to do. But then I never did used to use randomization.

[Bill D Cat]

Well I figured one day it would run Malatina, Andor, then travel off to do Ancient Treasure before coming back to Lyliya. And another day it might reverse the order. The common starting and ending point would be in Varanas Central, so it would transition between any of the various mini-games smoothly. Something like this perhaps.

Code: Select all

<onLoad>
   math.randomseed(os.time())
   pickpath = math.random(1,2)
   if pickpath == 1 then
     daily1 = "survivalr5"
     survivalr5 = "at"
     at = "cleanbags"
     cleanbags = "survivalnext"
     survivalnext = "daily1"
   elseif pickpath == 2 then
     daily1 = "at"
     at = "survivalr5"
     suvivalr5 = "cleanbags"
     cleanbags = "survivalnext"
     survivalnext = "daily1"
   end
   loadPaths("daily1")
</onLoad>

[beanybabe]

I was going to work on something for these. a year or 2 ago it seems someone had completed a wp that did them and ran a daily for tokens also but I forget who or what it was called.

[rock5]

I think there was but that would have been just using the existing bot features, ie. a loading b, b loading c, c loading d, etc. This post is about a way to control the sequence of any files from 1 location. It's not about minigames or any particular waypoints. You can use this method to chain any sequence of waypoint files and easily manage the sequence from 1 location.

[beanybabe]

Why do lylia unless you want the furniture. The only ones worth doing are survival cot and at. Just trash everything but badges, iv runes, charges and mats. Since there are all by close the random idea for cot and survival might be good.

[beanybabe]

I see like the world traveler but made to control waypoints. I did something much simpler but it got to hard to manage. Were I put variables in each wp that controlled features in profile. eg: a variable to make rogue not hide or make warlock not cast agro spells.

[beanybabe]

This may be a like idea. I was looking at making one character that I would set at a mail box and it could sent money and items out to others and change what they do depending on feedback from them. If you could get what your are thinking so its simple to implement that may work for me on this idea.

What you are thinking just seems a bit to much. its hard to know every variable. you would need go get stat calculations weapons skills and take that all into account. Each wp has special needs, also some only work with one class so you need way to get feedback from the waypoints to the controller for it to adjust its thinking.

I often think of making micromacro on a shared drive on the lan so all the log files are visable to each machine. The problem being if 2 try to update the same log data might be lost. This would allow a common log to be used to control all the other pc thinking.

[dx876234]

I've been using something similar to call/chain waypoints. I made a userfunction which implemented a stack and a few operations on the stack 'wpcall', 'wpchain' and 'wpreturn'.

The wpreturn will pops the waypoint on the top of the stack, else exit the waypoint if stack is empty.

The wpchain('waypoint1', 'waypoint2', 'waypoint3') pushes the waypoints on the stack and calls the topmost (waypoint1), as it does ' 'wpreturn' the next ones will get called until stack is empty.

And finally the wpcall is basically a wpchain with a single argument.

-dx

[beanybabe]

I was thinking of more automating things and what you say is making me think. Can you also add a time factor to check if a wp runs longer than it should and abort it?

[rock5]

You would have to do that inside the waypoint file you want to time. Set a start time in the onload then every now and then check the time elapsed. When it passes your desired time then take whatever steps you want.

[beanybabe]

Just has idea. I was thinking of putting number of waypoints in a folder. they need something like your thinking so depending on level and class it can make changes and choices.

But I got to thinking what if each wp had a chunk of data that could be read that said what level and other qualifications were needed for it such as ranged attack or healing needed etc. In stead of having 1 program that had all the data you just scan the folder for paths you char is able to run.

[noobbotter]

I like the idea of a timer on waypoints because sometimes, I haven't figured out why, a bot will get stuck inside AT at the point where they are supposed to click the candlestick. I've tried everything I could think of to double check that the candlestick is clicked to transport out, but for some reason, it doesn't fix the problem. The bot thinks the candlestick is clicked and that the "Yes, transport me out" button was clicked. If I manually see what happened, I can manually click it and transport out and the waypoint resumes where it should be. A timer would help resolve issues like that.

Is there any kind of function such as onWaypointLoaded()? If there was a way to know when a waypoint gets loaded, you could put that into a userfunction to keep track of time. And possibly even have set time limits for your different waypoints and different actions to take if one gets stuck or takes too long.

[rock5]

The main problem is if it's stuck in a loop, such as you described, then there is no way to force that loop to end. So even if you timed the waypoint from a timer that runs concurrently, there is nothing you can do to fix the problem. You can't load another waypoint file, well you can but it wont get run because it has to exit that loop first.

[noobbotter]

So because it's stuck in a loop, having something in even a userfunction wouldn't work because the MM is stuck in that loop. So literally, the only way to detect being stuck in a loop would be to have a separate MM window running a script specifically to watch for being stuck, such as character.X & character.Y not changing for more than 10 minutes = player is stuck. I wonder if I could make something like that? I'd hate to have 2 separate MM windows running for each bot, but seeings as I only run 1 at a time, it's feasable. The problem might be figuring out how to have the detection MM window stop execution of the other and how to resume after unsticking. Something to think about.

[rock5]

Well from a separate mm window you could close the other mm window and restart a new one. Trying to figure out which waypoint file you were using and how to resume where you left off would be tricky though.

[noobbotter]

I didn't mean to hijack this thread so I started a new one (http://solarstrike.net/phpBB3/viewtopic.php?f=21&t=6103). Feel free to resume relevant discussions here about Rock5's Controlling Waypoint function.

[Celesteria]

hi rock5,

this way sounds nice but it has a problem if your client crashes. so it has to start again from beginning or if you start the last waypoint file you dont have the variables filled.

i am using another way to handle my chars which are also handled from within one start file. i create a table of the waypoint files and save it to a file. now i commented out all checkRelog-functions from the waypoint files and use my own checkRelog () which is located in an userfunction (to be available to every script). the function loads the waypoint table, kills the first line and saves it again. if the table is empty it loads the next char. so i allways can start a client after a crash using my start file or continuing the last waypoint file that was loaded.

hope my explanation is understandable


greetings
Celesteria

[rock5]

It sounds good and there are definitely more thorough ways of doing it than I showed but a benefit of it is it's dead simple so even noobs can use it. Although not being able to restart is a serious flaw.

Maybe you should make an easy to use userfunction and share it?