its easy to check for engine calls during an EndScene call so
set a simple flag to true when thread enters EndScene and then simply check this flag in engine calls like DoString
fraps and co will maybe hook EndScene too but they will never call a wow function ; )
That's a more fundamental problem that has nothing to do with the hooking of EndScene.
A simple stack-trace is effectively doing the same thing, just on a more general level, and it will catch the bots that run externally and inject threads too.
What you're proposing has nothing to do with actually detecting the hook on EndScene, it's detecting calls to engine functions, something ENTIRELY different.
It's quite possible to call engine functions in a way that will defeat both the check you're proposing, and the more general check I proposed.
By the way, if implementing a FSM (Finite State Machine) to my bot code would I have to keep a vector of states, and after say 60 frames or so (FrameCounter % 60 == 0) 'Pulse' the FSM Class, causing the vector entity with the highest priority to be 'executed'? More so, how would I go about processing lua functions and such from an FSM based on the 'pulse' of endscene?
By the way, if implementing a FSM (Finite State Machine) to my bot code would I have to keep a vector of states, and after say 60 frames or so (FrameCounter % 60 == 0) 'Pulse' the FSM Class, causing the vector entity with the highest priority to be 'executed'? More so, how would I go about processing lua functions and such from an FSM based on the 'pulse' of endscene?
AFAIK, this is not an FSM you're talking about. It's a modified priority list of behaviors.
Standard FSM's don't have "priorities;" they just have states and transitions.
As to HOW to do this lua call, see the other posters' replies.
The only time an FSM would consider the "priority of a state" would be when determining which state to transition too, e.g. should I heal or should I take another swing at the monster? A well designed FSM using "priorities" would actually be an FSM with bounded evaluators, i.e. each state has a fixed list of evaluators it uses when considering which state to transition to next.
What the OP describes is a sort-of hybrid GOAP/evaluator-goal system. Behaviours have a very definite meaning within a GOAP/FSM/AI framework and a well-designed system would never just execute a naked behaviour based purely on a priority. You could do it, but it would be bad design that will bite you, very hard, in a soft part of your anatomy sometime later.
Bookmarks