[crossfire] Face "overlays"

[Mark Wedel]

On 07/11/11 01:17 PM, Nicolas Weeger wrote:
> Hello.
>
>
> I've been thinking on how to show what equipment a player is actually using
> during the gameplay.
>
>
> My current idea is to add "overlays" on faces.
>
>
> It would work something like that:
> - base player animation doesn't show anything
> - the eg "armour" overlay is displayed on top of the player, to show the
> armour being worn
> - for "compound" animations (eg attacking, and thus), use the same overlay, or
> a specific overlay
>
>
> This could also be used to add effects for long-time spells, eg a red aura for
> protection from cold, and such.
>
>
> Examples:
> - base animation "fenx_player"
> - for armour, use "overlay_armour_fenx_player" if it exists, else
> "overlay_armour" for an armor with "overlay_armour" overlay specification
> - if the Fenx attacks, compound animation is "fenx_player_sword", so use
> "overlay_armour_fenx_player_sword" if it exists
> - if the Fenx cast the "rage", add "overlay_rage_fenx_player" if it exists,
> else "overlay_rage" simply
>
>
> This would of course mean many potential animations... And more face
> information sent to the client.

  My question here is does this means that each of those combos above 
(overlay_armour_fenx_player_sword, overlay_rage_fenx_player) correspond to a 
unique face/png image on the server?

  Or is there some level of trickiness going on with how the client assembles 
those faces?

>
>
>
> One other option I thought of is to use a "dynamic" face, in which server
> tells the client "face (max_face + 2) is a combination of this, this and this
> face", use this special face for the map2 command, and inform client of face
> changes when the equipment changes.
>
> This of course adds some more complicated logic.

  Answer to the above question sort of determines that answer.

  Using a unique face (max face +2, +3, +4) probably isn't as hard as one might 
think - if that face is created (and assigned to the player) when the objects 
are equipped, most of the sending logic remains the same - the only additional 
logic would be to communicate what faces make up that unique face value.

  The method used to currently inform about animation sequences could be used, 
just with the addition to say 'this is a composite face, not an animation'.  The 
one advantage I see with this approach is that a lot of the code can be re-used.

  For example, the elf equips a sword.  The server sees if there is any 
animation stacking already created that matches - it finds there is none, so it 
creates elf_sword, and at the given time, sends it to the client.  The elf then 
casts a protection spell, which adds an aura around the player.  Once again, 
server checks, finds no such animation, and creates a new one (elf_sword_aura), 
which gets sent to the client.  Now at some point, the spell expires, so now we 
are back to just elf_sword - server checks, it already has this, so it just 
updates the fact to that value, and is done.

  It would be the actual map sending code which would see if the client (which 
may not be the elf players client, but another players client) knows about that 
animation, and if not, would do the normal routine to send the animation 
information as well as information about the faces.

  Note that the animation names above are really used for illustrative purposes 
- I think when it comes time for the server to see if it is new or old 
animation, it would have to check the actual image numbers, and not go on name.

  The compositing of images probably becomes the harder case - in your example 
above for armor, this means you need different armor images that will properly 
overlay on the given race - for small and big ones, this probably does not work 
very well.

  For more generic things, like auras, size on those is not as important, so 
they probably work in all cases.