Allmost foolproof KS run

[BillDoorNZ]

After further testing I found that when the player address is changing, the code in CPlayer.update() is changing the internal address (at the start of said function) and setting the addressChanged flag to force the skills for the primary class to be reloaded.

Just before it reloads the skills, it does a CPawn.update(self). Which for some reason was terminating early (self.Id was 0 so it was reading the player Id and then exiting back out without updating anything else .

I have changed the start of the CPlayer:update() function to look like:

Code: Select all

function CPlayer:update()
	local addressChanged = false

	-- Ensure that our address hasn't changed. If it has, fix it.
	local tmpAddress = memoryReadRepeat("intptr", getProc(), addresses.staticbase_char, addresses.charPtr_offset) or 0;
	if( tmpAddress ~= self.Address and tmpAddress ~= 0 ) then
		self.Address = tmpAddress;
		cprintf(cli.green, language[40], self.Address);
		addressChanged = true
		self.Id=-1;
	end;

-> note the: self.Id = -1; call - this allows the CPawn.update(self) call to update the player data correctly (I say correctly, but I have no true idea if this is what should happen or if the code is how it is for a specific purpose).

[rock5]

The Id shouldn't change. It's possible that, in pawn:update, it is reading an invalid Id from the new address, so it sets the Id to 0; meaning it is not a valid address. This may be due to some strange behavior in some servers such as the rom4u server where it needs a 3s pause after the waitforloadingscreen function before continuing.

So try this,

Code: Select all

GoToPortal()
waitForLoadingScreen()
yrest(3000)
player:update()

[BillDoorNZ]

ah...thats probably the issue then.

I effectively run the bot in wander mode and then send it waypoint files. Sometimes I control it manually tho, in those cases, it will be merrily running away minding its own business when I'll take it through a portal or teleporter and the bot will detect a player memory address change and probably try running against memory locations that are currently being written to or changed

Having the self.Id = -1 forces it to reload this stuff correctly tho - so its probably because the id is being updated to 0 somewhere - don't know how or why tho. As the Id is 0 when it detects the address change, which presumably is from a previous player/pawn:update() call before it recognised the change. Ah well. Seems to work with the -1 in there now, so will just monitor that.

[lisa]

Code: Select all

memoryReadRepeat("intptr", getProc(), addresses.staticbase_char, addresses.charPtr_offset) or 0;

What this code means is that it will try the read repeat function and if that function fails to get the address correctly then it returns 0

So when you have the address as being 0 it means it failed to get the correct address.

[BillDoorNZ]

aha! thanks lisa

little wonder it behaves as it does - poor thing doesn't know I'm running it through teleporters all over the place

[BillDoorNZ]

after many deaths and a generally painful experience with said 'foolproof' ks run, I've decided to make my own version that works better for ranged dps. Running in and getting hit by 5 or 6 ousul's and dying because of massive dot stacking is not my idea of fool proof.

The only way I can see of doing this effectively is by overriding the evalTargetDefault function and adding in some box constraints (only allowing it to target mobs in a specified rectangular area).

I've got the basics of this working now so the bot will:

1) run into the instance
2) set max_target_dist to 20 so as not to attack anything and head to the first corner changing target dist
3) at first corner it overrides the default targeting to constrain it to only target stuff in the current corridor and dps kills all mobs in that area
4) runs part-way up the corridor and loots all the corpses in one go
5) moves into the first room (checking here to make sure it did do the looting, otherwise it runs back and does so)
6) changes the constraining rectangle to the first half of the lower section of floor and then dps's and loots
7) moves to mid point and moves rectangle to the rest of the lower section floor, dps, loot, run to bottom of stairs.
8) run up stairs and set targetable area to whole section and re-enables looting after each kill (no poison mobs here)
9) carries on killing all the way to first boss and resets.

This is heavily based on the existing KS script concepts etc but re-pathed and updated. This is primarily focussed on ranged dps and as such I haven't done any testing with a melee based character.

