What's up, RMers?

[DerVVulfman]

Well, more work was accomplished.

I didn't fully think how to handle the horizontal mirror effect all that much... how to test if the battler was mirrored or not.  I totally forgot that the 'battler' data didn't contain any mirror effect flags, that it was only flagged in the 'Sprite' class itself.  So there was nothing like

      if @active_battler.mirror == true

or anything.

And this was needed for the use of the ORDER_STYLE arrays to determine the order in which all the sprite graphic layers are applied.

Oh, make no mistake.   I resolved the issue.  I did it before with a very simple routine found in AnimBat!  (formerly Animated Battlers)... whereby I made a method within the Spriteset_Battle class just to loop through all the battlers (both actor and enemy) to see if any one of the sprites in the spriteset WAS mirrored.  Heck, the one from AnimBat! was written so well, I just copied it.  There will be absolutely no conflict with the method if this paperdoll is used.

So, the order of the graphic layers is worked out!

So....  I have two more things to work on for this capability to continue.

1.  The actual implementation of the paperdoll overlay on enemy sprites.  This should not be hard as most of the Ah-Sung modules seem to work or are compatible.
   
2. This currently doesn't account for [Enemy Transform] which allows the battler to change its current graphics.
   

That took... some time.

The method I wrote to acquire the 'comments' from the Troops page had to be expanded to look for the code  identifying the Enemy Transform system.  And I had to come up with some format that would be acceptable, especially since the system will sort all the commands.

So while the arrays generated for the paperdoll layering reads as:  battler, slot, item....

The structure for the Enemy transform will be added to it as: battler, -1, new_ID

This suggests that all of the arrays sort on the battlers first, then the 'enemy transform' reads before any slot values, and then...   Well, nothing should matter at that point.   And as to the value of new_ID, that would be the new enemy ID that the battler will be using.

---

Now, for the readers to wonder... What the heck do I need to get the Enemy Transform stuff, or get the ID of the newly changed enemy, here's why.

The layering system allows you to have layers on both sides of the character sprite.  If the hero or enemy is facing the left, the sword may be drawn first and then covered up by the hero, and then the shield last... covering part of the hero.   But if the hero or enemy is facing right, then the shield is drawn first, then the hero, then the sword.

In essence, I need the actual filename (and hue) of the battler when it comes to the rendering process.

However, the comments and Enemy Transform command are fully gathered before the actual ENEMY TRANSFORM effect is executed.  So I needed to be able to get the Enemy Transform data at that very moment.  If I didn't acquire the Enemy Transform data, the system would THINK the battler was still the original one when the rendering data was gathered.

BIG OOPS averted!

---

Now a bunch of my code for all this hot garbage is in the Scene_Battle class.  That is not desired, and I do eventually want to move it into Sprite_Battler where the rest of the content is residing.  It will take time, but it will move there eventually.