[CF-Devel] Combat animations/sound

crossfire-devel at archives.real-time.com crossfire-devel at archives.real-time.com
Tue Feb 10 02:03:10 CST 2004


Le Lundi 9 Février 2004 15:12, Todd Mitchell a écrit :
>
     
      I beg of you guys to crack open the blocking code before working on
     
     >
     
      fixes for a new clean protocol for the client.  Or at least plan for
     
     >
     
      changes.  Blocking right now is a huge handicap for both skill creation
     
     >
     
      and map making.  A simple blocking system that allows for flying over
     
     >
     
      stuff (including missiles and spells), swimming/sailing, mountain
     
     >
     
      climbing and other types of movement would be so very useful.
     
     >
     
      Being able to use a bitmask comparison instead of a simple blocked flag
     
     >
     
      for blocking movement may be the sort of thing to consider?
     
     >
     
     
     
Good point! (and don't forget the 'jump over' and 'go thru using magic'')

>
     
      Also once you decide what is 'fixed' map info you will be cutting down
     
     >
     
      on the stuff that is possible to do.  Handle with care.
     
     
No that's why i used the term 'mostly fixed'. Considering server scripting 
possibilities, *anything* in a map can change. But because grounds and 
buildings don't change often, there is no need to send them to client each 
time a building/ground enter the visual part. We could have something like 
server sending fixed part along with an always increasing 32bit timestamp and 
a check sum, so client could check at mapenter:
 - 1st if server map is same a standard map
 - 2nd if not, if the last map sent by server has changed

This would also let client show map before server send info (like suppose 
server map is standard one and if not change the visual when we get response 
form server). Anyone i don't plan to implement the new protocol in a quick 
and dirty way. i plan to submit first a detailed list of expeted behaviour of 
new protocol

The main ideas will be 'reduce bandwith usage' and 'reduce server lags'
>
     
     
     >
     
      On Mon, 2004-02-09 at 13:52, tchize wrote:
     
     >
     
      > That's why 'mostly fixed' should be choosen with care.
     
     >
     
      > Nothing. Also note that client already knows more than player (aka
     
     >
     
      > disable darkness code an see better. i know complete dark is not send but
     
     >
     
      > nearly complete dark is alaos difficult to see). The main idea is to
     
     >
     
      > prevent sending map info to client if they are the same as in released
     
     >
     
      > maps.
     
     >
     
      >
     
     >
     
      > -----Original Message-----
     
     >
     
      > From: Nicolas Weeger <
      
      nicolas.weeger at laposte.net
      
      >
     
     >
     
      > To: 
      
      crossfire-devel at lists.real-time.com
      
      
     >
     
      > Date: Mon, 09 Feb 2004 14:07:11 +0100
     
     >
     
      > Subject: Re: [CF-Devel] Combat animations/sound
     
     >
     
      >
     
     >
     
      > tchize a écrit :
     
     >
     
      >
     
     >
     
      > (snipped most parts out)
     
     >
     
      >
     
     >
     
      > > The mostly fixed part of map would be send to client only one time.
     
     >
     
      > > This would includes additionnal info like blocked squares (so client
     
     >
     
      > > can precalculate moves, and make things look softer). Changes to this
     
     >
     
      > > part of map (which may happen from time to time) will trigger a patch
     
     >
     
      > > event from server to client so map are against in sync. I am thinking
     
     >
     
      > > about using a big picture for the map background/buildings/Walls(so
     
     >
     
      > > mapmakers could design a map made of something else than squares)
     
     >
     
      >
     
     >
     
      > The thing, though, is that client mustn't know more than player should.
     
     >
     
      > Because all sources are available.
     
     >
     
      > If you send all fixed info once and for all, any hacking player will be
     
     >
     
      > able to see this fixed part from the beginning, thus having more info
     
     >
     
      > than s/he should. So they only way is to send only what the player can
     
     >
     
      > see, nothing more.
     
     >
     
      >
     
     >
     
      > Making client handle animations is an obvious simplification, and would
     
     >
     
      > even let clients disable'em if they are too heavy on their computer :)
     
     >
     
      >
     
     >
     
      > Nicolas 'Ryo'
     
     >
     
      >
     
     >
     
      > _______________________________________________
     
     >
     
      > crossfire-devel mailing list
     
     >
     
      > 
      
      crossfire-devel at lists.real-time.com
      
      
     >
     
      > 
      
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >
     
      >
     
     >
     
      >
     
     >
     
      >
     
     >
     
      >
     
     >
     
      > _______________________________________________
     
     >
     
      > crossfire-devel mailing list
     
     >
     
      > 
      
      crossfire-devel at lists.real-time.com
      
      
     >
     
      > 
      
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     

_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel
     
     
    


More information about the crossfire mailing list