Developer notes

TaskManager.cs

• @58 TaskManager.Pulse introduces some logic on the order of IManagers execution.

FiniteStateMachine/.

• Introduces some kind of FSM behavior. BTW State does not represent classic machine state. Classic states defined implicitly by State.NeedToRun and internal logic of State.Run method. State.Run called in a loop each time executing different branches as predicates are changing. Each State descendant looks like a whole FSM, Engine like a collection of FSMs.
  IMO Engine/State should be reimplemented with coroutines because it will:
• reduce extension overhead, it is difficult to formulate correct set of State.NeedToRun predicates
• remove unconditional State.NeedToRun evaluation on each Pulse

WoW/WowLockToken.cs

• Looks like the only application of WowLockToken.LockObject is to ensure exclusive access to config.wtf, other uses looks confusing/haze.
• Using Launcher.exe is the odd way to make async wow process start.

HBRelogManager.cs, HBRelogHelper.cs, Remoting/

• In order to add control over HB client directly from HBRelog, I need to change remoting protocol from simplex to duplex.

It was possible to start wow via cmd/bat script. The reason for that obviously is to provide the user ability to do things before/after wow is started. I will remove this option and replace it with equal functionality by providing different kind of hooks which will execute specific command per event. Examples of such events can be wow process is started, character logged in, character logged out etc.

Wow process is a resource which should be reused if possible. Resource pool had an initial state when there's no wow processes in the system. So Resource manager creates one per request. Resource manager count references and as soon count is 0 it is became free and is returned into the pool of free wow processes.