SolarStrike Software

Posted: **Fri Jul 13, 2012 7:25 am**

I'd like to have some variables that will have global scope, while a waypoint script is running.

As far as I understood, the LUA code that can be added at each waypoint is treated as a "local function".

I found this in the wiki:

Code: Select all

self.free_field1 = nil;				-- free field for user use
self.free_field2 = nil;				-- free field for user use
self.free_field3 = nil;				-- free field for user use
self.free_counter1 = 0;				-- free counter for user use
self.free_counter2 = 0;				-- free counter for user use
self.free_counter3 = 0;				-- free counter for user use		
self.free_flag1 = false;			-- free flag for user use
self.free_flag2 = false;			-- free flag for user use
self.free_flag3 = false;			-- free flag for user use

I tried to use this, but it seems "self" is not valid in waypoint code. I changed it to:

Code: Select all

player.free_flag1 = false

which seems to work so far.

But what should I do, if I need more variables? And I'd like to give them more meaningfull names.

Maybe define a new class holding my variables and store such an object in one of the player fields?

Other solutions?
---
Next question:

Sometimes it happens that the scripts targets a mob, that is behind an obstacle. After several
failed attacks it cancels this target and looks for a new target. It happened several times to me,
that my script ran into a situation, that there were 3 mobs that were behind obstacles and so
the script did loop though these 3 mobs forever.

I was thinking to put mobs onto a "black list", if they cannot be attacked. When scanning for a new
target, the mobs on the black list should be ignored. The black list should be cleared when reaching
a new waypoint.

Where should I put such code?

Thx for any comments

Posted: **Fri Jul 13, 2012 11:59 am**

Question 1: Variables and functions are concidered global unless specified otherwise. So if you want to have global variables, make something up that is more relevant than those you used. Just make sure it is likely to be unique.

Question 2:This is a known issue that just hasn't been addressed yet. The main reason I never fixed it was because I was never completely happy with the ideas put forth. Most of the ideas involved completely ignoring the mobs until some point in the future. I've seen many situations were it would ignore a mob behind an obstacle then move to another position to attack another mob. After killing the second mob it would retarget the first mob and, because it is at a different angle or maybe the mob moved, it was able to kill it. Most ideas would exclude this from happening which I didn't like.

Your idea has been mentioned before with the list being cleared at different times but I had an idea recently. What if it keeps adding mobs to the ignore list until it successfully attacks a mob, then it clears the ignore list. Then if any of those initial mobs are in range it can try and attack them again. That's the way I would have done it.

As to where to put the code, the bot files would have to be modified and would affect a few functions.

1. player:fight(), where it saves the mob address in the ignore variable, would need to be changed to adding to a list of ignored addresses.
2. evalTargetDelfault would have to compare the address to a list of ignored addresses instead of just the one.
3. If you do it my way, the point in player:fight() where it first registers damage (not sure where that is, haven't looked) you would reset the ignore list.

That's off the top of my head. I'm not sure if anything else would need changing.

SolarStrike Software

Some Questions

Some Questions

Re: Some Questions