A note about the zip file - it has a waypoints and userfunctions folder to hold a couple of helper files and the geom.lua file (which goes in the mm\scripts\rom folder. you should be able to extract the whole thing to the mm\scripts\rom folder and it should add the other files to the appropriate dirs for ya.

Updated: 2 Apr 2012 @ 8:30am

KS_WIP.zip

(5.69 KiB) Downloaded 180 times

[rock5]

Using constraining areas has been talked about before but always concidered too complex for general use with the bot but I like the idea of having it available for specific situations. It would be nice it we could find a way to add it as an option without interfering with the regualar bot.

It would have to be a bit versatile though. I can't tell by looking at your code but does it only do straight rectangles? Can it handle angled rectangles and warped rectangles?

Idealy it should be able to use iregular shapes with different number of corners.

[lisa]

I like the restricting area for farming but for use in open area to look less like a bot, I wouldn't bother to use in an instance myself.

Running in and getting hit by 5 or 6 ousul's and dying because of massive dot stacking is not my idea of fool proof.

I've never had any troubles with chars dieing in KS, I have run S/Wd, M/P, P/S, M/D, Wd/W.
Usually run with lvl 65 and 12k + hp, lvl 65 package.
I do make specific WP for each different class type though, so my M/* runs to middle of group and uses purg, I set it to melee.
I also ALWAYS use a pet with perfume, this makes sure you don't run in to mobs to loot before killing the others. Groups of 4 mobs and you kill 1 then run into the middle of the other 3 mobs to get attacked at the same time will always make things harder.

At the moment I am testing with mages in KS to see if I can get the Gold/Hour higher because of the AOE.
I am running without any luck pots or housemaid pots and getting an average of 2.5mil/H.

Just using pet perfume, Honor Party and a single Luck Rune, 120% luck.
All bags are full before first boss.
I might see if I can get that to 3.5-4mil/H when the housemaids get high enough to give luck pots but I am not holding my breath.

[Sithlord512589]

Hi, first of all thanks BillDoorNZ for providing your files/work.
But sadly i get an error by starting it.
Only change i made was inserting my Toonsname for regrouping.

[rock5]

In regards to the restricting idea, after doing a search online, I was lead back to a post on this site.
http://www.solarstrike.net/phpBB3/viewt ... ?f=2&t=103
It just has a small error that needed fixing and I changed it to match our standards. Here is what I came up with. I tested it, it works correctly.

Code: Select all

function pnpoly(vert, testx, testz )
	local nvert = table.getn(vert)
	local j = nvert
	local c = false
	for i = 1, nvert do
		if ( ((vert[i].Z > testz) ~= (vert[j].Z > testz)) and (testx < (vert[j].X - vert[i].X) * (testz - vert[i].Z) / (vert[j].Z - vert[i].Z) + vert[i].X) ) then
			c = not c
		end
		j = i
	end
	return c
end

Now, how to use it. I'm thinking at a particular waypoint you would set a constraining table. Then in evalTargetDefault it checks to see if there is a table, if so it checks if it's in the area. Then when you leave the area you cancel the table.

What do you think?

[lisa]

I did post some code a while back when I was doing something for the game GF, it was purely limits of X and Z axis, so basically a rectangle. If character went outside the box it turned around and came back inside.
Wasn't anything fancy but it did work lol

Instead of changing evaltarget why not just create a function to do it?
So it would work kind of like wander but in a set area and put some sort of requirements to be met before continuing another WP. Could be time or a number of specific items, that sort of thing.

[rock5]

I'm not sure what you mean. The goal is to stop it from targeting mobs outside an area. We don't need to restrict the player because the player will be following a waypoint file. Sounds like you are talking about a new option to stay in an area until some condition is true, similar to what we already do by looping back to a tagged waypoint. But even this suggestion will require some way not to target mobs outside a given area. Which is where my idea comes in. Well maybe not my idea. I'm not sure who first had the constraining idea. It's been around a while.

Here is a better example of how I envision it working. Lets say you enter the first room with the frogs in ks. As soon as you enter you set the constrained area to the first room. That's the part with just the frogs. You put a few waypoints around the room then head up the stairs. At the top of the stairs you change the constrained area to the room at the top of the stairs. The beauty of this is you don't need to limit your attack range because there is no danger of attacking the mobs at the top of the stairs. And because you don't change the area until you reach the top of the stairs, it wont target any of the mobs at the top of the stairs until it gets to the top of the stairs where it is able to attack them.

Note: this should be extremely simple to implement.

[BillDoorNZ]

lol..thats exactly what i use it to do rock

I have a killzone rect check that occurs in an evaltarget replacement that checks if the target is in the killzone.
i.e.

Code: Select all

function KSevalTargetFunc(address, target)
	local canTarget = KS_old_evalTargetDefault(address, target);
	if ((canTarget) and (KS_target_rect)) then
		--check that target is in current box
		return PointInKillRect(target.X, target.Z);
	end;
	
	return canTarget;
end;

where KS_old_evalTargetDefault is the evalTargetDefault function and i replace it with mine and re-use it internally. The PointInKillRect evaluates the target vs the 'killrect':

Code: Select all

function KSSetKillZone(_rect)
	KS_target_rect = _rect;
	if (_rect ~= nil) then
		KSorigin = Point(_rect.cx, 0, _rect.cz);
		KSv1 = Point(_rect.v1x, 0, _rect.v1z);
		KSv2 = Point(_rect.v2x, 0, _rect.v2z);
		KSv1 = KSv1-KSorigin;
		KSv2 = KSv2-KSorigin;
		KSdp_v1_v1 = KSv1..KSv1;
		KSdp_v2_v2 = KSv2..KSv2;
	else
	end;
end;

function PointInKillRect(_x, _z)
	local pt = Point(_x,0,_z);
	local v = pt-KSorigin;
	
	local dp_v_v1 =  v..KSv1;
	local dp_v_v2 = v..KSv2;
	
	local result = (dp_v_v1 > 0);
	if (result == true) then result = (dp_v_v1 < KSdp_v1_v1); end;
	if (result == true) then result = (dp_v_v2 > 0); end;
	if (result == true) then result = (dp_v_v2 < KSdp_v2_v2); end;

	return result;
end

will take a look at your code in a sec.

yes, the rectangle can be on an angle with my implementation. unfortunatel i hacked my stuff up to simplify it and didnt test before posting

[rock5]

Ah, yes hooking into the eval function. I was thinking about that when considering a userfunction but I think it should be added to the bot.

Here's what pnpoly does. It basically draws a horizontal line to the right and counts how many lines it goes over. If it's even then the test point is outside the area. If it's odd then it's in the area. A fairly foolproof method.

[lisa]

I'm not sure what you mean.

Seems we were talking about different things lol
I understand what you mean now.

Couple of points.

1. How would you get the area you want?
would you need to do 4 points to get the box or do a loop of the area recording the coords as you went?

2. If you did the frogs room as in your example and kept the distances as default in profile then you would need an area for the first group and then go out into the next room and then do the new area, otherwise you would try killing the frogs through the walls.
So you would be creating many "areas" for the one instance like KS, there would need to be an easy/fast/efficient way to create the areas or it would be even more work then just changing the profile options.

3. Would need to have a fight back option for mobs out of the area, foolproofing it as such or clear the area if character moves out of such area. If the bot over ran a waypoint and so it didn't load the new area it wouldn't try to kill any of the mobs in that area which wouldn't be good.

Note: this should be extremely simple to implement.

Things are never that easy lol

[rock5]

1. You could just use createpath and then extract the coordinates. The table the function expects would look something like this.

• table = {
  • {X=1,Z=1},
    {X=2,Z=2},
    {X=1,Z=2},
  }

2. Well, to be REALLY thorough you could do areas for every room and even the corridors if you want but most likely you would just do the difficult rooms and reduce the MAX_COMBAT_DIST a little for easier parts. This method would never be as easy as changing profile options but would yeild better results. So it's up to the user to decide if a certain problem would be best solved by using this method.

3. Not sure. The bot already fights back when aggroing a mob that doesn't pass the default eval function so this should be no exception. It should fight back without any extra work. I'm pretty sure that the bot executes code from passed waypoints so that shouldn't be an issue. The only check I can think of that really needs to be done is to check if the target area is very far away, such as when the user forgets to clear it before moving away or teleporting. Then it should ignore it I think. Or maybe that will intoduce too much needless processing, I'm not sure.

It should be easy to implement. Just have a function to modify the "killzone" table and a check in the eval function

Code: Select all

if killzone then
    if not pnpoly(killzone,target.X,target.Z) then
        return false
    end
end

It could be as simple as that.

[jasn]

How does that handle the flying mobs ?

[BillDoorNZ]

Hi, first of all thanks BillDoorNZ for providing your files/work.
But sadly i get an error by starting it.
Only change i made was inserting my Toonsname for regrouping.

Sorry Sithlord, I had to hack that stuff together in a hurry and there were obviously errors...no time to fix atm, but will sort out on monday.

[rock5]

How does that handle the flying mobs ?

There are no truly flying mobs. The only things I've ever seen truly flying are the birds of paradise in Thunderhoof Hills. And they are just small critters, not actual mobs.

To answer your question, the function I did does not limit by the Y value of the mob but there are already checks for that in the default eval function.

[BillDoorNZ]

Hi, first of all thanks BillDoorNZ for providing your files/work.
But sadly i get an error by starting it.
Only change i made was inserting my Toonsname for regrouping.

I've updated the previous post with a corrected (and tested) version. Bear in mind it is still a WIP (Work In Progress) so there are some bits that are unfinished. The first part up to the top of the first big set of stairs (technically the second set of stairs as there is that first tiny set in the first room) is pretty much done (needs a minor tweak on the killzone for the ousuls in the second part of the room) so you can always just tack on the rest of the original KS.xml file from this thread for the rest if required.

I just noticed that this is also my dodgy - fly over the mountain range to get to entrance version where the character fly's all over the place in public - which looks like its falling from a height to everyone else, but no one has yet commented on it to me (that I know of .