Bot strange error?

[ark2003]

Tested today with 4 clients running and it ran more than 6 hours without getting stuck and it cycled through 3 full accounts and 4 chars on 4th account. After that i got "virtual memory too low" message and 2 clients crash (which is normal if i understand it correctly).
Since the change was regarding windows frames (like chat,menu,bagpack) so i manually did some testing by opening and closing some boxes while client was running.
So overall there was no problem due to changes proposed.

[rock5]

The problem is, if I implement that change, then it won't be able to recover if the chat bot is opened by mistake or any other edit box gets focus.

I'd rather figure out why it's not working but so far we have had no luck.

As far as I can tell, if it's working with the change, then nothing really has focus even though the bot thinks it does. Also editBoxHasFocus_address == 0 which happens when you change character but GetKeyboardFocus():ClearFocus() doesn't clear it.

Is it possible your computer just isn't fast enough and you need to increase the wait times?

I just experimented by reducing the 800ms timeout value and it started behaving like you described. So try to increase that value and see how that works.

It's line 608 of functions.lua

Code: Select all

				if( deltaTime(getTime(), startWaitTime) > 800 ) then

Try increasing the '800' to something larger like '1500' and see how that works.

[ark2003]

during my testing i added some wait in if condition so that bot does not execute a large number of instruction in short time here is the code:

Code: Select all

			while( memoryReadByte(getProc(), macro_address + addresses.macroSize *(resultMacro - 1) + addresses.macroBody_offset) == 6 ) do
				if( deltaTime(getTime(), startWaitTime) > 800 ) then
					yrest(200);
					tryagain = true
					break
				end;
				rest(1);
			end

when i open any box,bagpack etc bot is running fine but box is still open.
And with original code i had problems only very few times but with more clients opened it was frequent. As you mentioned wait time can be cause of it since with 4 clients system gets too slow.

i will try with the changes suggested in ur last reply but that would delay the execution also. In my case script was simple and no interactions with any boxes involved. But by removing that code segment: in certain scripts like making mana stones or automatic chat it may create produce some unwanted behavior (not sure though).

[rock5]

Well the first step is to see if that fixes the problem. Then I'll try to think of a solution that doesn't delay things too much. Maybe have the 800 timeout increase each time it retries, so it goes fast while it can but increases the timeout value when your system is going slow?

[rock5]

Actually I just realised it doesn't matter if you change the timeout value to a large number. It wont delay the RoMScript commands. That is only the maximum time it will wait if the command fails. So as long as the command doesn't fail, there wont be a delay.

I just tried 8000 and it still executed the RoMScript command as fast as always.