Page 18 of 20
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Thu Jan 03, 2013 1:19 pm
by 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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Thu Jan 03, 2013 4:18 pm
by 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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Fri Jan 04, 2013 1:24 am
by 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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Fri Jan 04, 2013 2:52 pm
by grande
Ummm, nevermind lol. Had a WP onload issue I hope will be solved when I try RC3. Woo hoo@@@ !! lol
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Fri Jan 04, 2013 3:34 pm
by abron1
i tried downloading this and all got is a file... no folder so i don't know how to install it.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Fri Jan 04, 2013 3:36 pm
by 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
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Fri Jan 04, 2013 4:00 pm
by 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
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sat Jan 05, 2013 12:37 am
by rock5
BlubBlab wrote: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?
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sat Jan 05, 2013 12:45 am
by rock5
grande wrote: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?
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sat Jan 05, 2013 11:06 am
by grande
rock5 wrote:
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
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sat Jan 05, 2013 12:29 pm
by 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?
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sat Jan 05, 2013 12:51 pm
by 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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sat Jan 05, 2013 2:30 pm
by BlubBlab
rock5 wrote:BlubBlab wrote: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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sun Jan 06, 2013 12:32 am
by rock5
grande wrote: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?
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sun Jan 06, 2013 9:52 am
by 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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sun Jan 06, 2013 10:26 am
by rock5
kenzu38 wrote: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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sun Jan 06, 2013 11:19 am
by 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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Sun Jan 06, 2013 11:43 am
by rock5
No, it works fine with the new patch.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Tue Jan 15, 2013 5:36 pm
by 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.
Re: Heads up! Big update comming. Public Release RC3 ready.
Posted: Wed Jan 16, 2013 9:04 am
by 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.