[CF-Devel] Plea

Sat Sep 8 16:52:13 CDT 2001

Chachkoff Yann wrote:

>

      I think merging both sets is a bad idea. They have completely different

     >

      drawing styles, and mixing them would not be good.

     >

      However, I agree that easier picture selection (on the client side) would be

     >

      a very good thing.

 I don't think the sets should generally be merged completely, but I do think
there are some images in the alternate set that should really be in the main set
because they are better than the images in the main set.

>

      That's one of the reasons I thought pictures should be a complete client-side

     >

      matter (but I already expressed this before, so I don't restart discussing it

     >

      here). Else you are somewhat dependent on what the server admin decides to do.

     >

      Of course, on some clients, you can use the "cache images" facility to avoid

     >

      the problem - simply fill the cache dir with custom pictures and you are on.

     >

      But I do not think it is a good idea to do so because:

     >

     >

      1-Most people don't know how to do this;

     >

      2-Some clients may manage the cache in a different way so that such trick

     >

      would not function properly on them;

     >

      3-If this is the suggested solution to display an alternate gfx set, why

     >

      isn't it THE solution to handle ANY set ? using two different systems to

     >

      supply pictures (from server or from gfx cache subdir) seems quite confusing

     >

      and redundant for me.

 Note that using a 'gfx' directory as I described in a previous mail is
different than the cache (basically, it looks for the image in the gfx directory
first, and if it does not find it there, falls back to the cached images/images
from the server).

 Point #1 should be corrected by better docs.  Certainly the docs on the gfx
directory are basically non existant.

 Point #2 is a problem for any solutions.  For any suggestion, the clients may
implement it differently or may not implement it at all.  Sure, it would be nice
if all the clients behaved in the same way, but I don't like the idea of
different clients may handle it in different ways as it is not a valid way to do
something.

 Point #3: The client must have a way to get images the server has added.  As
long as the server can add images, the client must be able to get them.  Suppose
I'm expirementing with some new arch's and images - my server has them, but they
are not out publically yet.  The client must be able to get them from my
server.  And if its the early test/experiment phase, I probably don't want to go
to the effort of making them public (may the archetype doesn't turn out.  Maybe
I want this to be a customization only available on my server, etc).

 Sure, if you could know that you had a complete image set that any server may
use, using a gfx method and not transferring the images from the server makes
sense.  I see no reasonable way to make sure that is the case, other than to say
that any server that adds new images is 'unsupported' or the like, which IMO is
the wrong approach for an open source and customizable game.  This is certainly
not a problem for the commercial games which can make sure the client has all
the images (and if they add stuff to the server, require a patch, but done
infrequently enough that its not a big bother).  Of course, the crossfire server
could also supply a 'patch', but this just amounts to the new images, so its
really no different.

>

      Anyway, can't we imagine a simple picture-handling client program (maybe

     >

      included into the client itself) ? It connects to a central server, checks

     >

      the content of a "picture-set" folder, and displays a list of all available

     >

      sets. Then you choose which one to use/update, and the required pictures are

     >

      downloaded. Such server would contain a "picture core" common to all servers.

     >

      All sets in it would have to be complete. Each game server could be also

     >

      associated with a smaller picture provider sending only pictures specific to

     >

      that server.

 How do servers that use custom images provide this to the picture server?  Some
form of authentication is probably needed, otherwise I would bet in pretty short
order someone malicous out there will realize that they could trash the picture
server.

>

     >

      I see some advantages to this:

     >

     >

      1) Server admins would not anymore have to bother about how

     >

      installing/updating a picture set - they simply provide pictures if they want

     >

      to add a custom object.

 IMO, this really isn't any different than it is now.

>

      2) GFX makers would not anymore have to wait admins to install/try their

     >

      sets. They simply put them on the central picture repository (much like what

     >

      is done now with CVS).

 This is a definate advantage.  Of course, similar authorization on who can
actually write to the picture server would need to be put in place.

>

      3) Players would not anymore have to find how to install alternate sets on

     >

      their system - they could simply select the required set from a clear list

     >

      with clear comments.

 This is useful.  Note that it can basically be done the same way now via web
page and download of appropriate archive.  If installation became complicated, a
pretty trivial script that creates
the appropriate gfx directory and copies the image in could be made and included
with the image archive.

>

     >

      I want to know: is there anyone opposed to that general scheme and why ?

 I have no real objection to a central repository that can be used in
preferance/addition to what the server provides.  I don't think there is any
reasonable way to completely remove the images from the server unless you are
willing to say that you may end up playing on a server and not have images for
certain objects.

 Rick Tanner is working on a webpage to describe putting the alternate images
into the gfx directory in a much more straight forward fashion.

 My personal preferance on such a scheme would be:
1) Make sure the clients use a similar/compatible scheme for images in the gfx
directory.  I think the one other thing is that images in the gfx directory may
only be used if the -cache option is on, so that should probably be turned on by
default.
2) Make a web page/site that contains the image archives.  In that, you can even
put preview pictures in addition to the text.
3) Make installation of that archive simpler.  Presumably the web page mentioned
in step #2 would have most of the directions, but adding some docs into the
client itself about said web page and directions would be useful.
4) As it is now, the client would search for images in the gfx directory, and if
not found there, get it from the server they are playing on.

 I suggest the above for the following reasons:
1) It is much simpler to do than writing our own server for server image files. 
cgi-bin or ftp access (with unique accounts for each person) can be done to let
'well known' servers update their image files.
2) Much easier to have mirrorred web sites than trying to figure out how to
mirror specialized image server.
3) Just like a custom image server, such a web page server could get updated
main distribution via cron (ie, do cvs update and then build appropriate files,
and copy to web server).

 Now what is not clear in both proposals is how to do with single images that
are updated.  If the image files are actually groupings of images, you now have
a problem where maybe a few images have changed, but do to them being parts of
larger archives, you don't really want to spend the time downloading them all. 
I guess that is the one advantage of providing a custom picture server, you
could make the download resolution to single image size.  I suppose you could
have the images for each set also available individually and so could get
downloaded that way, but in that case, you probably want a front end program
that does that.