Matenia

If you use code, you can use polyarea_water and roads, which should help general navigation to avoid water and prefer roads

Can you just use my code example and see if it works?
Another example:

ExpirationDate = 2020-11-11 18:48:30 (static point in time)
CurrentTime = 2020-11-11 18:48:20 (this obviously changes)
FullBuffDuration = 10 seconds
TimeLeft = ExpirationDate - CurrentTime (this will get lower and lower with time, at the start here, it's 10 seconds)
TimeAlreadyPassed = FullBuffDuration - TimeLeft (this is 10-10 = 0)

Now as time passes on, the result of TimeAlreadyPassed gets HIGHER and HIGHER until it reaches 10 eventually. 
So if you look at my condition in my original post, you will see that I validated TimeAlreadyPassed for GREATER THAN 2.

If you still haven't read the documentation, please do.

My solution still stands. GetTime() is a timestamp of sorts. It ALWAYS changes.
That's why you need to calculate the time that has already passed since the spell was applied, which is its full duration MINUS the in which it's going to end. And THAT needs to be larger than 2.

What do you mean, "it doesn't work"? Is there a Lua error or is your condition just faulty and never gets hit?
Because if you think about it, GetTime() always changes. You need to know when the buff/debuff started. 

Yes, you know when it expires, but you don't know when it started unless you take the duration into account. You're not calculating "timeLeft" you're calculating "timeAlreadyPassed".

 

local timeLeft = expiration - GetTime()
local timeAlreadyPassed = duration - timeLeft

if (timeAlreadyPassed > 2) then
	CastSpellByName('Simple Logic')
end

I hardcode lists and partially rely on user feedback.

Now you could parse combat log events, store the results per mob entry and maybe even serialize them. That way, you're good to go. Unfortunate though, if mobs are immune for only a few seconds and you never use certain spells anymore because they temporarily immuned thanks to a buff.

Although I guess you could write some smart detection for a "buff state" in combination with the school/spell. Spell school can be ready from spell info and combatlog iirc.

There's no official server support, so ALL subscriptions are for private servers. Options are available as per sales page.

I will be giving a discount for my products around Christmas.

Droidz will not support the retail client. It's not related to profiles.

Okay, now we know there is actually a bug. Before when you didn't tell us anything, just saying "I can't turn off lua to move", we had no info. That's what log files are for and why Droidz asks for them. You cannot debug everything on your own machine all the time. For HMP, I do the same because it's impossible t recreate someone else's conditions on hard to find bugs.

Dude, just post the log file for him. A LOT of profiles and fightclasses force enable Lua to move, because with frame lock, you get permanent game freezes in combat otherwise

You haven't even paid for WRobot, I doubt you're going to pay 40€/hour for what would amount to 200-500 hours of work, assuming you want literally every single dungeon playable in every single role the way that DungeonBuddy did.

Big no from me.

We don't know what expansion you're on. If you're on 1.12, it uses keyboard movement by default and you will need to enable CTM.

You need more hotspots in your profile. And if there are stucks, blacklist the area and it willl avoid it.

Faster machine and/or try to change the internal setting for frequency Lua events are read from wow's lua stack.

Personally I think it's from sloooow Lua processing and caused by LuaEventsWithArgs being called too infrequent, so the table gets too big. I do not unpack any tables in my code that are bigger than 50 keys.

Bit more info. Where did you get ported? Or did wRobot just close with the warning? That can be quite buggy.
Generally if you don't know what you're doing or can't risk to lose an account, you shouldn't run a bot. 

If you're worried about losing it now, don't bot on it again - just run on a different account.
Also nobody can give you specific advice for your server at all and you're generally better off NOT mentioning specifics accounts of what happened to you on what server, unless it's a thread specifically tailored to avoiding detection methods.

Battlegrounder uses the GrindingBG and FightBG class. Decompile to see what they do. Replace GriningBG with your own state if you must.
And adjust your fightclass range, then it won't try to melee people as a caster...

Seems to me you're not using the latest version. Seeing as you don't own wrobot even, it would appear I need to up the security.

Thanks for alerting me it's been cracked ?

It uses a pathfinding server, so there are no client side meshes.
If you don't disable pathing and you're on the real trial, it will path find correctly.

There is no meshes folder if you aren't using the cracked version ?

Yes. It's not possible.

You should probably point out which fight class. I believe this error occurs if the fightclass throws an exception (i.e. the fightclass thread crashes).

GoToTask is blocking, it will not stop walking unless you also pass a breaking condition to the "whileCondition" parameter.
Or use normal MovementManager.Go which is not blocking - but if you have a complete condition, it will just call MovementManager.Go over and over until the condition is fulfilled.

This is tick-based vs blocking.

Not possible without code

If that's what you want, yes you need to write a plugin or you can set up a macro ingame and use wrobot's macro settings to hit it every 30 seconds

It shouldn't crash, but also using :Click is a protected function, so you need a plugin or something that only runs that code ONCE