Q: How to force bot not to unstick?

[kkulesza]

I have writen my own function to send mail.
I trigger it inside a waypoint.
The problem occurs when i open portable mailbox with bot.
When mailbox is opened then the focus automaticly goes to textboxes and some "wwwww" are being writen.
I can still send the mail, close mailbox and move on, but...
every time bot unsticks itself.
I think it is happening because of the textboxes. Bot remembers he has hit "W" key few times and he didn't change position.
So he thinks he's stuck.

Is it possible to wipe his memmory and simply move to the next waypoint without unsticking?

[lisa]

if you are doing the mailing manually just pause the bot by pressing END key (default)

If you are making the bot use the portable mailbox then you need to look at how you are implementing the usage.

[rock5]

If the edit box gets focus when you open the mailbox you could try clearing the focus on the same command. eg. I don't know what command you use to open your Mailbox but lets assume it's MailFrame:Show(). You could try

Code: Select all

RoMScript("MailFrame:Show(); GetKeyboardFocus():ClearFocus()")

[kkulesza]

in the onload section i have mail sending function:

Code: Select all

function SendToFriend()

	RoMScript("OpenMail()")
	yrest(1000)
	RoMScript("MailFrameTab_OnClick(2)")
	yrest(1000)
...
end

trigerring the function:

Code: Select all

<waypoint x="-12043" z="13169" y="96">
					if( __WPL.Direction == WPT_BACKWARD ) then
					   SendToFriend()
					end
</waypoint>

[rock5]

I suspect it is when you click the second tab that the edit box gets focus so try

Code: Select all

   RoMScript("MailFrameTab_OnClick(2); GetKeyboardFocus():ClearFocus()")

I just did a bit of a test. It seems to work.

[kkulesza]

Code: Select all

RoMScript("MailFrameTab_OnClick(2); GetKeyboardFocus():ClearFocus()")

still unsticks the bot, but now only "1" is inserted into textbox.
I've got VK_1 triggering in one of my skills but bot is out of combat while sending mail, so i don't know why he would press "1"

but still your method is about preventing bot to unstick, not forcing in not to unstick.
I was think about loading a new path after sending mail.
Are there any exta args possible int the loadpath function?
Something liek this would be perfect:

Code: Select all

loadpath("waypoinFileName",WayPoint=15)

[rock5]

Loading a new waypoint file will always start at the closest waypoint unless told otherwise.

You could put

Code: Select all

__WPL:setWaypointIndex(15)

in the onload section of the waypoint file or maybe follow the loadpath.

Code: Select all

loadPaths("waypoinFileName")
__WPL:setWaypointIndex(15)

[kkulesza]

Ok. I've done a lot of debugging (and i hate debugging)
And my unsticking problem is solved.

The problem was with textboxes getting focus, but in two places in code.
1. First of all i had to clear focus from "To:" textbox in order to do some further scripting while MailFrame is open.

Code: Select all

RoMScript("MailFrameTab_OnClick(2)")
RoMScript("GetKeyboardFocus():ClearFocus()")

This wasn't causing the unsticking problem though.
Originally i got rid of the focus by double pickup macro:

Code: Select all

RoMScript("PickupBagItem(1)");yrest(100);
RoMScript("PickupBagItem(1)");yrest(100);

It worked, but the ClearFocus() function is better, and i wasn't aware of it, so thx a lot Rock5

2. Further in the code i used a SendMail() function. After that focus goes to "Subject:" textbox.
This was causing the unsticking problem, but also a strange behaviour of micromacro/bot occured
I'll post the two pieces of code . 1st caused unsticking problem.

Code: Select all

RoMScript("SendMail(\""..altName.."\", \"GuildNeedWeapons\", \"\", nil)")

--some code to count the mail
	MailsSend=MailsSend+1;
	if MailsSend >= MAX_MAILS then
		currentAlt=currentAlt+1;
		MailsSend=0;
	end
	if currentAlt> #altList then
		endFarming();
	end

--closing the mail UI
RoMScript("CloseMail()");

2nd is not causing the problem

Code: Select all

RoMScript("SendMail(\""..altName.."\", \"GuildNeedWeapons\", \"\", nil)")
	yrest(1000);
	RoMScript("CloseMail()");  --closing the mail UI


--some code to count the mail
	MailsSend=MailsSend+1;
	if MailsSend >= MAX_MAILS then
		currentAlt=currentAlt+1;
		MailsSend=0;
	end
	if currentAlt> #altList then
		endFarming();
	end

As you can see the difference is in the place where CloseMail() is called.
In the 1st example bot was starting to move immidiately after the SendMail() was called,
but the Mail UI was open for few secs and In the "Subject:" textbox some "wwwwww" were being writen until CloseMail() was called.

Ok, but why did the bot start to move?
Function called in waypoint N was not ended and bot was already moving to N+1 waypoint.
I thought that bot executes all instructions declared in a waypoint and after he finishes them he follows to the next waypoint.
I didn't understand that at beginning.
Now i think it was a delay in the RomScript() function.
Bot did execute the

Code: Select all

RoMScript("CloseMail()")

instruction and moved on not waiting for Rom client to execute the CloseMail();

Again thx for help lisa and Rock5

[rock5]

Not all commands wait for it to complete before releasing control for the next command. If a command doesn't have time to finish then you need to put a pause after it to give it time. Or you need to check somehow that it is finished.

There is something you need to understand about RoMScript. I has steps it takes when an edit box has focus. So when you go to the second tab with this command

Code: Select all

RoMScript("MailFrameTab_OnClick(2)")

the edit box will get focus.
For this command to execute

Code: Select all

RoMScript("GetKeyboardFocus():ClearFocus()")

Focus needs to already be cleared because no command can execute while an edit box has focus. So RoMScript does it's thing to clear focus then it executes that command which by then is not necessary. I guess what I'm saying is any RoMScript command will clear focus. That is why I put those commands on the one line, so that the focus is already cleared by the time the RoMScript finishes.

Movement on the other hand doesn't clear focus. That's why when the last RoMScript command causes an edit box to get focus and it starts trying to move, you get "wwww"s appearing.

As to why the 2 pieces of code are acting differently, there is nothing there that should make it act differently except the "endFarming()". I don't know what's in that so there could be something there.