AW: [CF-Devel] Re: New races and spells.

[Michael Toennies]

>
     
      Arg: I'm getting quoted out of context as a rabble rouser here.  For the
     
     >
     
      record, I am not advocating making hundreds of custom player
     
     >
     
      faces for each
     
     >
     
      weapon/armour/race combination, or of dumping in single or two directional
     
     >
     
      faces into the player arch list.
     
     >
     
     
     >
     
      > > > I think this is a good idea.  If we got rid of the class/race
     
     >
     
      > > > face distinction and made a set of  choosable arches for each
     
     >
     
      > > > race (with some overlap when body types are similar).  Need a
     
     >
     
      > > > few more pictures here and there (some more elves, trolls,
     
     >
     
      > > > a halfling in full battle armour...maybe even a couple
     
     >
     
      > > > different dragon types, but they would be useful to reuse
     
     >
     
      > > > for npc's as well. It would be easier to have players pick
     
     >
     
      > > > from one big larger set, but I wouldn't want to see fireborn
     
     >
     
      > > > picking a halfling face, or a dwarf looking like a troll...
     
     >
     
      > >
     
     >
     
      > This is mostly a matter of available art. The current system
     
     >
     
      > was chosen simply out of practical reasons: Player animations
     
     >
     
      > for classes exist only in humanoid shape. Due to the
     
     >
     
      > lack of non-humanoid class faces, such races must stick
     
     >
     
      > with their default race face.
     
     >
     
     
     >
     
      I suggest either dropping the class faces altogether and sticking with the
     
     >
     
      current racial faces, or making the proper four directional faces
     
     >
     
      to cover a
     
     >
     
      variety of generic types for each race (heavy armoured, robed, lightly
     
     >
     
      weaponed).  Most of the class faces can double up for now and a new arch
     
     >
     
      could use the same face.  As new graphics get done, the arch can
     
     >
     
      be changed
     
     >
     
      to use a new animation.
     
     >
     
      BTW, Is there a reason that player faces aren't animated?
     
     >
     
     
     
Yes, the reason is that somewhere in the past the crossfire
animation system was broken. The player animation system don't
use the 'normal' animation system, they just hack the needed
animations in (in server/player.c - where the player char socket
input is calculated).

Thats for example the reason why the doppelganger monster is
taken out of game because this race had copied the player
animation/faces to simulate the doppelganger skill - but because
the player animation system is not anymore compatible to the
normal animation system, it does not work.

I had fixed this before i left, including a fancy extended,
fully compatible animation system which included idle,
moving & fighting animations. But the code was removed by garbled
(and broken again) because he had at this time a less understanding
about this code parts. The reason was that i fixed only the new
parts of the animation system and as he saw the old, broken parts
he thought this was from me and removed the stuff - now the code
looks good again but it is logical broken.

For Daimonin i have now finished the code and fixed some more problems
hidden deep in the system.

There are several problems in the animation code that you guys will find
out when playing with it. For example is the use of "is_animated" faked,
because this flag is automatically set when the loader.l reads in a
animation - also, the anim_speed is not set & used in all arches AND it is
chained to the object speed. But the internal "speed" value don't should
be used as animation speed because this can have a different logical
meaning.
For example can there be a fire fountain which creates all "speed" events
a fireball. But the fountain animation itself should be don't slower or
faster when you manipulate this speed factor. I cut this in Daimonin, make
the anim_speed counter be independent from the speed value. Even in normal
monster animation you will notice a better look with it.

The update of a animation in crossfire is always one frame/map update to
late.
When you play around with it, you will notice that a animation which changes
direction (for example a monster, turning fomr north to south and moving one
step down) will look for one map update in the wrong direction. That why the
code first do the move and then update the animations later.

Also, the animation system don't face external changes of the animation.
When you run for example in a friendly object, you can push it. This push
will change direction and facing of the object - and so the animation too.
But this will not be calculated with the push - this will only be updated
when the object ITSELF update his animations - what is still chained to
the speed - but paralyze for example simply add a huge factor to speed
(that was what i had wanted to change with the FLAG_PARALYZE) - so the
animation is never be changed for a pushed, paralyzed object until it
will move again. Only a example - you will find alot more of this bad
effects when you think over some spell and object effects which depends
on speed and animations.