clintbellanger/flare-engine — pull request #382 by stefanbeller (2013-02-26 00:31:13+00:00)
Title: Revert "Merge pull request #378 from stefanbeller/master"

Yes the transformation is broken by the the StatBlock reorganisation.
While I was refactoring it, I came to the conclusion that the refactoring would be very huge.

So as of now (or before the initial statblock reorganisation) it was very easy code as Justin pointed out, as everybody could just use the StatBlock. Now that it got separated, the stats are no longer just plain there in an Entity, but are a class of their own, being operated on using a pointer.

When thinking initially about the separation of StatBlocks I did not take into account that we had transformation. At rewritign the Avatar I messed up the pointers of the stat blocks (hero_stats, charmed_stats and the stats derived from Entity),
so I'd expect I'll take a little more time to get it smooth and fully working again.

I still think it is a viable way with separated StatBlocks, but specially the Avatar class needs conscious attention at the rewrite and some time, which I probably do not have in the next days.

So this pull request is reverting all the changes applied to stat blocks, so the state is a usable state.
(We don't want to have huge changes close to a release anyway ;)

I'd like to apologize to @hean01 @dorkster and @makrohn for introducing merge conflicts.

Once I have more time to figure it out exactly, I'll rewrite the StatBlocks.

My plan as of now is this (for reference purposes):

The StatBlock is an abstract base class, so it cannot be instantiated directly, but you can only create a subclass (AvatarStatBlock, NPCStatBlock or EnemyStatBlock).

The Entity class needs to have a pointer to a StatBlock and an abstract function ```statBlock()```. (The Entity class is already abstract, so it's no big deal) The deriving subclasses would need to implement the statBlock function and return the specific stat block depending on its own type, i.e. the Avatar class will return an AvatarStatBlock, the NPC class will return an NPCStatBlock when calling that function.

The problem with the transforming of the Avatar could be solved similar as it is now:
There will be 2 pointers ```charmed_stats``` and ```hero_stats``` which will carry two independent StatBlocks of different type (Avatar and Enemy). The actual ```stats``` pointer of the Entity class would just need to point to one of both. This yields the advantage to not have to copy over so much data as we're doing now. Now we have 3 StatBlocks (```charmed_stats``` and ```hero_stats``` and ```stats```), but operate only on ```stats```. During transforming, one of the shadow copies will be taken and some of its data are copied over to the stats block.

If done right with the pointers, we would not need to copy anything, because of addressing always the right data anyway.
(hero_cooldowns, slots, etc could stick to the Avatar block all the time, but movement, speed, resistances and such would be loaded from either of both blocks depending on the transform state.)