[CF-Devel] RE: The journey of the attack

[Mark Wedel]

David Hurst wrote:
>
     
     
     >
     
      Could someone do me a massive favour and tell me exactly how crossfire
     
     >
     
      currently runs when a player first attacks.
     
     >
     
      I would like to be able to trace the path so that I can add a few thing to
     
     >
     
      it (like check for multiple weaponary etc). My current plan is to add code
     
     >
     
      so that the server first checks if the players has multiple weapons, then
     
     >
     
      runs the two attacks uniquely. It would be alot more efficent to only check
     
     >
     
      once for multiple weapons, then run the attack code. Code would have to be
     
     >
     
      added so that crossfire keeps track of when a player changes his weaponary
     
     >
     
      around, and would have to check again. Ideas? As the attack speed is just
     
     >
     
      the number of times it rolls a dice each time you move into a monster, the
     
     >
     
      code will not have to be modified at all. For gameplay I also intend to tell
     
     >
     
      the client where each attack is coming from. Ie Dagger: You make a
     
     >
     
      bonecrunching sound.. axe: you atomize Goblin..... This will hopefully give
     
     >
     
      players a better idea of the differences with weapon speed (thus reducing
     
     >
     
      the need to change units).
     
     
 General path is as follows:

server/main.c - process_players1 and process_players2 deals with player movement
and setting their speed.
server/player.c - handle_newcs_player - deals with reading data from socket (or
requests to do so), and moving the character.
server/player.c - move_player deals with player trying to move, which then calls
move_player_attack in teh same file.  If we can't move to the destination space,
check the destination space for a an attackable object.  If we find one, we then
call skill_attack, which finds appropriate skill and sets it up, and then calls
attack_ob, which really calls attack_ob_simple.  That function then sees if we
actually managed to hit the object and does a bunch of other stuff.

 thats the main order of thingss



>
     
      Also, I would like some help on where I should stick the code that keeps
     
     >
     
      track of how many hands a player has free. This I would assume would be done
     
     >
     
      by running through the inventory and counting how many hands. If the player
     
     >
     
      has two many hands used it will deequip the first item that uses hands.
     
     >
     
      Seems fairly simple (although I have no idea how to do it yet ;). I would
     
     >
     
      dearly love to look at the code that currently sorts through the inventory
     
     >
     
      (there used to be one in god intervention).
     
     
 Going through inventory is pretty simple.  You could look at the ring code to
see how it does it.  But one thing ring code does not do is keep track of what
is in what hand - it just knows you can have two rings equipped, so if you try
to equip another, it unequips one (probably the first one found in your
inventory).  this is a minor inconvenience (unfortunately, there is really no
good way to say what hand you want to put a ring on even if we did track what is
on what hand).

 Thinking about this, the proposed two weapon code & multiple shields will seem
to greatly complicate that.

 If I have sword and shield equipped and try to equip a different sword, should
that unequip the shield and go two weapon, or should it unequip the current
weapon I have?  Likewise, if I do try to theoretically equip a new shield, does
it replace the current one or assume I want to go dual shield?

 Thinking about this, I would strongly suggest that the first thing you should
add is two handed weapons (great swords and so on).  This will get you familiar
with the code and should require a fairly small amount of code change (ie, apply
code gets changed to unequip current weapon & shield, and likewise if you try to
equip one of those, it unequips your weapon).  This doesn't get you that far
down the attack code path, but will at least get you familiar with the apply
code.

>
     
     
     >
     
      Once I get the latest CVS the first target I have is living.c . The Code is
     
     >
     
      terrible I can't follow 3 lines of it before I have to refer back somewhere.
     
     >
     
      If Mark hasn't already, I will go through comment it throughly and move
     
     >
     
      things like varibles from the start to the place that they are used. For
     
     >
     
      instance in the version that I have, 7 or 8 varibles are defined at the
     
     >
     
      start, but aren't used until line 1250 and aren't really needed anyway (in
     
     >
     
      particular S). In that same area (line 1250 or so) there are formulas that
     
     >
     
      appear to have subtractions that can be removed from the fraction. I assume
     
     >
     
      they are inside the fraction because the coder wanted to use integers
     
     >
     
      instead of floats but in this case it would be faster to use floats anyway.
     
     
 Err, this is tricky.

 You can only declare new variables inside a { grouping, and they only survive
(accessible) within that group.

 Standard ANSI C does not allow arbitrary declaration of variables wherever you
want them like C++.  Personally, I prefer for variables to be declared at the
top of the function unless they are really local to a small area - at least if
I'm looking to see where a variable is declared and how its declared, I look at
the top of the function first.

 some formulas may be broken up like that simply to make the formula clearer to
read.  For example, if you take:
    K=1 + M/3.0 - W/(3*M2) + op->speed/5.0 + D/2.0;

 And expand M, W, M2, and D, you may now get a three line formula that is much
harder to read (for example, doing a quick glance, I can see that D is basically
a bonus for high dex, and M and M2 are adjustments based on character
strength/carrying caacity, and W is weapon weight).

 Also, any good compiler/optimizer will collapse it and automaticaly remove the
unused variables. 

 I will strongly state:  Write code for clarity.  Performance is certainly an
issue, but in most functions, the compiler will probably do as good a job as you
can do.  The real thing is to beware of things that can't be optimized very wall
and do take time (like traversing object lists)