771 Changelog

For changelogs and discussion related to a specific revision.
Post Reply
Message
Author
User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

771 Changelog

#1 Post by rock5 » Mon Jan 27, 2014 12:09 am

- Added feature to resume last waypoint file.
  • Every time the waypoint number changes it updates a file in rom/logs/resumes/ folder with the file name and waypoint number. Then if you want to resume you can select 'resume' from the waypoint list or specify 'resume' as the path on the command line

    Code: Select all

    rom/bot path:resume
    This will load the last waypoint that character was running and resume at the last waypoint number it was at (assuming the waypoint file has waypoints and the onload doesn't change the waypoint number).
- Fixed a typo in player:harvest

- Moved recently added code, that keeps casting click to cast skills till all mobs in range are dead, a little higher in the function to make sure it works properly.
  • Something was breaking the cast, before all mobs in range were dead. I suspect it might have been the onleavecombat code. So I move the code above that and that fixed it.
- Added feature to __WPL:getNearestWaypoint. Now you can specify a range of waypoints to look in.
  • The bot makes no use of this feature. This is mainly for users with a little coding skill. Example,

    Code: Select all

    __WPL:getNearestWaypoint(player.X,player.Z,player.Y, 2, 34)
    This will find the closest waypoint to the player that lies between waypoint 2 and 34. You can also use tag names instead of numbers. Here is an example bit of code that uses a quest state to choose the range

    Code: Select all

    if getQuestStatus(questname) == "incomplete" then
       __WPL:setWaypointIndex(__WPL:getNearestWaypoint(player.X,player.Z,player.Y,"Kill Start","Kill End"))
    else
       __WPL:setWaypointIndex(__WPL:getNearestWaypoint(player.X,player.Z,player.Y,"Return Start","At NPC"))
    end
- Updated Enlivened Blade and Day Of Rain skills.

- Fixed bug that caused error when starting the bot when displaying the client list.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
Ego95
Posts: 564
Joined: Tue Feb 28, 2012 12:38 pm
Contact:

Re: 771 Changelog

#2 Post by Ego95 » Tue Jan 28, 2014 5:40 pm

Code: Select all

2014-01-28 23:38:22 - ...ocuments/micromacro/scripts/rom/classes/waypointlist.lu
a:452: attempt to concatenate field 'FileName' (a nil value)
I think the "resume last waypoint file" feature broke the "wander" waypoint :(
Can't even start it.

Greets

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: 771 Changelog

#3 Post by rock5 » Wed Jan 29, 2014 12:38 am

Ah, forgot to test wander. The question is, do we want it to 'resume' wander? Does it make sense to do so, considering that wander mode is linked to where you start it? Note: if we made it resume wander it would not continue wandering in the same location but start from where you resumed.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
Ego95
Posts: 564
Joined: Tue Feb 28, 2012 12:38 pm
Contact:

Re: 771 Changelog

#4 Post by Ego95 » Wed Jan 29, 2014 6:42 am

I think to resume wander would not make any sense.

spyfromsiochain
Posts: 84
Joined: Sun Aug 18, 2013 9:57 am

Re: 771 Changelog

#5 Post by spyfromsiochain » Sat Feb 01, 2014 11:23 am

About resuming "wander", I do it all the time. When I am online and I use "wander" I reply and chat, all the time, and since u have like 2 sec for the refresh of the bot, I dont have time to reply when he is working, so I press "end" to stop, reply and then "del" to resume, this is the way I found to continue doing this.

regards

Edit: I use "wander" option to grind TP btw, with "0" wander, its the best way I found to be the most "human like", "wander" ">0" is faster killing mobs, because it doesnt "rest" but keeps moving around unnecessarily, and using a personalized profile is even worst.
I look at those fans with no blades and it amazes me everytime, how can they push air without using blades lol - lisa (pro sentence :D)

User avatar
Bill D Cat
Posts: 555
Joined: Sat Aug 10, 2013 8:13 pm
Location: Deep in the Heart of Texas

Re: 771 Changelog

#6 Post by Bill D Cat » Sat Feb 01, 2014 11:30 am

I think in this case we are talking about the new Resume feature that lets you restart a waypoint file from where it was interrupted. Using a Wander mode isn't technically following a waypoint file, and as such the new Resume feature doesn't make much sense for it. All you'd have to do is start the Wander mode again and let the bot move around randomly as before.

Using the end and delete keys is only pausing the operation of the bot, so while it is resuming operation when you press delete, it is not exactly the same thing as the new Resume feature.

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: 771 Changelog

#7 Post by rock5 » Sat Feb 01, 2014 11:38 am

In the end the main purpose of the resume option is to resume in the middle of a chain of waypoint files when you don't know where you were up to or to resume from the correct point when restarting a waypoint file that crisscrosses itself. I don't really see any other practical uses for it.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
Bill D Cat
Posts: 555
Joined: Sat Aug 10, 2013 8:13 pm
Location: Deep in the Heart of Texas

Re: 771 Changelog

#8 Post by Bill D Cat » Sat Feb 01, 2014 2:06 pm

So would the "starting from nearest waypoint" option that was already in the bot be obsolete now? What I mean is previously I had to force the bot to start at waypoint #1 with a command in the onload section because sometimes it would want to start somewhere else due to the criss-crossing paths. This would eliminate the need to use the command in the onload section.

With the new resume feature, I think that old functionality could be removed. Starting a new waypoint file should always start at waypoint #1 unless you start it via the resume option, then it should pick up where it left off. I really don't see a need to keep the old function around anymore.

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: 771 Changelog

#9 Post by rock5 » Sat Feb 01, 2014 10:12 pm

Starting a waypoint normally will always start at the closest waypoint, that hasn't changed. If you stop a waypoint part way through then use the resume option then it will resume at the point it left off. This should solve most issues.

If you still have issues of waypoints not starting at the first waypoint when it should it's more a waypoint design fault that a problem with the bot. Typically what I do is, if you start a waypoint file at an npc and revisit the npc later in the waypoint file, I would merge those waypoints into 1 so it only has 1 waypoint to start at. All other overlapping point should be ok because you don't normally start at those locations and the resume feature can be used if you need to restart the waypoint at those locations.

This is what I mean by merging waypoints. Imagine you have a daily that starts and ends at an npc.

Code: Select all

<waypoint x="11" Z="22" Y="0"> 
    player:target(npc)
    AcceptQuestByName(quest)
</waypooint>

....

<waypoint x="11" Z="22" Y="0"> 
    player:target(npc)
    CompleteQuestByName(quest)
</waypooint>
In this case you can just merge the first and last waypoint and delete the last one.

Code: Select all

<waypoint x="11" Z="22" Y="0"> 
    player:target(npc)
    CompleteQuestByName(quest)
    AcceptQuestByName(quest)
</waypooint>

....
It can even work with multiple visits to the npc by using tags and choosing the path to go to based on things like the quest state.

It makes it a bit more complex but it's more versatile than just forcing you to start at waypoint 1.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
Bill D Cat
Posts: 555
Joined: Sat Aug 10, 2013 8:13 pm
Location: Deep in the Heart of Texas

Re: 771 Changelog

#10 Post by Bill D Cat » Sun Feb 02, 2014 3:45 am

Rock5 wrote:Typically what I do is, if you start a waypoint file at an npc and revisit the npc later in the waypoint file, I would merge those waypoints into 1 so it only has 1 waypoint to start at. All other overlapping point should be ok because you don't normally start at those locations and the resume feature can be used if you need to restart the waypoint at those locations.
Unfortunately, createpath doesn't have any way of knowing you want to merge waypoints, and as such the average user who doesn't have much experience in hand coding waypoint files won't have a clue on how to go about doing something like that.

I'll stick to using __WPL:setWaypointIndex(1) then. I've had a number of my daily waypoint files decide to start half-way into the file when I take the command out just because the paths cross and I started the file when I was five steps further from the original point when I wrote the waypoint. The old method of guessing where the first waypoint should be worked adequately when we didn't have a routine that knows where to resume. Now the old routine is redundant from my point of view, but at least it can be coded around in the onload. Unfortunately, that work-around now breaks the new resume feature that gets it right every time.

So now we have three options. Force the bot to start at the first waypoint with a command in the onload, hope the bot guesses correctly on where to start the waypoint, or accurately have the bot resume an interrupted waypoint file.

Maybe I'll just go hunt down the original routine in my copy of the bot and comment it out. Then it doesn't effect anyone else.

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: 771 Changelog

#11 Post by rock5 » Sun Feb 02, 2014 4:25 am

Bill D Cat wrote:Unfortunately, createpath doesn't have any way of knowing you want to merge waypoints, and as such the average user who doesn't have much experience in hand coding waypoint files won't have a clue on how to go about doing something like that.
Most beginners wont be creating complex waypoint files (although there are some that try too grrr). The most complex they will probably do is like that first example where a daily starts and ends at an npc. It's easy enough to learn not to put an end waypoint near the npc. Users who are competent enough to realize they have to force the waypoint to start at 1 or else it wont work, could probably also do it the way I explained. In the end you do it the way you want to and the way you are skilled enough to do.
Bill D Cat wrote:The old method of guessing where the first waypoint should be worked adequately when we didn't have a routine that knows where to resume. Now the old routine is redundant from my point of view
Are you talking about starting a waypoint file at the closest waypoint? The resume feature is just for resuming a waypoint file if you stop it and then want to restart it at the same location. If you are starting a waypoint file for the first time then it will have no where to resume from so has to find the nearest waypoint. That will never become redundant. You just happen to find that you need to start most waypoints from the first. I personally never did that and never had the need to, even when I was a beginner. In the end the bot can't be perfect for every user and users need to cater their code to the features that are available.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
Bill D Cat
Posts: 555
Joined: Sat Aug 10, 2013 8:13 pm
Location: Deep in the Heart of Texas

Re: 771 Changelog

#12 Post by Bill D Cat » Sun Feb 02, 2014 12:45 pm

This is a waypoint file that I use to take me from virtually anywhere to Rorazan to do the daily quest "Demonstration Battle".

Code: Select all

<?xml version="1.0" encoding="utf-8"?><waypoints type="RUN">
	<onLoad>
			player:mount()
			travelTo("Rorazan")
			__WPL:setWaypointIndex(1)
	</onLoad>
	<!-- #  1 --><waypoint x="-20717" z="-22764" y="582">	</waypoint>
	<!-- #  2 --><waypoint x="-20647" z="-22861" y="578">	</waypoint>
	<!-- #  3 --><waypoint x="-20456" z="-22949" y="578">	</waypoint>
	<!-- #  4 --><waypoint x="-20226" z="-23332" y="549">	</waypoint>
	<!-- #  5 --><waypoint x="-19762" z="-23639" y="485">	</waypoint>
	<!-- #  6 --><waypoint x="-19541" z="-23600" y="492">	</waypoint>
	<!-- #  7 --><waypoint x="-19037" z="-23556" y="452">	</waypoint>
	<!-- #  8 --><waypoint x="-18680" z="-23522" y="441">	</waypoint>
	<!-- #  9 --><waypoint x="-18522" z="-23322" y="441">	</waypoint>
	<!-- # 10 --><waypoint x="-18481" z="-23074" y="441">	</waypoint>
	<!-- # 11 --><waypoint x="-18429" z="-22917" y="474">	</waypoint>
	<!-- # 12 --><waypoint x="-18359" z="-22717" y="489">
			player:dismount()
			loadPaths("Dailys/DemoBattle");
	</waypoint>
</waypoints>
If I remove the __WPL:setWaypointIndex(1) command from the onload, then the bot will always say that waypoint #12 is closer than waypoint #1 and will start from there. That will end up running me into the side of a fence and force multiple unstick tries, eventually leaving me outside the walls of Rorazan somewhere. So I have to either use that command or __WPL:setWaypointIndex(__WPL:getNearestWaypoint(player.X, player.Z)) to force the bot to start at waypoint #1. Either option effectively breaks the resume feature if I were to get a client crash at some point while this waypoint is executing as the resume would then try to go back to waypoint #1, possibly trying to run through obstacles on its way.

So what I'm trying to say is, I think the bot should always start at waypoint #1 unless told to resume. Otherwise it is just guessing that the waypoint file was interrupted when it tries to move to the nearest waypoint by default to start. I'd rather it do what I tell it, than for it to try and second guess my intentions.

User avatar
lisa
Posts: 8332
Joined: Tue Nov 09, 2010 11:46 pm
Location: Australia

Re: 771 Changelog

#13 Post by lisa » Sun Feb 02, 2014 5:54 pm

my guess is the travelto function needs a player:update() after arriving at destination.
Remember no matter you do in life to always have a little fun while you are at it ;)

wiki here http://www.solarstrike.net/wiki/index.php?title=Manual

User avatar
Bill D Cat
Posts: 555
Joined: Sat Aug 10, 2013 8:13 pm
Location: Deep in the Heart of Texas

Re: 771 Changelog

#14 Post by Bill D Cat » Sun Feb 02, 2014 6:42 pm

I thought about that, but the bot gives the message that it is going to start at a different waypoint even before the contents of the onload is executed. So it has already decided to go to waypoint #12 before the player:mount() has been executed. So adding the update as part of the travelTo() won't change that.

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: 771 Changelog

#15 Post by rock5 » Sun Feb 02, 2014 9:55 pm

This is not a usual waypoint file. Most waypoint files wont do movements within the onload. If you do do movement within the onload then you have to do something about the current waypoint number. For instance some of my minigames talk to the npc and enter the game within the onload so I've had to add something similar and yet it you restart it withing the game it has no problem. What you have to remember is you only have to set the current waypoint if you actually move within the onload (which makes sense because if you move within the onload then the automatically found point or resume point would become obsolete), otherwise you don't. You could do something like

Code: Select all

if getZone() ~= rorazan then
    travelTo("Rorazan")
    __WPL:setWaypointIndex(1)
end
That should always work because it only sets the waypoint when the travelTo function is used and you will always be at waypoint 1 when the travelTo function is used. Otherwise, if you are in Rorazan, it keeps using the automatically found closest waypoint or resume point if resuming.

See easy.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
Bill D Cat
Posts: 555
Joined: Sat Aug 10, 2013 8:13 pm
Location: Deep in the Heart of Texas

Re: 771 Changelog

#16 Post by Bill D Cat » Sun Feb 02, 2014 10:10 pm

I've already disabled the feature in my copy of the bot, so I'm not going to worry about coding around this particular issue.

Besides, getZone() isn't a recognized command by the bot.

Code: Select all

local zonename = RoMScript("GetZoneLocalName(GetZoneID()%1000)")
seems to work though.
Last edited by Bill D Cat on Sun Feb 02, 2014 10:50 pm, edited 1 time in total.

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: 771 Changelog

#17 Post by rock5 » Sun Feb 02, 2014 10:47 pm

It was example code. I knew you'd know what I meant.

There is actually a bot function. The correct spelling is getZoneId(). The bot function is preferable because the in game function returns the zone and channel merged together so you would have to parse the response. The bot function separates them.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
Bill D Cat
Posts: 555
Joined: Sat Aug 10, 2013 8:13 pm
Location: Deep in the Heart of Texas

Re: 771 Changelog

#18 Post by Bill D Cat » Sun Feb 02, 2014 11:15 pm

GetZoneLocalName() doesn't care if the channel is included in the zone ID. So 22, 1022, 2022 and 3022 all return "Ancient Kingdom of Rorazan".

Now I'll have to go work on my Elven Island, Yrvandis Hollows and Howling Mountains files to see if I can get rid of the need to force the first waypoint in them. The paths definitely cross over multiple times, so I'll have to make sure that they work right so that the new Resume feature will work properly with them.

User avatar
rock5
Posts: 12173
Joined: Tue Jan 05, 2010 3:30 am
Location: Australia

Re: 771 Changelog

#19 Post by rock5 » Mon Feb 10, 2014 9:38 pm

@Bill D Cat

I've started running a few characters through the Elven Island script. I've been thinking a lot about the need to start at waypoint 1 and resuming. And I really see the need for being able to do both.

Firstly let me say, there is a sort of bug with the resume feature. If you stop at a waypoint it gets skipped when resumed. When you are between waypoints it resumes fine. I'll have to fix that. I think I may have to change it so it only updates the resume point just after leaving a waypoint instead of every time the current waypoint is changed.

I can think of 2 solutions to doing both.
  • 1. You should be near waypoint 1 when starting the script for the first time so why not just do a distance check.

    Code: Select all

    if 200 > distance(player,__WPL.Waypoints[1]) then
        __WPL:setWaypointIndex(1)
    end
    That way if it starts for the first time then it will start at waypoint 1 but if you resume and you are some distance from wp 1 the resume feature should work.

    2. Have some variable that indicates that we are resuming so don't start at wp 1. Looks like I can use an existing variable.

    Code: Select all

    if not __WPL.ResumePoint then
        __WPL:setWaypointIndex(1)
    end
    This will make sure that if you are not resuming then it will start at wp 1.
Both examples allow resume to work.
  • Please consider making a small donation to me to support my continued contributions to the bot and this forum. Thank you. Donate
  • I check all posts before reading PMs. So if you want a fast reply, don't PM me but post a topic instead. PM me for private or personal topics only.
  • How to: copy and paste in micromacro
    ________________________
    Quote:
    • “They say hard work never hurt anybody, but I figure, why take the chance.”
          • Ronald Reagan

User avatar
Bill D Cat
Posts: 555
Joined: Sat Aug 10, 2013 8:13 pm
Location: Deep in the Heart of Texas

Re: 771 Changelog

#20 Post by Bill D Cat » Tue Feb 11, 2014 12:00 am

rock5 wrote:Firstly let me say, there is a sort of bug with the resume feature. If you stop at a waypoint it gets skipped when resumed. When you are between waypoints it resumes fine. I'll have to fix that. I think I may have to change it so it only updates the resume point just after leaving a waypoint instead of every time the current waypoint is changed.
Agreed. The resume point should only be updated after any LUA code within the current waypoint has been executed. This way if the script aborts during the execution of that code, it will resume at the same waypoint and attempt to execute it again. Empty waypoints used for movement only will update the resume point to the next waypoint once the character has successfully reached that waypoint.

I'll try out your distance and resume variable checks when I get home from work. Might just be the solution I was looking for.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests