Changelog 745 (RC3)

[rock5]

I can't see what is causing the error, sorry. Try a few things and see if you can figure out exactly what causes it. Example, try a different profile, try a different waypoint file, try a different character, etc. and see if you can see a pattern.

There was a new version of GoThroughPortal released recently. It should work better. Remember to make sure the waypoint where you do the GoThroughPortal is not too close to the portal.

[BlubBlab]

Okay I found out it was my own misstake I added a new event : onZoneChange (player.lua Line 63)
so I can stop unautorized Zone Change because the bot was running sometimes(very raw) backward trough the portal(other cause would be lose the party in middel of a KS run through server errors).

I forgot to add a suitable error message it was an old one, probleme was :

Code: Select all

<onZoneChange>
		cprintf(cli.green, "zone works \n");
		
		if(RoMScript( "GetCurrentWorldMapID();" )== 6)then
			if( __WPL ~=nil )then
				if( __WPL.FileName =="ks.xml" and flagbunch == true)then
					player:logout();
				end
			end
		end
		
		flagbunch = true;
		
		if( __WPL ~=nil )then
			flagbunch = false;
		end
	</onZoneChange>

__WPL seems to be nil.(yes I did here already thinks to prevent the Probleme, but I dont know is __WPL alway nil now?)
So I test it now if wp#6 still crash the game client.

[rock5]

How are you handling the new event? Could you show me what changes you have made? If you have made changes in a few places maybe you could send the whole player.lua file. PM it to me if you don't want to post it here.

[grande]

Ummm, nevermind lol. Had a WP onload issue I hope will be solved when I try RC3. Woo hoo@@@ !! lol

[abron1]

i tried downloading this and all got is a file... no folder so i don't know how to install it.

[BlubBlab]

May it would be better called onAdresseChange but here is the main code :

Code: Select all

function CPlayer:update()
	local addressChanged = false
	local addressChanged2 = false
	-- Ensure that our address hasn't changed. If it has, fix it.
	local tmpAddress = memoryReadRepeat("uintptr", getProc(), addresses.staticbase_char, addresses.charPtr_offset) or 0;
	if( tmpAddress ~= self.Address and tmpAddress ~= 0 and tmpAddress ~= nil) then
		self.Address = tmpAddress;
		cprintf(cli.green, language[40], self.Address);
		addressChanged = true
		if self.Class1 == CLASS_WARDEN then
			setpetautoattacks()
		end
	end;

	local oldClass1 = self.Class1
	local oldClass2 = self.Class2
	CPawn.update(self); -- run base function

	if addressChanged or self.Class1 ~= oldClass1 or self.Class2 ~= oldClass2 or (#settings.profile.skills == 0 and next(settings.profile.skillsData) ~= nil) then
		settings.loadSkillSet(self.Class1)
		-- Reset editbox false flag on start up
		if memoryReadUInt(getProc(), addresses.editBoxHasFocus_address) == 0 then
			RoMCode("z = GetKeyboardFocus(); if z then z:ClearFocus() end")
		end
		
		
		if( addressChanged == true)then
			addressChanged2 = true;
		end
		addressChanged = false
	end

	-- If have 2nd class, look for 3rd class
	-- Class1 and Class2 are done in the pawn class. Class3 only works for player.
	if self.Class2 ~= -1 then
		for i = 1, 8 do
			local level = memoryReadInt(getProc(),addresses.charClassInfoBase + (addresses.charClassInfoSize * i) + addresses.charClassInfoLevel_offset)
			if level > 0 and i ~= self.Class1 and i ~= self.Class2 then
				-- must be class 3
				self.Class3 = i
				break
			end
		end
	end


	self.Level = memoryReadRepeat("int", getProc(), addresses.charClassInfoBase + (addresses.charClassInfoSize* self.Class1 ) + addresses.charClassInfoLevel_offset) or self.Level
	self.Level2 = memoryReadRepeat("int", getProc(), addresses.charClassInfoBase + (addresses.charClassInfoSize* self.Class2 ) + addresses.charClassInfoLevel_offset) or self.Level2
	self.Level3 = memoryReadRepeat("int", getProc(), addresses.charClassInfoBase + (addresses.charClassInfoSize* self.Class3 ) + addresses.charClassInfoLevel_offset) or self.Level3
	self.XP = memoryReadRepeat("int", getProc(), addresses.charClassInfoBase + (addresses.charClassInfoSize* self.Class1 ) + addresses.charClassInfoXP_offset) or self.XP
	self.TP = memoryReadRepeat("int", getProc(), addresses.charClassInfoBase + (addresses.charClassInfoSize* self.Class1 ) + addresses.charClassInfoTP_offset) or self.TP

	self:updateCasting()
	self:updateBattling()
	self:updateStance() -- Also updates Stance2
	self:updateActualSpeed() -- Also updates Moving
	self:updateNature()

	if( self.Casting == nil or self.Battling == nil or self.Direction == nil ) then
		error("Error reading memory in CPlayer:update()");
	end

	self.PetPtr = memoryReadRepeat("uint", getProc(), self.Address + addresses.pawnPetPtr_offset) or self.PetPtr
	if( self.Pet == nil ) then
		self.Pet = CPawn(self.PetPtr);
	else
		self.Pet.Address = self.PetPtr;
		if( self.Pet.Address ~= 0 ) then
			self.Pet:update();
		end
	end
	self:updatePsi()
	self:updateLastHitTime()
	self:updateGlobalCooldown()

	if(addressChanged2 == true)then
	--new event onZoneChange
		if( type(settings.profile.events.onZoneChange) == "function" ) then
			local status,err = pcall(settings.profile.events.onZoneChange);
			if( status == false ) then
				local msg = sprintf(language[555], err);--555 new error message
			error(msg);
			end
		end
		addressChanged2 = false;
	end
...

You need add 3 lines more in the Setting.lua to register the event but that its

[grande]

~*~EDIT*~* Got it working with this:

Code: Select all

<onLoad>

player:update();

__WPL:setDirection(WPT_FORWARD);
__WPL:setWaypointIndex(__WPL:getNearestWaypoint(player.X, player.Z))
__WPL:setDirection(WPT_FORWARD);

</onLoad>

WOOHOO YEAH!!! lolz

Previous drama message:

When I loadPaths it is not going to the correct WP. The MM window initially gives the correct WP indication but then it decides to go to the very last WP which is a huge PITA because of obstacles and ensuing crashing into walls:

Code: Select all

We use the normal waypoint path xyz.xml now.
Waypoint #2 is closer then #1. Hence we start with waypoint #2.
Moving to waypoint #6, (6428, 5438)

*Edit: I notice that it seems to be starting from the last WP# that the previous WP file left from rather than actually going from the nearest WP.

I'm running RC3 now

Saw some posts from 2010 about the functions.lua having issues. Is it something to do with this below?

Code: Select all

-- Returns the point that is nearest to (X,Z) between segment (A,B) and (C,D)
function getNearestSegmentPoint(x, z, a, b, c, d)

	if a == c and b == d then
		return CWaypoint(a, b)
	end

	local dx1 = x - a;
	local dz1 = z - b;
	local dx2 = c - a;
	local dz2 = d - b;

	local dot = dx1 * dx2 + dz1 * dz2;
	local len_sq = dx2 * dx2 + dz2 * dz2;
	local param = dot / len_sq;

	local nx, nz;

	if( param < 0 ) then
		nx = a;
		nz = b;
	elseif( param > 1 ) then
		nx = c;
		nz = d;
	else
		nx = a + param * dx2;
		nz = b + param * dz2;
	end

	return CWaypoint(nx, nz);
end

or does this post have something to do with resetting WPL?? http://www.solarstrike.net/phpBB3/viewt ... 706#p24706

Code: Select all

__WPL = CWaypointList();

[rock5]

May it would be better called onAdresseChange but here is the main code :

I think your problem happens because it tries to do a player:update() while porting. Did you do as I said and made sure the last waypoint was away from the portal?

[rock5]

Saw some posts from 2010 about the functions.lua having issues. Is it something to do with this below?

No issues that old would still be a problem today. It may have something to do with the way I changed the way the onloads run. I should be able to reproduce it. I need to ask a few questions first.

1. Where was the command in the previous file that loaded that file? Was is in a waypoint or in the onload or in a function that is called in a waypoint?
2. Is there any code after the loadPaths command?

[grande]

1. Where was the command in the previous file that loaded that file? Was is in a waypoint or in the onload or in a function that is called in a waypoint?
2. Is there any code after the loadPaths command?

1. in a waypoint

Code: Select all

<!-- # 150 --><waypoint x="7" z="1" y="2">
	local queststate = getQuestStatus("")
	if queststate == "complete" then
		player:target_NPC("");
		CompleteQuestByName("")	
	end
	yrest(1000)
	local dqCount, dqPerDay = RoMScript("Daily_count()");
	if dqCount ~= 10 then
		player:target_NPC("");
		AcceptQuestByName("")
		else
			RoMScript("LeaveParty()"); 
			SetCharList(CharList)
			yrest(500);
                	LoginNextChar()
			yrest(500);
			loadProfile("Default")
			yrest(500);
                	loadPaths("returnpathtorepeatonnexttoon")
			yrest(500);
		end 
	</waypoint>

2. Just the yrest(500);

Thank you Rock5

[rock5]

Grande I couldn't reproduce it. It worked fine for me.

So I think this

Code: Select all

We use the normal waypoint path xyz.xml now.
Waypoint #2 is closer then #1. Hence we start with waypoint #2.
Moving to waypoint #6, (6428, 5438)

means the bot worked correctly in going to #2 but something else made it go to #6. Do you have any other code that changes or sets the current waypoint? Any setWaypointIndex? Maybe even in a timed event?

[grande]

Sorry Rock5, I looked all over to see what was making it start from WP six instead of the closest WP number. In the end I just ended up using the workaround, something like __WPL...getclosestWP...X..Y.. mentioned above.

All I know is I would start from the returnpath which was at WP6 and the last WP where it loads the operational WP, it then loads the operational WP file, it checks the DQ count which is full so it loads to next character, loads return path, indicated WP#2 is closer than WP1 so will start with 2 but then skips back to 6 which is right where it left off before loading to the operational WP.

[BlubBlab]

May it would be better called onAdresseChange but here is the main code :

I think your problem happens because it tries to do a player:update() while porting. Did you do as I said and made sure the last waypoint was away from the portal?

Yeah I did works fine now, the propleme befor stroke only when I was outside the instance(the WPL thats lead to the instance) but because I check if __WPL is nil every works now.

[rock5]

Sorry Rock5, I looked all over to see what was making it start from WP six instead of the closest WP number. In the end I just ended up using the workaround, something like __WPL...getclosestWP...X..Y.. mentioned above.

All I know is I would start from the returnpath which was at WP6 and the last WP where it loads the operational WP, it then loads the operational WP file, it checks the DQ count which is full so it loads to next character, loads return path, indicated WP#2 is closer than WP1 so will start with 2 but then skips back to 6 which is right where it left off before loading to the operational WP.

Sorry, are you talking about a return path from dying? I didn't test that. Let me see if I get this straight.
1. You return from death with a return waypoint file which has 6 waypoints.
2. It loads the main file.
3. It checks the DQ count. This check is in a waypoint right? So it went to the correct waypoint right?
4. It loads the next character, loads the default profile and load a return path. So it's not a death return path?
5. It indicates that wp 2 is closer but goes to 6.

Does that sound right?

[kenzu38]

Hey rock, just here to report what I noticed since changing to RC3. Haven't read the previous pages of this thread so I don't know if someone's already told you but since I started using RC3, I've had quite a handful of game client crashes when opening RC3.

And it almost always crashes when I run it when another client with a different window size is open in the background but not minimized. Neither of these windows are "fit to screen". But one of them crashes when I open RC3.

Also, sometimes when running RC3, it changes the window size of my client. Haven't had any of these oddities in any other version.

[rock5]

Hey rock, just here to report what I noticed since changing to RC3. Haven't read the previous pages of this thread so I don't know if someone's already told you but since I started using RC3, I've had quite a handful of game client crashes when opening RC3.

And it almost always crashes when I run it when another client with a different window size is open in the background but not minimised. Neither of these windows are "fit to screen". But one of them crashes when I open RC3.

Also, sometimes when running RC3, it changes the window size of my client. Haven't had any of these oddities in any other version.

I Just started 5 clients, which is more than I would usually bot at one time with, changed the window sizes, then started the bot. No issues whatsoever. In fact you should have less crashes because the RC version uses a lot less cpu. I suspect you have some sort of memory issue, maybe faulty memory, etc. There hasn't been a flood of messages about crashes so I suspect it's something to do with your set up.

There is no code in the bot that changes window size to my knowledge. So if it is actually happening then it not likely to be caused by the bot.

[kenzu38]

Ok, I see. Then it's probably coz of the new patch rather than the bot. Or probably coz I haven't upated my graphics card driver in a while.

[rock5]

No, it works fine with the new patch.

[lisa]

I have been having an issue with the "pulled back" code it does, mostly when going through portals. Obviously the coords change quite a lot when going through a portal and then it says it has been pulled back and does the -1 waypoint thing which are the coords on the other side of the portal which makes the bot just walk off into the distance.
I am not sure a -1 waypoint is the best default behaviour.

[rock5]

I thought the pull back code is supposed to work out which is the nearest next waypoint. It looks back to see which 2 waypoints it's between and goes to the next waypoint. I'm not sure under what circumstances it would try going to a waypoint before a teleport. Maybe if the player coordinates weren't updated and it thought it was still at the last location? But seeing as the pull back code only happens in the moveto function that means it would only be an issue if you moveto into a portal. Aren't you using GoThroughPortal? Could you try a possible fix. Add a "player:update()" to the top of the "CWaypointList:findPulledBeforeWaypoint()" function. See if that helps.