[CF-Devel] Does gcfclient have a maintainer?

[Mark Wedel]

Michael Toennies wrote:

>
     
     
     >
     
      for example at this time we a range of very small cmds, following one
     
     >
     
      action.
     
     >
     
     
     >
     
      if you hit some, you get (perhaps)
     
     >
     
      - a draw info
     
     >
     
      - a sound cmd
     
     >
     
      and in some cases
     
     >
     
      - stats cmd (exp)
     
     >
     
      - map cmd
     
     >
     
     
     >
     
      Its only an example. What i mean is, that cf got some more complex
     
     >
     
      in the past and more and more features and actions are implemented.
     
     >
     
      And which every feature, some is added.
     
     
 As I've said before, there is no compelling reason that the number of commands
that gets sent back and forth need to be reduced.  And personally, I find it
much easier to debug the 4 individual commands than if you had 1 mega command
that includes all that stuff.  And in that mega command, you really are not
saving that much space, as you still need to have markers to say if you are
including draw info, stats, sound, etc, and some of those also need legnth
parameters.


>
     
      I found some glitches and artifacts how the client works.
     
     >
     
      In old times, the client examine the drawinfo for information.
     
     >
     
      There are still many places where the windows/gcfclient do it.
     
     >
     
     
     >
     
      A real real bad part which needs a lifting is the way, the client
     
     >
     
      get the nrof items and the type of items. Both works with some creepy
     
     >
     
      text parsing.
     
     >
     
     
      The code is still there for legacy reasons.  I don't believe the server will
use the older item command anymore, and always uses the item1 protocol command
that includes the nrof as a seperate field so the client does not need to
reverse engineer the name.

 If there are any cases were the server is still using the item command, that
should be fixed up.  It may be getting near time to remove all the depreciated
commands and code from the protocol and client, but generally, there has not
been a major reason to do so - they may still provide useful if anyone is
playing on older servers, and the code pretty much works.

>
     
     
     >
     
      The type works with a buggy table, identify only 80% of the items.
     
     >
     
      Also old items like the wizard cloak and 70% of all non standard weapons
     
     >
     
      are identified as type "unknown". Also, gloves for example are identified as
     
     >
     
      type "boot"... I don't wear gloves on my foots most times.
     
     
 The table can be easily edited at least for the unix client.  I've generally
tried to fill in missing types.

 Note that for the unix client at least, the item_types table is just used for
grouping and nothing else.  When making up that table, I did not have a problem
grouping the footware and handware together, since they are fairly uncommon
items.  If its a big deal, it is very easy to change that.


>
     
      For this and for some more it will be useful to make a new version of
     
     >
     
      client, include
     
     >
     
      the SETUP cmd for what the client wants in which way and include more
     
     >
     
      information direct
     
     >
     
      in the cmd, like the item type and nrof.
     
     
 nrof is already done - see above.

 item type is sort of odd, in that even on the server, I personally think that
there are many more item types than you might find useful.  Also, one thing the
client does is that the item_types file lets you order where the items appear in
your inventory, so things like containers are at the top, followed by weapons,
armor, etc.

 The item numbers that the server uses are not in any meaningful order.  For
example, here is the order if I extract the entries that may actually appear in
the players inventory:

#define ROD             3
#define POTION          5
#define FOOD            6
#define POISON          7
#define BOOK            8
#define CLOCK           9
#define ARROW           13
#define BOW             14
#define WEAPON          15
#define ARMOUR          16
#define SPECIAL_KEY     21
#define SHIELD          33
#define HELMET          34
#define HORN            35
#define MONEY           36
#define GRAVESTONE      38
#define AMULET          39

 And I'll snip it there.  But just for note, WAND is type 109, which is no where
near rod (#3 up there).

 I personally like my wands and rods stuck near each other in the inventory. 
Likewise, if you look at the above, the special key type is between the armor
and shields, and gauntlets and boots don't even appear on the list.

 So using the server idea of item numbers if of very limited use if you want
your items sorted together.  Now sure, you could create a mapping table in the
client that sorts these, but you run into the same problem we have right now -
new items get added, and so your mapping table is out of date.

 Also, in some cases, the client should not know about the different item
types.  For example, a player (client) should not know if the item type is food
or poison.  And in many maps, certain item types are disguised with the name &
image of another item type.  I know that at least one map used a shovel as a
special key - if you could instantly see that shovel was a special key, that
would make things less interesting, and in some maps, it may basically ruin the
quest if you know what the special item happens to be.

 In less than an hour of work, the item_types file for the client could be made
100% complete.  Of course, as new archetypes are added, it may get out of date
again, but the same could be true when new item types are added.




>
     
      ** Also, i want much more sound infos. I will do some work in it, because i
     
     >
     
      know a friend of
     
     >
     
      me, who has do a lot of sounds for a prof. full prize game. He has a bunch
     
     >
     
      of cool sounds for
     
     >
     
      a rp game he don't use and when i ask him and can show him some useful way
     
     >
     
      we use it, he will
     
     >
     
      give it us for free!! **
     
     
 He has to agree to give us the sounds under the GPL for it to acceptable, as
this is what the rest of the game is under (or I guess we could make an
alternate sound distribution with a different license).  As I said previously,
sound code in crossfire has really not changed much in a long while, and is
probably one of the more out of date areas.

>
     
     
     >
     
      What will be very useful when we add more (and more complex) sound
     
     >
     
      actions, is a BATCH cmd!
     
     >
     
     
     >
     
      Lets name it BATCH. It works very simple, first value is the length of the
     
     >
     
      batch,
     
     >
     
      perhaps next is the number of cmds in the batch (it can avoided if we count
     
     >
     
      the length),
     
     >
     
      next the cmd. cmd is still <length> <cmd> <data>.
     
     >
     
     
     >
     
      With it, we can easy include a snd cmd for more actions like find traps,
     
     >
     
      disarm traps
     
     >
     
      success/not done/failed and of course color information and much more cmds.
     
     
 I fail to see how the batch command makes any difference.  IT is no different
than just sending a bunch of commands - all you are doing is encapsulating them
in another layer.  Just send a bunch of sound commands.  the result is the same.

>
     
     
     >
     
      If we include the new protection code, i strongly prefer to show the player
     
     >
     
      the value.
     
     >
     
      Handling it with rod of protection will be a pain in the ass. The player
     
     >
     
      MUST see it,
     
     >
     
      it will be to confusing. I want die i the game because i do bad actions, not
     
     >
     
      why i get
     
     >
     
      tired of zapping a rod or counting values.
     
     >
     
     
     >
     
      Also, for this we can extend the STAT cmd, drop the drawinfo for protection
     
     >
     
      and let the client
     
     >
     
      show/info the player.
     
     
 I have no problem extending the stat command when we do the partial resistance
code.  I don't see a big reason to drop the drawinfo message.  Sure, you may not
need it, but it doesn't really hurt anything.  Especially if the expiration of
the spell drops your resistance by 10 points - you may not notice that in the
stat, but you may still want to re-cast that protection spell.

 It does seem to me that a bit of stuff that perceive self tells the player
should really be known but there is no other way to really find out.  For
example, many races start with some special ability or another (see in dark,
some level of protection/vulnerability/etc), but there is really know way of
know that fact.

 Likewise, if you gods gives you something or takes it away, you would think
that the character should have that knowledge, but once again, save for perceive
self, there is no way to get that information.

 As time has passed, more information has made it into various commands (like
skills and statistics).  And perceive self seems like it is generally a spell
that is very seldom used.  Is there really anything that perceive self tells you
that is actually useful that shouldn't be common knowledge (at least to your
character?)