Node Pirating - skip nodes being harvested by others?

[mandoleth]

Does the "node" object have any attributes we can scan just prior to harvesting? If the node has a decreasing available amount, one could assume it's being currently harvested.

I noticed the bot walking up to a player who was already gathering and I had to stop the bot before it started humping their leg.

[Administrator]

No, there is no way (that I'm aware of) to tell if another player is harvesting that node unless you gather that information from the player doing it (not from the node itself), which this bot does not do.

[mandoleth]

Hmm. All right, then what would be the best way to detect the proximity of the nearest player within the harvest() method? Is there something like getNearestDoucheBag().getDistanceTo() in perhaps more complex terms?

[mandoleth]

I think I found a way to program some "avoidance" into the lua scripts. In player.lua, line 96

-- normal harvesting
if( mousePawn.Address ~= 0 and mousePawn.Type == PT_NODE
and distance(self.X, self.Z, mousePawn.X, mousePawn.Z) < 150
and database.nodes[mousePawn.Id] ) then
return mousePawn.Address, mx, my, mousePawn.Id;
end

I'll be adding another check for a different object type to detect another player within the mouse's scan.

I'm thinking I will attempt the following:

1. Add a variable for configuration regarding allowable paranoid distance. That distance is basically what we deem as a safe buffer of space between the bot and another real player RIGHT BEFORE harvesting a node.

2. If that safe distance buffer check isn't met, we are "paranoid," so we don't harvest and move to the next node.

Reasoning - I don't want other players getting annoyed that I rushed right in front of them to harvest what they were about to and then report to a GM that I'm botting.

In a related issue, I think I can include some basic "human" response capability in the bot via Whisper if contacted by a GM. People have been banned because the bot won't respond to one. There are many open source AIs out there, I just need a good profile for the chat bot to run from, then expose the remote call to lua somehow. I'll cross that bridge when I come to it, if ever.

[mandoleth]

Not sure if anyone is needing this functionality or gives a crap but I'm pretty much done coding the check for players in very close proximity to the harvest node. I'm testing tonight and perhaps I'll have the paranoid other player check working. If anyone's interested please let me know. Otherwise I'll keep it to myself

[Administrator]

How does it work? How are you checking if a player is nearby? I can only assume you're trying to cycle targets and test if it's a player. That would work, but not well.

[mandoleth]

A scan is performed, slightly wider than the scan for the harvest node and looks for player objects within a certain distance. It's assumed that players harvesting that particular node will be within this particular area. If a node is found AND a player is found AND that player is within a certain distance (going to have to monkey with that integer some, I'm sure...) then we do not attempt to harvest.

Actually I have the player.lua in modified form if you want me to attach it. I've never written in lua before so... Java and other languages have been my thing so far.

[mandoleth]

I have not had time to test this at ALL but this code should explain the idea. One major change I have made is by extracting the scan function from an inline method to a regular function. Other than that I just call scan twice with some added parameters - once for PT_NODE and once for PT_PLAYER type.

There may be compile problems since I'm new to LUA but I'll work them out once I have time to test this, hopefully tonight.

http://dl.dropbox.com/u/2584982/player.lua

[useless]

I am actually very interested in this, I've noticed the same thing.. The bot will run right up to a player and continuously try to harvest from the same resource as another player for like 15-20 seconds before moving on. I've had other players type /wave to me which breaks their harvesting for just long enough that I sneak in and start stealing their resources which really pisses them off. Luckily I was sitting there when it happened and was able to END the macro and say "Sorry, I wasn't paying attention".

I was thinking something very similar to your implementation, although there has to be a way to do it without scanning twice - that's such a waste of resources, and the pauses that are introduce by scanning make your character look botted. How many actually players do you see running to where a resource USED to be and pausing for 1-2 seconds then running to another resource that USED to be there and pausing for 1-2 seconds.. If we could do it without pausing at all it'd be much better...

[mandoleth]

I agree - yes the player could be detected within the same scan if the scan were wider. I scan twice because the player may be a distance from the node that the first scan won't detect.

The *only* reason I didn't alter the original scan was because I felt that altering the author's code to that extent would "break" too many assumptions made in the configuration and expected behavior, causing an endless number of workarounds.

All that said, the length of time and speed of scanning is configurable, thanks to the original author.

[mandoleth]

one other reason I didn't detect people within the same scan - the scan is such that it moves the mouse around "until..." Therefore if I were to try to detect two objects within the same scan, I couldn't be guaranteed to detect both objects unless I scanned for a very long time, ignoring the node or player until I were sure that the other object didn't also exist.

The ideal future solution would be to start scanning the node AS the bot is running up to it and do so until the bot hits the waypoint at which time the harvest can immediately begin. This would also provide the ability to scan for players BEFORE the bot sits on the node they are harvesting, which I think looks a little odd.

But - baby steps.

[mandoleth]

Working! or at least... compiles and runs the paths without breaking anything. I have yet to come across another player so I don't know yet if the first scan for player pass works. We'll see. But at this point at least I can modify it until it DOES properly scan.
http://dl.dropbox.com/u/2584982/player.lua

[mandoleth]

Having some trouble getting the second scan to run (or at least I can't see the pass executing twice,) but I'm working on it. If anyone's looked at the code and knows why - lemme know!

[3cmSailorfuku]

How does it work? How are you checking if a player is nearby? I can only assume you're trying to cycle targets and test if it's a player. That would work, but not well.

Im not sure what the target struct contains in RoM, but doesn't it also usually contain which animation/action the target is doing right now?
After calculating the distance to each cycled target (Since you can't enumerate players in this case) and determine their action (Harvesting in a 20yrd distance for example) you could skip the nearest node.
Kind of a ghetto solution though.

It's pretty much the same what mandoleth seems to be doing, but in his case he can't 100% tell if the player near him is harvesting, idling or engaged.

[Administrator]

Im not sure what the target struct contains in RoM, but doesn't it also usually contain which animation/action the target is doing right now?
After calculating the distance to each cycled target (Since you can't enumerate players in this case) and determine their action (Harvesting in a 20yrd distance for example) you could skip the nearest node.
Kind of a ghetto solution though.

Yes, this should be possible. It would work, but could also experience some problems due to RoM's goofy targeting.

[mandoleth]

Yep. Scan is working now in my code... I had multiplied outside the window. Kind of a bad thing. If the scan determines that the other player is within a few ticks of the node, it's safe to assume they are or will be harvesting. Just an idea - it's not perfect by a long shot, but it's a beginning. Maybe there are ways to improve it.

[arntom]

can u upload your latest *.lua, that i can compare the results
thank you

[mandoleth]

http://dl.dropbox.com/u/2584982/player.lua

But - I must widen the scan a bit before it's going to detect much.

[mandoleth]

Looks like arntom has made some great fixes in player.lua... he or I will be posting soon. Nice...