[CF-Devel] new release: CFJavaEditor 0.971

[dnh]

Hmm i tend to agree with mark here, while it may be silly to put face
colour in there when we aready have the images. It seems both wasteful and
very time consuming to create a new method. I don't really have a better
suggestion for how to do it, though I would like to point out. There are
some cases where certain tiles have been given strange colours to make
sure if people use magic map it stands out. I can think of one classic
example where there is a river, and they only way to get across is by dim
dooring on the right angle. To help the player the correct path is a
different colour on  magic map. Now how else could map makers store this
sort of information?

dnh

On Tue, 19 Jun 2001, Mark Wedel wrote:

>
     
      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
      
      
     >