Images, was Re: [CF-Devel] arch/object changes.

David Hurst dnh at hawthorn.csse.monash.edu.au
Tue Dec 11 20:14:35 CST 2001


>
     
       My worry about supporting an arbitrary number of alternate sets is that it is
     
     >
     
      certainly possible to end up with a lot of different sets, with maybe just a
     
     >
     
      small number of alternate images.  This could get to be a real pain.  To me, the
     
     >
     
      other advantage of client side images is that the user can select on an on image
     
     >
     
      basis which ones he wants.  For example, right now if play with the alternate
     
     >
     
      set, you get all the images in that set - if you only wanted the monsters out of
     
     >
     
      the alternate set, you would need to make appropraite changes to your local gfx
     
     >
     
      in that case.
     
     
This is somewhat true yes.

>
     
       But I guess really, it doesn't make much difference how many image sets are in
     
     >
     
      the server.  But I have the following guideline/proposal:
     
     
Well it doesn't matter, as long as clients can easily choose which they prefer.

>
     
      1) Image format for all images should be png.
     
     
I believe this was agreed upon awhile ago, I defn don't think we should move from png yet ;).

>
     
      2) There must be an active maintainer of each of the image sets.  If a set gets
     
     >
     
      too out of date because of no maintainer, that particular set gets removed.
     
     
What do you define as active out of interest? Commiting something new once a week, once a month, hanging around in #crossfire?. I guess this is fair ambiguous, I would prefer something alittle clearer, like..

'we reserve the right to move unsupported sets off the main cvs tree if support discontinues or because it is supersceded"

Is this sort of what you were thinking?

>
     
      3) When new arch (and image) is introduced, only an image for the main set is
     
     >
     
      required.  It is up to the maintainers of the different sets to make an image if
     
     >
     
      the default one is not appropriate.
     
     
Yes a nice rule, this comes back to the support thing. If a set stops supporting things that, the set description indicates it should.. some form of warning message to a set maintainer could/should be sent?

>
     
      4) There will be something like a 'image_sets' file in the lib directory.  This
     
     >
     
      file would contain things like image set number, symbolic name (running client
     
     >
     
      like -set 5 is pretty odd, but if instead, it is something like -set small, that
     
     >
     
      makes more sense), standard geometry of images (this is more relevant because in
     
     >
     
      the future, things like shops will just be one image, so the client can't look
     
     >
     
      at the image size - it needs to know something about what the normal size of the
     
     >
     
      image should be), image fallback mode (if image not in this set, try other set. 
     
     >
     
      Now that other set could have another fallback - eventually they all fallback to
     
     >
     
      0 - the main set), and description.
     
     
Would it then be possible to change sets while in the game? I certainly see that feature as being quite important.

>
     
       There would be some extension to the protocol to request a copy of this
     
     >
     
      information so it can prevent it to the user (you could have a selection
     
     >
     
      mechanism in the client that requests this).  Also, when the client switched
     
     >
     
      some set, it would get the resolution at minimum.
     
     
Ahh I think this answers my question =).

>
     
      5) There must be a somewhat legitimate reason for the set, eg, there must be
     
     >
     
      enough in the set to warrant it being part of the game and not just 15 images
     
     >
     
      you download off some site.  There should probably be at least 100 images before
     
     >
     
      it should become a set.
     
     
I suppose this again is rather ambiguous. What defines being legitimate, to someone who just wants to update the dragon and use another set for everything else, they may see this as legitimate?

>
     
      6) In terms of collection, the collect script will only collect the images for
     
     >
     
      that specific set, resulting in a sparse image file.  The server will deal with
     
     >
     
      fallback.  This results in smaller image files in lib, which means faster load
     
     >
     
      time and less memory footprint for the server.
     
     
Hmm also abit slower though? the way CF currently handles the alternate set is, it creates the image list, then runs through it and sees if it can find an image in the alternate set of the same name. If one is found it uses the image from that directory instead of the arch directory. This means anything which is either wrong, or not there is ignored at the old image used.

>
     
      7) naming would be image.111.x.png (the image and 111 obviously vary), with x
     
     >
     
      starting at 1 (0 is reserved for main set - in theory, those should get renamed
     
     >
     
      to that, but for legacy purposes, keeping it without that .x works).  If there
     
     >
     
      is good reason, put the .x in front of the .111 could be done - to be honest,
     
     >
     
      I'm not sure a how relevant this if - if using command line tools, none at all
     
     >
     
      (as it just is amatter of doing *.x.png vs *.x.*.png.  I can see it makes some
     
     >
     
      difference for tools that show the stuff alphabetized, OTOH, the location of the
     
     >
     
      .x. makes some difference, but only when the image has different animations - in
     
     >
     
      that case, all the ones for each set will appear next to each other  This
     
     >
     
      probably does make things a little easier, especially if there ends up being a
     
     >
     
      whole bunch of sets.
     
     
Yeah I suppose this is contentious. If looked at from a list in alphabetical order you have the choice of:

a) sorted by set, object, specific: set.image.111.png
b) sorted by object, set, specific: image.set.111.png
c) sorted by object, specific, set: image.111.set.png

obviously there are 6 more choices ;), but I think these are the three most important. What do we consider the most important information, the name should be sorted from most important to least important. Originally I would have said a), but now my preference is for b). When editing and finding images, the preference would be for which monster, which set, which image in general. I must say (yes I know more python whinging) that uses an int to represent the set seems alittle counter intuitive. I would ave thought three letters would be far more useful, I would hate to have to find the list of which set is which number. But std, flt, iso, crt, stp, crp etc etc would be far more useful? I realise that c's string handling is alittle braindead... but this seems worth the extra work to me.. ;)

Yes I like all of what you have said Mark, can't wait for implementation ;). I would be happy to move all the alternate set images into the arch with image.x.. or image.111.x.. a script shouldn't be to hard =\. I like your idea of storing set information, particular image size and a short description of its purpose. That information could then be sent to the client so users will have less trouble selecting their prefered sets. thoughts?

dnh (or to leaf: DNH) ;)

    
    


More information about the crossfire mailing list