I have not worked on it for a 2 months now, and it is not completely as i wished it to be. There are still lots of improvements possible. But I stopped playing archmage, and lost the drive to work on further improvements. If anyone is interested in further development, email me, i might consider giving the complete code. Including other stuff in development, such as the "calculate-back-tool" and the "battle simulator", which are still in a (very) premature phase.

A large source of trouble is detecting the real "owner" of a unit in the battle flow, when allies have send the same type of unit that the invader/defender already has. I have been trying to solve many cases, but in many cases it also stays unresolved.

Another big source of trouble is the fact the in the battle report the "engage" part is maximally 45 lines long. In battles with many heroes, that means that a lot of information is missing (hero capacities, reinforcements send by allies, pre-battle kills).

From version 1.0, some new terms have been introduced (in the "Army Peformance" part):

cumulative attack power.This is the sum of all attack power an army has (number * attackpower), including secondary attacks, additional strike and counter.
attackpower/netpower. Just what it says. As far as I have seen, this figure is quite a lot depending on the color. Green and White seem to have quite a high figure for this (from 15 up). Black a low figure (6 or 7 is not bad).
effectivity. Defined as "netpower killed"/"cululative attack power".

Base accuracy is 30%. Non-flying and non-siege units have 20% base accuracy during a siege (regular attack = also 30%).
Averaged resistances. In the accuracy calculations, the attacktype resistances of a unit are averaged, which seems to be right. That means that on a ranged-magic attack, the resistance of the defending unit is the average of the resistance to ranged and the resistance to magic.
Damage reduction. There is also a damage reduction factor if units have Beauty, Swift, Scales, Charm and/or Fear. The reduction factors values mentioned in the encyclopedia for these, proved to be wrong for some. In the calculations, my own derived figures are being used.
items and spells. Items and spells used can have a large impact on the "accuracy", their effect is not incorporated in the calculations. I have figured out the effect of many spells and items using this battle report analyzer. You can do the same if you wish. It is part of the fun...
heroes. Some heroes also have large impact on accuracy. Also these effects are left out of the calculations.
damage residu. There seems to be something like a "damage residu": a single unit can lose some hitpoints, but not enough to be killed. The next time that stack is attacked, less damage is needed to kill a single unit. This can explain that a single ultimate is sometimes killed by a small stack.
This effect confuses the "corrected accuracy" calculation (no corrections for this are being made).
random effect. Some attacktypes have a random penalty on accuracy. For example, melee attacks never have the full 20% or 30% accuracy.
fatigue. There is a fatigue penalty on accuracy after each attempted counter and primary attack of 15%
absolute and relative reduction. It should be noted that some things have an absolute effect on accuracy (like "Satchel of Mist", reducing base accuracy with 10 percent points to 20%), and others have a relative effect (like fatigue: 15% fatigue reduction means multiplaying accuracy with 0.85).

Attack order. In the previous version of the battle analyzer, it was supposed that the attack order of units with the same initiative reflects the battle power of those units. This turned out to be a wrong assumption. The attack order of units with the same initiative is determined by stack number (the order of the units as shown by stack-organizers). The unit number estimations that were based on the faulty assumption have been removed in this version.

basic rule (#1.) Attack the highest stack that has not been attacked, and which you can attack (ground-flying is impossible). If no stack has been found by this rule, go to rule #2.
additional rule (#2.) Ranged stacks *always* attack the highest opposing stack.