[CF-Devel] arch types & xbm&xpm libs

[Mark Wedel]

Michael Toennies wrote:
>
     
     
     >
     
      What i don't want include is xbm&xpm support.
     
     
 No requirement that you do.  You can easily state in the client documentation
that this client can only be played on a server that has png images available
(which I think realistically is pretty much all of them).  If you happen to get
a server that does not have png images (such that when your client says it wants
pngs, server says can't do that), you could just pop up a message stating as
such.  Of course, removal of these from the servers does not change the case in
any way if someone is on a very old server.

 As a note, the gtk client never supported the xbm format.  So that is a real
case example of only supporting some set of images.

>
     
     
     >
     
      Should it not be time to remove them from server CVS?
     
     
 Probably.  I will note the biggest issue on this is people still using the
older sets and prefering them for whatever reason (if you have monochrome, the
xbm make sense, if you have limited screen size, ie laptop, the xpm may be
preferable over the png, etc).

 a related question on this is dealing with multiple png sets.  As I see it,
current there are the main png set, the alternate png set, and the iso png set.

 In the long run, one of the following should probably happen:
1) Server does not provide images at all.  If a site adds images, they provide
them through other means (ftp or the like)  In this sense, the client deals with
all image stuff (basically like cached is always on).  This simplifies code, but
may make hopping to different servers more of a pain (OTOH, you could very well
have some sites which have every image available).  This is almost certainly
what commercial programs do, but they can also always rely on the fact that they
know what the server and client is transmitting.  I don't know if this is ideal
- the code for both client and server for transmitting images isn't that
complicated.
2) Remain as is, with server only supplying one image set, if a user wants to
use another, they must download the appropriate files.  This is basically what
we have here.
3) Server provides some number of images sets.  this could be done more
intelligently in the sense that the main set remains as is (has everything),
where as the other ones only collect the images that are custom to that set. 
Thus, the crossfire.png-alt may only have a couple hundred images.  When the
server needs to send an image to the client, it checks the specific set the
client is using, and if it doesn't have it there, it goes to the main set and
uses that image.

 As an aside, I think there is a little too much focus on the alternate set in
this sense - it seems right now whenever someone improves an image, it pretty
much goes to the alternate set.  I think there are many cases where the improved
image should really have replaced what is a mediocre image in what is currently
the main set.  I know that one of the original motivations of the alternate set
was to deal to have a set that did not use scaled up images (presumably, if all
those had gotten redone by hand at the proper scale, that would make some more
images between the two sets common.


>
     
     
     >
     
      Another point is this ugly item_type module and the way the client
     
     >
     
      try to get and idea of the type.
     
     >
     
     
     >
     
      Well, we only need a way to include the real type information in the arch
     
     >
     
      type.
     
     >
     
      Mainly, we need to update the items with it - all stuff which a client can
     
     >
     
      put in his
     
     >
     
      inventory.
     
     >
     
     
     >
     
      Really, this should be a must! The old methode is a hack and a violation of
     
     >
     
      the rules of the
     
     >
     
      arch object system. The arch object system is dynamic and server side.
     
     >
     
      What the client try is static and not server side. In fact, current client
     
     >
     
      item type code is
     
     >
     
      outdated in the second it is written.
     
     >
     
     
     >
     
      I should be really not the horrible work to include a type (and perhaps a
     
     >
     
      subtype information) in the
     
     >
     
      item arches.
     
     
 There is of course an object type in the archs.  The problem is that sending it
then violates another rule - the rule that the client is assumed non
trustworthy, and sending data that the item that appears like shovel is really a
key or the like.

 One other motivation I originally had in the client having an item types field
was to effectively let the end user determine how they wanted their stuff sorted
by changing values in that file as appropriate.  The ordering of the object
types in the arch is not in any order - just a sample:

#define ROD             3
#define POTION          5
#define FOOD            6
#define POISON          7
#define BOOK            8
#define ARROW           13
#define BOW             14
#define WEAPON          15
#define ARMOUR          16
#define SPECIAL_KEY     21
#define KEY             24
#define SHIELD          33
#define HELMET          34
#define HORN            35
#define MONEY           36
#define AMULET          39
#define DRINK           54
#define GEM             60 
#define RING            70

 I could go on, but I think its reasonably easy to see that things may not get
grouped nearly as well as you want it (keys are between armour and shield, and
things like cloak, gauntlets, boots are still further down the list.  So if the
client sorts by this official item type, its pretty non sensical.  You could of
course have the client re-map this values to other values for purposes of
sorting, but that seems to reduce the hackiness of the current setup by a minor
degree.

 The ideal solution is probably as you mention - put in something like a
public_type field, which then gets sent to the client.  Doing type/subtype
problem makes the most sense, as that way you can put all of armor, shield,
boots, gloves, into the main armor type, and then assign subtypes for each of
those.  One nice thing this setup would have is that if new subtypes got added
on the server, the client would still work fine, since it doesn't really care
how the binding works out.  This is different than say if we had that re-mapping
table on the client, as it would get a new type that it doesn't know about and
have no idea to re-map it.

 Note that putting those fields in is a big difference from the type/subtype
redo I have suggested would make more sense for the object structure.  But even
if this redo of the object structure is redone, the type/subtype (which could
just be done as something like 'client_type 8/14', where 8 is the major type,
and 14 the subtype, having this client_type still prevents the problem of
sending more information to the client than perhaps should be done (like poison
for example, of the fact that the shovel may be a ring,etc).