[CF-Devel] Does gcfclient have a maintainer?

[Michael Toennies]

Hi
I near finishing the dx client, also sound work fine now
and i have do some work in the gcfclient working me through the
code, so i have done work. Not in the X code, more in the cmd and
client/server communication.

I have some idea how we can useful extend the commands.

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.

I strongly prefer the SETUP cmd, i talk about some weeks ago.

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 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.

I have finished a inventory puppy. There you see, what you have actually
applied.
It look great and its very useful. With the old code, there is no real good
way
to implement and identify all item types (which i need to give the puppy the
right
armor on the right slot).

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.

When you look in the code of the cmds, you will see that you can do most
changes without
more bandwith use, in many case you can make the cmds smaller (putting the
nrof in a int
value for example).

** 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!! **

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.

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.

So, please let us work together in the client stuff.

MichToen

>
     
      > Server requests for colored text are not being honored by
     
     >
     
      > gcfclient....
     
     >
     
     
     >
     
       Best I know, no one is officially maintaining/is reponsible for
     
     >
     
      the gcfclient.
     
     >
     
      I've done some limited work on that client.
     
     >
     
     
     >
     
       As previously said, what I would really want to do is change the color
     
     >
     
      information to not be color but instead go into different
     
     >
     
      categories of messages
     
     >
     
      so that the client can sort them.  This could also make some
     
     >
     
      things easier - I
     
     >
     
      know when David originally wrote the gtk client, determining
     
     >
     
      multi line queries
     
     >
     
      were difficult to determine - an option for the message could
     
     >
     
      denote it should
     
     >
     
      be applied as part of a query.
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >