What's up, RMers?

[DerVVulfman]

For the revised version of Brenda's Visual Battlers, I did manage to get character facing directions to work.  In this, the layering system may actually function depending upon the facing direction of the battler sprite.

Above, I have two images... though I didn't separate them with a line.  OOPS.   Well, there's two, okay?

The upper shot shows enemies facing the right, and the hero holding a sword and shield facing the left.  However, the sword and shield happens to be the gear carried and not part of the original sprite.  It is a paperdoll system after all.

The lower shot shows the battlers after I used a mirror effect upon them, a common horizontal flip effect used in most animated battle systems.  And when the hero battler's sprite is flipped, the directional facing system kicked in, and used the already existing ORDER_STYLE array to determine that way the graphics are themselves layered.

The first shot had the shield drawn last, so it was atop the sprite.  But with the ORDER_STYLE layering system, the shield was drawn first and hides behind the battler when the sprite is mirrored...  Just as it should IF your battle system can recognize the use of mirrored battlers.

So I can now confirm that equipment may change in-game during battle for the actors, and the facing direction of the battlers does affect the layering as wanted and desired. I tested to see if the UserID feature from Ah-sung's Paperdoll worked, and it was a success... no alteration was even needed. So I highly doubt any need to worry about the 'T' flag to allow for dual wielding characters. Nice, eh?

But, ahhh...

Two steps forward.... two steps back.   It appears that there will needs to be more work to make the updated Paperdoll system for battlers work with any animated battle systems.  The issue is that both systems, animation and paperdoll, refresh and renew the sprite separately when changed or updated.

If the animation system is executed first, it attempts to render the battlers, and then the paperdoll will kick in... and render with the overlain graphics without the individual frame animations  But if the paperdoll system executes first, it creates and renders the sprite only to have the animation system kick on and re-acquire the original graphic... and you go back to square one.

So, some study needs take place in order to see what can be done for a 'few' systems at least.