[CF-Devel] new release: CFJavaEditor 0.971

[Michael Toennies]

Also the old methode needs some bytes to submit
information, the bandwith is not a problem here-
how much is this spell invoked?

To bind the color information on xbm and face is ugly and bad.

Just send a type information to the client. And let him decide
how and what he do with it.

If we include a real layer system, what very easy is, because the whole
information and technic is since long time included in Cf, client can
do fancy thing with it.

If spell and map submit type information, we can easily include automapping.
Also, if we layer, we only must send ONE time a floor or wall information -
or
even a special layer like a tree. Include for every player a dirty flag map,
where differences like changed walls or floor are marked (which should
happens not
very often) and all is fine.

THIS will safe alot of bandwith. And the whole system is ready in CF.



>
     
      Michael Toennies wrote:
     
     >
     
     
     >
     
      > Also, as i add i copy&paste a false name, so i make a yoyodyme
     
     >
     
      folder in CVS
     
     >
     
      > main tree.
     
     >
     
      > Can one remove it? Mark, Tanners?
     
     >
     
     
     >
     
       Since the CVS repository is hosted on sourceforge, everyone
     
     >
     
      basically has the
     
     >
     
      same power to create/destroy.
     
     >
     
     
     >
     
      > The face file should be also removed, its nonsense to assign
     
     >
     
      xpm/xbm color
     
     >
     
      > values to the faces.
     
     >
     
      > As i understand, this is used for the magic map command. This must be
     
     >
     
      > reworked for the png only
     
     >
     
      > set, so i drop it too.
     
     >
     
     
     >
     
       Do you have a better suggestion for what to do?  Its easy to say what is
     
     >
     
      currently there is not ideal, but often harder to come up with a
     
     >
     
      good solution.
     
     >
     
     
     >
     
       For png, if magic map is to be supported in the same form, that
     
     >
     
      information is
     
     >
     
      needed.  The server otherwise has no way of knowing what color
     
     >
     
      the different
     
     >
     
      items are (and since as far as the server is concerned, the
     
     >
     
      images are just a
     
     >
     
      bunch of bits which it does not understand, so it can't really look at the
     
     >
     
      images and generate what color it should be).
     
     >
     
     
     >
     
       Since the color/face data already exists, it makes keeping and
     
     >
     
      using it the
     
     >
     
      easiest solution.
     
     >
     
     
     >
     
       Now magic mapping could of course get reworked to do something
     
     >
     
      else, like send
     
     >
     
      the actual faces for all the spaces, and the client can then
     
     >
     
      scale it down or
     
     >
     
      the like (which many other games do for the larger view).  This
     
     >
     
      would consume
     
     >
     
      much more bandwidth (at minimum, twice as much of only 1
     
     >
     
      face/square is sent),
     
     >
     
      and may be much more useful (if all faces on a space are sent) or
     
     >
     
      less useful
     
     >
     
      (if bottom space (typically terrain/floor/wall) is sent, or
     
     >
     
      somewhere between
     
     >
     
      depending on what all gets sent.
     
     >
     
     
     >
     
     
     >
     
      >
     
     >
     
      > Michael
     
     >
     
      >
     
     >
     
      > _______________________________________________
     
     >
     
      > 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
      
      
     >