SolarStrike Software

Posted: **Thu Mar 31, 2011 1:22 am**

I was having a few issues with that function when bot wouldn't actually activate the loading (either failing to trigger the zone change via a portal or not managing to talk to the NPC at all) so I made a few minor changes to the existing one to not get stuck in an infinite loop.

By default it will exit and return false after 15 seconds so your script can fix the issue.

Code: Select all

function isZoneChanged(_maxWaitTime)
	-- delay is the max waiting time bot will wait for loading screen to appear, 15 sec by default
	local _maxWaitTime = _maxWaitTime or 15
	
	-- wait for loading screen to appear
	if memoryReadBytePtr(getProc(), addresses.loadingScreenPtr, addresses.loadingScreen_offset) == 0 then
		repeat
			yrest(1000)
			_maxWaitTime = _maxWaitTime - 1
		until _maxWaitTime == 0 or memoryReadBytePtr(getProc(), addresses.loadingScreenPtr, addresses.loadingScreen_offset) == 1
	end

	if _maxWaitTime == 0 then
		-- Loading screen didn't appear, we return false so waypoint file can try to trigger zone change again or exit with an error
		cprintf(cli.yellow,"Couldn't detect zone change...\n")
		return false
	end
	
	-- wait until loading screen is gone
	repeat
		yrest(1000)
	until memoryReadBytePtr(getProc(),addresses.loadingScreenPtr, addresses.loadingScreen_offset) == 0

	yrest(2000)
	player:update()
	return true
end

