[crossfire] server map code redo.

[tchize]

Not commenting on how should do to prevent messing up thread :)
Le Lundi 29 Août 2005 05:47, Mark Wedel a écrit :
>
     
       This is a heads up that I plan to start work on a pretty significant map
     
     >
     
      code redo.  Below are the main areas I plan to tackle.  I may do these in
     
     >
     
      smaller pieces, but the are somewhat related in that I'll be changing the
     
     >
     
      map structure itself to some extent to make this all happen.
     
     >
     
     
     >
     
       I'll send out more detailed proposals on these points, but this is a brief
     
     >
     
     outline:
     
     >
     
     
     >
     
     1) Refine move/block types.  Right now, we have 2 move types (walking &
     
     >
     
      flying). There is only 1 block type, that blocks both flying and moving. 
     
     >
     
      Extend code to allow for more move types, as well as refined blocking
     
     >
     
      (blocks walking, not flying, etc).
     
     >
     
     
     
Great :)

>
     
     2) Change/improve lighting code.  Max light radius of 4 made sense when the
     
     >
     
      map max size was 11x11, doesn't make a lot of sense when it is now 25x25. 
     
     >
     
      Look at other line of sight improvements
     
     >
     
     
     
Nice :)

>
     
     3) Add more layers to display logic, also have it handle head information
     
     >
     
      better so that the client/socket side doesn't have to do this.
     
     >
     
     
     
Needing it :p

>
     
     4) Store more object attributes in the mapcell so we don't have to look
     
     >
     
      through the list objects to see if any have that set.  Also store number of
     
     >
     
      objects (likely pickable and flying as different values) so can implement
     
     >
     
      spill over logic, make sure number of spell objects is at some reasonable
     
     >
     
      level and bail out if it gets too high.
     
     >
     
     
     
Will speed up things


>
     
       Future/down the road:
     
     >
     
     
     >
     
     5) To convey some of these changes to the client, a new protocol command is
     
     >
     
     needed.  But no reason to write that until we have data to actually send to
     
     >
     
      it.
     
     >
     
     
     
I'll opt for a complete rework of whole client/server protocol in a branch. 
This way we can easily tweak new protocol for performance and not take 
care of old protocol compatibility. Backward compatibility could come 
afterwards when new protocol is mature enough.

>
     
     6) As per other discussion about threading - moving the maps objects to a
     
     >
     
      per map list makes threading much easier.  However, above changes are
     
     >
     
      really related to mapcell and related functions, so redoing pointers
     
     >
     
      doesn't really fit in here (doing it as part of the above just makes that
     
     >
     
      more complicated).
     
     >
     
     
     No Comment. Except thread safe code should be another work :)
>
     
     
     >
     
     
     >
     
     _______________________________________________
     
     >
     
     crossfire mailing list
     
     >
     
     
      crossfire at metalforge.org
      
      
     >
     
     
      http://mailman.metalforge.org/mailman/listinfo/crossfire
      
      
     
-- 
--
Tchize (David Delbecq)
     
     tchize at myrealbox.com
     
     
Public PGP KEY FINGERPRINT:
    F4BC EF69 54CC F2B5 4621  8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
    
     
     http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
     
     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 
     
     http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050829/266e03ba/attachment.pgp