[CF-Devel] arch/object changes.

Sun Dec 9 01:04:49 CST 2001

>

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

     >

      points:

Firstly, I agree with most points here. Certaintly, as Mich has pointed out to me, the objects area and in particular the interface between client and server for objects is rubbished abit. A quick example, currently a server matches a name with a list of names it stores, so it can't classify it. What does this mean? as soon as a new item is added the client is effectively broken. Type is certainly a piece of information that is needed for easy implementation of the body like mapping Mich used in the dx and sdl clients. As I personally like this, I wish to see it added =).

>

      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.

This should be moduler I suppose. Also, it should be mentioned that any extra information about an item could in theory break alot of puzzles. I suspect this situation is somewhat similar to that of the implementation of PR. Alot of things may or may not break, but it shouldn't take very long to iron out the major bugs then focus in on the specifics.

>

       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.

I suppose this is where a major problem lies. I think garbled (Tim) suggest a good idea for classifying such things, I will let him reiterate it. Of course for the situation of item mapping for the client, more than just a type is really needed, it where is it on the body? An axe doesn't actually imply where it should be placed on the body, and for things like multiple weapons, clever things like more than 2 rings for fireborn etc that sort of information would become invalueble.

>

       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.

No comment, gee I like python ;)

>

      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.

agreed, this is very yucky =), 'that is two tooths'.

>

       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.

Yeah I like this idea.

>

       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.

Err why not just update the 'name_plural' value?? If you are gonna store that info in the .arc file, surely it would be a simple matter to update it for the map specific items, grep?

>

      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.

At this point I will remind you of the arguements we have just had with Mich about notice of major changes ;). While it is defn true that you are the adminy dude, I suppose some people would have liked more warning about this change (laptop users mostly, sheeesh ;). I for one love that this has FINALLY been done.

>

      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.

I have thought about it abit more, I was more interested not in the support of alternate sets, but the ability to add any new set to the archs. Some naming system which allows easy creation of a new set?

>

       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.

I believe the topic of moving images to client side has been discussed, using some sort of central image server. I believe this idea was also dumped =). I feel that the server really should provide the distribution of images, I also think it should be able to provide a selection of styles for the user, as it has in the past. Crossfire has supported three sets until recently, png, xpm and xbm. Now that xpm and xbm are no longer supported we support one, although there is a second easily mergable set sitting in cvs doing nothing. From a simple system of, gcfclient -sdl -alternate, or perhaps a server side command, or perhaps even something in the config window. Really if we are going to ditch the other two, we should pick the alternate set up, at least some of the xpm/xbm players will feel alittle more at home with the style of it.

>

       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.

It is alot of effort to go through for one person, really we should support it and no force users to investigate that sort of thing on their own? =\

>

       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.

I agree, the stuff is there, we just need to support it in image collect and distribution,

>

       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.

I agree 100% here. Not only would it make it easier for developers to view the options, but it would organise the alternate set, it would allow easy retirement, of a standard or alternate set image. ie remove a standard image and it uses the alternate instead.

the idea of adding a suffix is in my mind the best choice. image.<set>.111.png why this order? because usually you want to look at a sets image before you want to look at a specific image in the series. It is mearly a style thing, I don't have a real problem with what you have suggested.

It also seems that the gimp guesses some formats but not others when it doesn't have a suffix file type (.png). none the less, it is bad form not to give a file a type for simple management purposes if nothing else. Adding .png to the end of an image could well save alot of time in the future =).

>

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

     >

      easier.

Indeed, the graphics sets are secondary to the game. None the less I think this change would improve the manageability of CF no end =). I vote 1 for this change in pretty much its entirety. Perhaps alittle more though on exactly what we want to send the client in terms of information is in order though =).

dnh