Allmost foolproof KS run

[BillDoorNZ]

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.

I remember seeing the 'line through poly' test method years back (and implemented it somewhere once) but had since forgotten it Solves the problem much more generically, although I'm not sure that we really need it - worse case, solve the problem with multiple rectangles - but then thats just painful as the evalTarget stuff would then need to check against multiple rectangles and will start to get very slow I would imagine.

I can't see any reason why the 'killzone' concept can't be generically added to the bot (as you mentioned) where it gets used if there is a killzone, or ignored if there isn't one.

From all my testing, it certainly solves a lot of targeting through walls etc problems.

[rock5]

Ok I'll look into adding it. I have a few decisions to be made.

I'm looking to add 2 functions for this, the pnpoly function and one to set the killzone table.

1. Should the name of pnpoly remain "pnpoly", maybe as a nod to the original author, or should we rename it to something clearer? What should it be named? Maybe "PointInPoly"?
2. Should it be a global function or local? I'm thinking there could be future uses for it so it should be global.

I like the word "killzone" so I thought I'd use it in the "set" function, maybe "SetKillZone(_table)"?

I just had another idea. Maybe we could have SetKillZone accept waypoint files as well. So instead of using createpath to create a temporary waypoint file to extract the coordinates to use with SetKillZone, you could name it KSroom1.xml and then do

Code: Select all

SetKillZone("KSroom1")

So it could accept a table or a waypoint file. How does that sound?

[BillDoorNZ]

Ok I'll look into adding it. I have a few decisions to be made.

I'm looking to add 2 functions for this, the pnpoly function and one to set the killzone table.

1. Should the name of pnpoly remain "pnpoly", maybe as a nod to the original author, or should we rename it to something clearer? What should it be named? Maybe "PointInPoly"?
2. Should it be a global function or local? I'm thinking there could be future uses for it so it should be global.

I like the word "killzone" so I thought I'd use it in the "set" function, maybe "SetKillZone(_table)"?

I just had another idea. Maybe we could have SetKillZone accept waypoint files as well. So instead of using createpath to create a temporary waypoint file to extract the coordinates to use with SetKillZone, you could name it KSroom1.xml and then do

Code: Select all

SetKillZone("KSroom1")

So it could accept a table or a waypoint file. How does that sound?

Definitely global - can definitely see that function being used in other places.
I reckon PointInPoly is a good enough name - meaningful enough so that anyone who reads it will understand what it does. I really like the idea of being able to use waypoint files for the polygon too, would allow users to keep it all relatively separate and modularised.
One other function that you might consider adding is a simple helper called ClearKillZone() - just so there is a 'standard' way of clearing it (rather than SetKillZone(nil) / SetKillZone(0) / SetKillZone({}) ...) and would also act as an extension point later on in case anything else needed to be done at the same time.

[rock5]

Ok that's all good but I'm not sure what you mean by this

would also act as an extension point later on in case anything else needed to be done at the same time.

I'm adding a "GetKillZone" function too.

[rock5]

Ok this is what I've done.

- Added functions PointInPoly(), SetKillZone() and ClearKillZone().
- The global variable that holds the kill zone table is called TARGET_KILL_ZONE. I'm not sure this is right. Variables in caps are usually constants. Actually, maybe I should add the variable to the __WPL table as the kill zone would be specific to the waypoint file. That way the kill zone gets reset when loading a new waypoint file without having to do it manually.
- Added check in evalTargetDefault that takes into account aggro as well.

Edit: Actually maybe SetKillZone and ClearKillZone should be __WPL functions.

[BillDoorNZ]

Ok that's all good but I'm not sure what you mean by this

would also act as an extension point later on in case anything else needed to be done at the same time.

I'm adding a "GetKillZone" function too.

What I meant by this is that if later you find there is a need to do other stuff when clearing out the killzone poly, then you will already have a function in place (that should be the only way that people clear our the killzone) that you can 'extend'/'modify' to add to.

Adding the to the _WPL is a good plan too - as you say - it handles the changing of waypoints automagically too.

[rock5]

What I meant by this is that if later you find there is a need to do other stuff when clearing out the killzone poly, then you will already have a function in place (that should be the only way that people clear our the killzone) that you can 'extend'/'modify' to add to.

I think I see what you mean but I don't think ClearKillZone should ever have anything but SetKillZone(nil) in it. Any code you want to do when clearing the killzone table should be placed in SetKillZone. After all, people might still use SetKillZone(nil) or whatever and you don't want them to miss out on any necessary code. At the moment there is a section in SetKillZone that looks like this

Code: Select all

	if _zone == nil or _zone == "" or (type(_zone) == "table" and #_zone == 0) then
		self.KillZone = {}
		return
	end

We could always add extra code in there if we wanted.

[BillDoorNZ]

What I meant by this is that if later you find there is a need to do other stuff when clearing out the killzone poly, then you will already have a function in place (that should be the only way that people clear our the killzone) that you can 'extend'/'modify' to add to.

I think I see what you mean but I don't think ClearKillZone should ever have anything but SetKillZone(nil) in it. Any code you want to do when clearing the killzone table should be placed in SetKillZone. After all, people might still use SetKillZone(nil) or whatever and you don't want them to miss out on any necessary code. At the moment there is a section in SetKillZone that looks like this

Code: Select all

	if _zone == nil or _zone == "" or (type(_zone) == "table" and #_zone == 0) then
		self.KillZone = {}
		return
	end

We could always add extra code in there if we wanted.

The reason I tend to put that stuff in is that you can then use them as a place for events. e.g. onKillZoneChanged(_newKillZone) that can then be trapped elsewhere. On my system I changed the waypointList.lua file to add an onUnload() event so I can do stuff when the waypointlist changes (set mobs & friend list back to what it was, set Kill_Stealing off again, set the onLeaveCombat event handler back to one I had overriden ...).

e.g. My waypoint for quest 422580 (Those Pesky Bears - in Savage Lands):

Code: Select all

<?xml version="1.0" encoding="utf-8"?><waypoints>
<onLoad>
	quest_Id=422580;
	quest = __QL:getQuestById(quest_Id); --__QL is a QuestList class that loads the quests from a database
	quest:update(); --asks ROM for updated info on quest

	quest_oldTargets = settings.profile.mobs;
	quest_oldFriends = settings.profile.friends;
	settings.profile.mobs = {};
	settings.profile.friends = {};
	Friends_Add(GetIdName(102253)); --skippers
	Mobs_Add(GetIdName(102257)); --bear
	
	printf("Starting waypoint for Quest: "..quest.Name.." ("..tostring(quest.Id)..")\n");
	redirectToWaypointTag("start");
</onLoad>
<onUnload>
	settings.profile.mobs = quest_oldTargets;
	settings.profile.friends = quest_oldFriends;
</onUnload>
	<!-- #   0 --><waypoint x="6268" z="21125" y="173" tag="start">
		PickupQuestIfIDontHaveIt(quest); -- if I don't have hte quest, then target the npc, talk to them and get the quest.
		
		TurnInQuestIfComplete(quest); -- if quest is complete (same turn in npc as starter npc) then hand it in
		if (quest.Completed) then
			redirectToWaypointTag("finish"); -- I have to have a finish tag to skip the looping and revert back to my wander waypoint - my code assumes that at last waypoint = finished
		end;
</waypoint>
	<!-- #   1 --><waypoint x="6430" z="21088" y="181"></waypoint>
	<!-- #   2 --><waypoint x="6435" z="20977" y="194"></waypoint>
	<!-- #   3 --><waypoint x="6494" z="20987" y="197"></waypoint>
	<!-- #   4 --><waypoint x="6549" z="21133" y="182"></waypoint>
	<!-- #   5 --><waypoint x="6536" z="21195" y="181"></waypoint>
	<!-- #   6 --><waypoint x="6621" z="21220" y="183"></waypoint>
	<!-- #   7 --><waypoint x="6730" z="21331" y="218"></waypoint>
	<!-- #   8 --><waypoint x="6794" z="21496" y="219"></waypoint>
	<!-- #   9 --><waypoint x="6792" z="21608" y="222"></waypoint>
	<!-- #  10 --><waypoint x="6735" z="21580" y="218"></waypoint>
	<!-- #  11 --><waypoint x="6688" z="21463" y="221"></waypoint>
	<!-- #  12 --><waypoint x="6609" z="21386" y="215"></waypoint>
	<!-- #  13 --><waypoint x="6350" z="21345" y="165"></waypoint>
	<!-- #  14 --><waypoint x="6223" z="21263" y="159"></waypoint>
	<!-- #  15 --><waypoint x="6140" z="21169" y="169">redirectToWaypointTag("start");</waypoint>
	<!-- #  16 --><waypoint x="6256" z="21098" y="175" tag="finish"></waypoint>
</waypoints>

[rock5]

Nice idea, the onUnload, but I still don't get the point. Anywhere you use ClearKillZone() you can use SetKillZone(). If you want to set some sort of marker that the kill zone has changed, you would do it in SetKillZone. ClearKillZone() will always just have "SetKillZone()" in it.

I think we are going in circles. Just know that I'm adding a ClearKillZone function. So far I have

__WPL.KillZone = {}
CWaypointList:setKillZone(zone)
CWaypointList:clearZone()

It's working nicely. Strangly it worked the very first time I tried it. I marked out and area around some mobs for the kill zone then created another waypoint file that circled that area in a bigger circle and loaded the kill zone in the onload.

Code: Select all

<onLoad> __WPL:SetKillZone("killzone") </onLoad>

It ran around the kill zone ignoring all mobs except the ones in the kill zone.

[BillDoorNZ]

nice

I'm not overly fussed on HAVING to have the event stuff, thats just a habit of my own

Was thinking about it more last night, might be worth adding a second option to turn the killzone into a exclude_killzone so that the bot will run around and kill anything NOT in the killzone

Would be useful for scenarios where the killzone poly needs to be very complex due to a couple of areas you want to avoid??? dunno

[rock5]

Was thinking about it more last night, might be worth adding a second option to turn the killzone into a exclude_killzone so that the bot will run around and kill anything NOT in the killzone

Good point. I'll think about it.

[bruenor9]

iM A MAGE druid. umm Im looking through the script and it looks like it was suppose to cast recover when hp is low. It does not cast recover at all.

[bruenor9]

Alright got it working but it gets stuck too much and closes after 10 tries. How to fix that?

[lisa]

Is your KS run getting stuck running into walls?
Does the bot walk off a balcony and it isn't smart enough to walk back up the stairs?

Then you need the new and improved onload section to deal with these Unsticking issues, just 5 easy payments of $1,111,111 and you too could enjoy the peace of mind of knowing your bot will run KS for hours on end.

We have a special offer for our readers today, the first 1,000 people to read this will get this code absolutely free of charge, yes that's right you get the code and pay absolutely nothing.

Code: Select all

function unStick3()
	if getZoneId() == 6 then
		__WPL:setForcedWaypointType("RUN")	
	else	
		sendMacro("LeaveParty();");
		waitForLoadingScreen(); 
		yrest(3000)
		player:update();
		__WPL:setWaypointIndex(__WPL:findWaypointTag("rerun"));
	end
end

Just add that to the onload section of the WP, Obviously it uses the tag "rerun" so if your KS version doesn't have that tag then you will have to edit it with the tag you have or add the tag in.

Or if you are really lazy you can just use this WP designed specifically for M/D chars.

KSmagma.xml

Mage/Druid

(15.34 KiB) Downloaded 395 times

--=== Note ===--
1. This is designed to be used with a pet using pet perfume, the bot won't loot on it's own.
2. It uses the addon Invite Last Group for party invites
3. Buy honor scrolls for optimal G/H
4. It doesn't kill bosses
5. It uses the userfunction to set window
6. It uses the fly hack userfunction to fly over bosses
7. It is designed for solo killing, not with another char tagging along for the ride
8. It assumes you have all 6 inventory bags

If you don't have all the things mentioned then you should get them lol


This is the code for 30 day pet perfume for usage in your profile.

Code: Select all

	<onLeaveCombat><![CDATA[
	if not player:hasBuff(503479) then -- pet perfume 30 days
		inventory:useItem(204514)
	end	
	]]></onLeaveCombat>

This is 7 day version

Code: Select all

	if not player:hasBuff(503479) then -- pet perfume
		inventory:useItem(207582)
	end

Weird how the buff id is the same lol

[bruenor9]

uuh, woh lisa. Thanks. Appreciate it a lot. Who does the cheque go to?

[savvoulis_21]

i have a problem with the waypoint!! when it finishes the run and go to sell the items, it doesnt sell them instead it buys items! plz help me!

thank u

[lisa]

i have a problem with the waypoint!! when it finishes the run and go to sell the items, it doesnt sell them instead it buys items! plz help me!

You need to set up your profile to sell items

Code: Select all

		<!-- Auto selling options when used with player:merchant -->
		<option name="INV_AUTOSELL_ENABLE"	value="true" />		<!-- true | false -->
		<option name="INV_AUTOSELL_FROMSLOT" value="15" /> 			<!-- 1 = bag 1 slot 1 -->
		<option name="INV_AUTOSELL_TOSLOT"	value="180" /> 			<!-- 30 = last slot bag 1 -->
		<option name="INV_AUTOSELL_QUALITY"	value="white,green,blue" /> 	<!-- white,green,blue,purple  -->

[savvoulis_21]

thx a lot lisa!!!

[jasn]

Thanks Lisa for your WP file.

But it seems i have an error on it or my character cant count.
Every time i get the "countmobs" part in the file it errors out.
Is there a function that i´m missing or something else?

[rock5]

Probably refers to my CountMobs userfunction that I've posted around the forum. If you had done a search you could probably have found it.

Anyway,I've decided it's time to make a page for it. So you can download it here.
http://www.solarstrike.net/phpBB3/viewt ... 781#p36781