Some really basic example use (for a buggy instance portal like Clops that, sometimes, won't zone your char even while standing inside). Would be slightly better if it also pressed forward key incase bot failed to move in the portal for any reason and, of course, a max number of tries is always good to not end up jumping on the same spot all night

Code: Select all

repeat
	keyboardPress(key.VK_SPACE);
until isZoneChanged()

So far it works fine with portals for me (instead of bot standing in the middle of it for hours while AFK), but didn't get a failure to talk to NPC yet, so I'm not certain that trying to talk to him again is enough to fix the issue. And hopefully it will save a few mins to someone having the same problem with original function

Posted: **Thu Mar 31, 2011 2:12 am**

A good idea but I don't think it can be used as a general replacement for waitForLoadingScreen() because, for example, changing characters could take an unknown amount of time so 15s would cause it to fail. Maybe a user specified timeout value would work?

I could add another argument so peaple can specify how long the timout should be. eg waitForLoadingScreen(20) will wait a maximum of 20 seconds for the loading screen to appear before returning false. Probably if no timeout is specified then it should use a large default timeout like 2-3 minutes although I'm not sure about that.

What do you think?

Posted: **Thu Mar 31, 2011 4:44 am**

I think it's good idea, specify a value to wait.

Posted: **Thu Mar 31, 2011 4:58 am**

I didn't have logout in mind when modifying that function. But the current waitForLoadingScreen() is perfect for relogging : nothing embarassing can happen if the bot gets stuck in that phase and Rombot also doesn't have any control over that part, so there wouldn't be any reason to exit that loop early.

Anyway, if the waitForLoadingScreen() function had to be updated, it would have to keep the "infinite" loop by default, if only for compatibility purposes with existing waypoint files. But adding the timeout as an optional argument to it would certainly be an improvment for the bot.

Posted: **Thu Mar 31, 2011 5:07 am**

That's the conclusion I came to. I don't think there should be a 'default' timeout value. Because if a user doesn't check to see if the function returned true or not and just expects it to work (and that would be most users) then the character will head towards the next waypoint which might be nowhere near him with disasterous results.

I think to use the timeout value the user has to manually include it and add code to deal with it returning false. If there is no code for dealing with a false value then there is no point in returning false.

Posted: **Sat Apr 02, 2011 5:00 pm**

I made something very similar to this. Does jumping at Clops portal work? I've tried having it backup and move side to side, but sometimes it still doesn't want to work. I haven't tried jumping yet.

I override waitForLoadingScreen because it behaves exactly the same as original when no timeout is specified.

waitForLoadingScreen(15000) would wait for 15 seconds and if no load screen, return false.

Code: Select all

function waitForLoadingScreen(_wait)
	if memoryReadBytePtr(getProc(), addresses.loadingScreenPtr, addresses.loadingScreen_offset) == 0 then
		printf("Waiting for loading screen...\n")
		local timeStart = getTime()
		repeat
			yrest(100)
			if _wait ~= nil and deltaTime(getTime(), timeStart) > _wait then printf("Loading screen did not appear after %s seconds!\n",_wait * .001) return false end
		until memoryReadBytePtr(getProc(), addresses.loadingScreenPtr, addresses.loadingScreen_offset) == 1
	end
	repeat
		yrest(100)
	until memoryReadBytePtr(getProc(),addresses.loadingScreenPtr, addresses.loadingScreen_offset) == 0
	yrest(2000)
	player:update()
	printf("Loading screen cleared!\n")
	return true
end

Posted: **Sat Apr 02, 2011 7:50 pm**

Alkaiser wrote:I override waitForLoadingScreen because it behaves exactly the same as original when no timeout is specified.

That's probably because i haven't committed the changes yet. Sorry. It looks like I might even have lost the changes i made to my file, so I'll have to do it again.

Edit: No, found a copy in a backup. But I like the way you checked the timeout value in the loop. It's 1 less 'if' statement compared to mine so I'll change mine to match. I'll be committing a change soon to allow users to monitor ungame events. I'll include this change then.

Posted: **Sat Apr 02, 2011 8:18 pm**

Alkaiser wrote:
I made something very similar to this. Does jumping at Clops portal work? I've tried having it backup and move side to side, but sometimes it still doesn't want to work. I haven't tried jumping yet.

Yeah jumping does work everytime for me. The only thing I'm afraid is that if for some reason the bot doesn't move right inside the portal, he could keep jumping for a long time

I tried moving forward and jumping, but I must have done it wrong since the bot just ended trying to run against the door without jumping and slightly moving to the left side where it wouldn't zone at all. I guess that moving backward and then jumping forward would be the best anti-stuck solution, but didn't get time to try that yet.

Posted: **Wed Apr 06, 2011 2:08 pm**

Well, I've incorporated jumping at the entrance but it still sometimes fails. It seems that the inability to enter the instance only occurs when RoM is minimized. If I restore the RoM window then the instance will load every time.

EDIT: WOAH! One of my clops bots just got a 7-day ban (first ban ever). Must have messed up and did something very bottish while I was sleeping.

Posted: **Wed Aug 10, 2011 3:58 am**

Hi
First sorry to bump this thread - but i`ve been using this function for quite a while to get to CL, and for the last couple days its behaving funny - doesnt detect ( or hardly ever ) address change. So even if i get thru the portal my char still waits in the loop for address change.

MM prints out that it didnt detect the zone change, and char is walking back and forth thru the portal several times until eventually he got killed by couple of mobs hanging around entrance area ( while waiting for loading screen bot is not defending himself ).

Below is part of the code that im using :

Code: Select all

repeat_counter = 0;
		repeat
			keyboardHold(key.VK_W); -- The W key will be held down
			yrest(1000);
			keyboardRelease(key.VK_W); -- The W key is now released 
			yrest(100);
			keyboardPress(key.VK_S);
			keyboardPress(key.VK_SPACE);keyboardPress(key.VK_SPACE);keyboardPress(key.VK_SPACE);
			repeat_counter = repeat_counter +1;
			cprintf(cli.red,"Tried %s times.\n", repeat_counter);
			if ( repeat_counter > 3 ) then break end
		until isZoneChanged()
		if ( repeat_counter > 3 ) then 
			cprintf(cli.red,"Trouble getting thru the doors - will retry last 3 waypoints.\n");
			__WPL:setWaypointIndex(__WPL:findWaypointTag("DoAgain"));
		end

i was just wandering if that have anything to do with Rock5 recent update to waitForLoadingScreen() function in r.619 ?

Posted: **Wed Aug 10, 2011 7:52 am**

That looks confising to me. You aren't actually using waitForLoadingScreen().

This is how I do 'walk in teleports'

Code: Select all

...
<waypoint before teleport tag="try again"></waypoint>
<waypoint in teleport> 
    if not waitForLoadingScreen(30) then
        __WPL:setWaypointIndex(__WPL:findWaypointTag("try again"))
    end
</waypoint>
...

If it doesn't teleport in 30 seconds then it goes to the last waypoint to try again.

If there is an issue with waitforloadingscreen, I'd need to see how you're using it first.

Posted: **Wed Aug 10, 2011 8:56 am**

Rock5
Thanks for your prompt answer and help

Just wanted to point out that this function doesnt work properly anymore and to be honest i have no clue about memory , addresses and pointers and all the rest. It was just an idea since i have red that you have played with waitforloadingscrren function - and this one stopped working not that long afterwards ( but might be a complete coincidence ).

Indeed you way seems to be a bit simplier and easier, i will use it - if you dont mind

Thanks again

SolarStrike Software

Slightly enhanced waitForLoadingScreen()

Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()

Re: Slightly enhanced waitForLoadingScreen()