How can I force a fight?

[Zer0 148]

Version 1.0.0 is out

 

[Zer0 148]

Hi guys,

Although the radar works. Engaging in a clean radar fight is still quite a hassle and triggers a cascading amount of issues that I have to quick fix (blacklisting vendors and flightmasters, messing with running states...). I'm really looking to have a better, more reliable system. 

I have looked around in the forum and other places but I didn't find exactly what I wanted. So here's my question. Is it possible to add a State to the wRobot engine when the plugin initializes, and would it be a good idea? A whole new state that would be called RadarFight for example and that would have a very high priority. Does a state only run based on a set of conditions, or can you trigger one (Run(), or NeedToRun()) manually? Also what happens if two states have the same priority?

I'm getting a bit desperate here, and I'm not sure if I can go any deeper than that. The lack of documentation is starting to be a real problem, so any help will be very much appreciated.

[Marsbar 227]

I'd say states are the way to go, that way other things won't interfere. Have a look at the grinder product example. Since it's a product when it loads the Bot it adds all the relevant states and has it's own grinder state. That should be enough of an example to craft your own.

[Matenia 620]

Maybe just add your radar as its own state. That would, however, make it so the ToTown state running wouldn't allow your state to be triggered.

Like Mars said, look at the grinder product example to see how exactly Droidz' FSM works. Then take a look at my free PartyHelper plugin on how to add states to wRobot.
 

[Zer0 148]

Following your advice, I have been playing a bit with the State idea, yesterday. Both the grinder example and the PartyHelper plugin have been of tremendous help. Thank you again, both of you. Although things are getting clearer, I have a few questions and instead of running in circles and slowly losing faith for a week, I'm gonna ask directly.

FYI, I'm conducting all my tests using the Grinder engine, and occasionally the Automaton. When I start the bot; my character needs to go to Town and has enemies on its way.

Here's my observation: It seems like 2 engines are running at the same time.
Let's say engine1, which only has "NPCScanState" and which refreshes every 3 seconds or so. After I add my RadarFight state with a higher weight to it, while the ToTown state is running, on enemy detection, the RadarFight state triggers and the bot tries to attack the mob, but seems to be confused and wanting to go back to its ToTown state. Basically same problem as before.
And engine2, which has all the other states (IsAttacked, Pause, ToTown, MovementLoop etc...). After I add the RadarFight to this one with a high weight, when the bot is on its way to town and detects an enemy to fight, the RadarFight state doesn't trigger at all. BUT, if I get attacked and the weight of RadarFight is higher than the weight of IsAttacked, the RadarFight state takes over and things works perfectly.

Does that make sense to you? It seems like engine2 only checks for states to run when engine 1 is somehow interrupted. Any idea how to overcome this?

[Matenia 620]

I guess that makes sense. IsAttacked checks for enemies targeting you (or you being on theit threat list in higher expansions) and tries to fight back. Maybe activate "don't fight back" in wRobot settings?:

Also I believe NPCScanState is started with the "newThread()" method (static) on the class, so it would make sense it's running in an additional thread to start a fight. Unfortunately I don't know all the inner workings of wRobot.

[Zer0 148]

I've managed to add my own state properly and it's working well in normal traveling conditions, but during the ToTown state, even when the Radarfight state NeedToRun is True and has a higher priority than the ToTown state, it doesn't trigger (unless isAttacked gets triggered, then the ToTown state is halted, and the Radarfight state takes over, since it has a higher priority than isAttacked).

How come the IsAttacked state forces the ToTown state to pause, but not my RadarFight state? I'm trying a lot of things, but so far, no dice. Any idea?

To expand on this, it seems like during the ToTown state, the engine isn't even checking for other states, unless actually attacked. Is there a way to force a state check?

[Matenia 620]

Ask @Droidz
My best guess is IsAttacked has another thread that stops ToTown or something

[Zer0 148]

I think it is linked to this piece of code in the NeedToRun() method of the ToTown state:

if (!wManager.Wow.Helpers.Conditions.InGameAndConnectedAndAliveAndProductStartedNotInPause || wManager.Wow.Helpers.Conditions.IsAttackedAndCannotIgnore)
{
	return false;
}

So I need to work my way around that. Anyway, I shot a message to Droidz. Thanks for your insight.

[Matenia 620]

You can set Conditions.ForceIgnoreIsAttacked to true for the the duration of your state. That conditions evaluates to false then.

[Zer0 148]

Hah, pretty counter-intuitive, but smart ?. Unfortunately the problem is the same. The bot doesn't even seem to check if other states should be running and just keeps walking, even though my RadarFight state does indeed need to run (I'm checking in the log right on enemy detection).

[Matenia 620]

That's what I thought. I don't know how IsAttacked handles this, maybe the GoToTask used to get to the vendor inside the ToTown state has a exitCondition for getting in combat. 
Usually the exit condition for GoToTask is checking if the bot is running (not pause) and not being attacked. So that makes sense.

The bot SHOULDN'T check for other states while one state is still running. That's how FiniteStateMachine works. 
Maybe remove the ToTown state from the machine and build your own wrapper state that will abort the ToTown state (which should work by calling MovementManager.StopMove) if you pass/change a variable to your ToTownWrapper.

What you want to do won't really work without hacks. All of our code is more or less hacked together because we're changing wRobot's default behavior. @Marsbar, for his training plugin even removes wRobot's training state and adds his own.

[Zer0 148]

Yep. The more I dive into the bottom of the code, the more I realize I would indeed have to hack the original behavior pretty hard, which is not really my intention, mainly for maintenance reasons. I guess I'll leave it at that and focus on other things for now. Thanks again for your help.