Magicmap, was Re: [CF-Devel] new release: CFJavaEditor 0.971

Mark Wedel mwedel at scruz.net
Wed Jun 20 23:28:26 CDT 2001


Michael Toennies wrote:
>
     
     
     >
     
      Type information is a absolut unique identifier.
     
     >
     
      To advance it, we also talked about to make a second byte
     
     >
     
      which is then the under type typ.
     
     >
     
     
     >
     
      like type x = weapon. x,1 = swords, x,2 = axes...
     
     >
     
     
     >
     
      This is absolut enough information for the client.
     
     
 One may question if it is in fact too much information for the client (I'm not
necessarily saying it is, but such a system certainly conveys a lot more
information to the client).  Also note that such a change for the archetypes and
code isn't near the top of my things to do right now.

 I do agree that some for like that could be used.  I remember that heroes of
might and magic would let you cast similar spells, and on the overall map, it
would tell you what type of things are where.

>
     
     
     >
     
      Also, the color information submited with the magic map command is more
     
     >
     
      than worse. You will not have different colors... magic map is normally
     
     >
     
      build up by 13 or 16 colors ors so. Seems a relict from 16 colors days.
     
     
 There is no debate about that.  But there are a lot of things in the server
that are 'old', but they work fine.  Certainly something that works but is not
ideal is better than nothing at all (or a quick hack).  It seems like it would
be a lot simpler to just update your editor to collect this information than do
anything else.

 Or of course the alternate solution which will probably be used for a while
then is to just not use the editor to collect the archs, but instead use the
scripts in crossfire that actually do work and do all this stuff.

 could magic map be improved?  It sure could be.  But we should figure out what
it should be improved to and how the implementation works out.


>
     
     
     >
     
      Using a different water arch.
     
     
 Under your system, that only works if that other arch has a different
type/subtype.  To me, that is not a good approach - it requires rebuilding
archetypes for somethign that should purely be an object change.

 Also, with a type/subtype setup, the client still needs to know what to do with
the information.  So if you add a new archetype, that doesn't really do any good
unless client knows what to do with that new subtype.  This makes adding such
attributes much more difficult, as basically a client update is needed for it to
be usuable.

 But as said, we really need to figure out what do to.

 My personal preference would be to basically make it a extended map type
command (were we send the faces), but only send faces for non items/non
monsters, and include special tags to note these other facts (tag for monster,
treasure, and some other number of types).  But once again, this conveys
different informatoin - you get a very pretty map (client would presumably scale
the images down), but you don't get any information on the monsters other than
they are there.

 For example, with color information right now, you can narrow down monster
types based on colors (not a lot of yellow/orange monsters, so if that currently
shows on a magic map, you can pretty much know its a beholder/dread).

 OTOH, sending the exact information is a lot more than currently given.  OTOH,
if thats what is needed to make magic mapping usuable, that may not be too
unreasonable.

 Note that there can be same big bandwidth issues if many of the images have not
been sent to the client.  Yes, if the player plans on doing the map, he will
need to download those at some point, but casting this on a decent sized maps
shortly after the player starts could results in a whole lot of images needing
to get downloaded.

    
    


More information about the crossfire mailing list