[CF-Devel] arch/object changes.

[Mark Wedel]

 Various thoughts on updating the archs directories and the objects.  Several
points:

1) client type in arch.  I agree that the current method of the client trying to
figure out the type of object is a pretty bad hack.  However, at the same time,
you just can't send the type field in the object, as that may give away
information.  So my thought is to instead add a 'client_type_info' (or something
similarly named) which is only used for telling the client the type of object
and perhaps for some internal descriptive purposes (eg, if you have client types
of PLATE_ARMOR and CHAIN_ARMOR, you could use that information for descriptive
but not functional differences (that would still use the main type field).  The
client_type is the type of object as the character would perceive it.  This
unfortunately gets tricky (as what should get put into things like keyrings and
quivers shoudl be what the character would perceive it as, so in theory, I
should be able to put any long thin pointy thing in a quiver) Things like the
'bad' booze would have a client_type set to the same as good booze.  Special
objects in maps (for example, I think in port joseph you get an object that
looks like a shovel but is in fact a key), could over ride this information so
that the client doesn't think it is a key.

 I had originally thought of using the objects current type as client_type if
not set.  The problem is that the type fields are not in any order (I would
prefer all my armor things to be together for example).  I had thought about
making a map table, but then figured it was just as simple to write a perl
script that contains that information to update all the arc files.

 In actual execution, I figure this should be 16 bit value, with it being quite
sparse (eg, weapons in the 100-200 range, armor types (shields, helms, ...) in
the 200-300, etc.  There is no need for a 1:1 map from type to client_type - you
could have different client types for clubs vs swords vs axes for example.  I'm
not sure how that fits in with garbled attack message stuff and his different
types there. I would think only one should be sufficient.

2) Changing on how plural names are generated.  Currently, the server has code
in it which makes a name singular to plural.  That are enough different things
to make it pretty fullproof (eg, a flag like NEED_IE which tells it that it
should replace the y with ies).  But all in all, this is extra complication
which does have some problems.

 My thought is just add a 'name_plural' to the .arc files.  For most all the
arcs, this can be figured out pretty easily using the same logic.  this removes
some code form the server and is more fullproof.

 The only complication here is objects on maps that change the name (eg, fist of
the earth instead of bonecrusher).  My personal thought is in those cases, we
just make a plural name on the fly using a simpler logic (append an s), and fix
them as discovered (wouldn't be hard to write a script to hunt all these down
for that matter, which may be a better solution.  The editor should be updated
to have the user update both of these.

3) Images: I did some work recently to remove support for xpm and xbm graphics
in the server (in terms of collecting and loading them).  Sometime soon I'll
actually remove all the files.

I had commented to DB in irc that it wouldn't be too hard to make it so that the
server could support main + alternate png set itself.

 But as I thought about it, that makes no real sense.  I understand the desire
for people to use different image sets, but the images in the server are really
there to provide a 100% sure way of the client getting a potentially new image.

 The unix clients (and pretty sure the windows one) allows the user to use any
images they want through various means (in the unix case, make a
~/.crossfire/gfx directory, and put what images you want to use there.

 I think the problem is really distribution of these images.  Making an official
image release for the client of whatever sets (main/alternate/whatever else) to
me would make the most sense, as well as documentation on how to use them.  I
think this is also useful in other regard as it means that the user in generally
won't have to download the images from the server.

 Now personally, I would prefer that these images sets not be seperate CVS
areas, eg, the alternate set would sit in the main arch tree, but use a slightly
different nameing convention.  I think this makes it easier to see what images
are out there, and how they compare.  The collect scripts could then also make
the appropriate image files are part of the release process.  My thought is that
the naming should be something like basename.111.<image set>.png.  Main set
would not have an image set tag simply to avoid having to rename all of them. 
But that approach allows in some sense for an unlimited number of image sets. 
According to DB, gimp needs to have a proper suffix (.png) to be happy, which is
why I put that idfferent name before it.

 This is mostly just a maintenance issue, but I think it will make life a little
easier.

 Thoughts?