[CF-Devel] Does gcfclient have a maintainer?
Michael Toennies
mtx93 at tzi.de
Tue Nov 21 07:26:11 CST 2000
>
>
>
> 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.
The compelling reason will come in the future, the game grow and the data we
send
also. I find the idea, to send the triggered cmds of one action as a batch
not so
strange.
With the meta server and the dx client, we will got some more players, that
will bring
the some new performance problems. In my opinion the batch question will
come faster
then we think.
Also, there is no "mega command", all what you do is to send the cmds as one
package,
accessing the socket one time, and use the BATCH cmd as a meta tag, telling
the client
nothing more than the data are a row of cmds.
All what you do is, to assemble the normal cmds from the batch and work
through it in the same
way you got them as single cmd from the socket. There is no difference in
debugging or something
else.
A fact is, that if you play with sound and you have some lag like i
yesterday, the game starts to
run creepy because you got the cmds for a action (attacking or opening doors
for example) not exactly,
means you got a message, after some time the sound, etc.
Because a sound need a good timing with your game action, the effect is bad.
This will be avoided if
you send it in a batch.
>
> 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.
Ah yes, i see, i jump in the false routine. Think i access it when i
testing, wrote
it down as glitch.
>
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.
I aggree, but much better is to rip of this artifact and put the useful code
in a oldstuff module, where interested people can use it. There is really
much
unused and odd stuff in the client, i work through much unused structure
parts or
even double implemented stuff from older versions.
>
>
>
> 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.
The food and poison food is a good example. What of course the client should
not know is, that one is good food and the other poison. But what it should
know is that booth are from type "TYPE_EATABLE".
The use of the table is really really bad coding. The names and stuff in
there should
not be hard coded in any module! They are generated stuff by the map editor.
What you do
with at runtime generated stuff like "xyz bodypart"?
A real new type like a "leg armor" is something real new, but a new helmet
type armor should not
be identified by name. The type helmet is real, it IS somewhere in the
server stuff defined, because
the server can determinate from all armor type the correct part type, when
you apply a "xxy" helm
he automatically can remove the old one. Same for gauntlets, the server
knows the difference between
shoes and gauntlets. This is, what the client should know because
- the player need the info
- he will get it automatically when he applys a armor type
- Its nonsense that a player should not see/know the difference between a
boot and a gauntlet item
(except trolls, ok :)
Also your shovel example is false. The client knows about all keys. If a
item is type key and you
have a applied keyring in your inventory, the item is put automatically in
from the server!
This is somewhat annoying in the noble quest where you find the broken
pentagram part or whatever,
because you got the message "you got broken..." but you will not find it in
your inventory because
it is put in your keyring! Cost me a minute to find it and i know 2 newbies
who get confused by
it very much.
Its true what you say, that the way the server handle and using items
including the #define you show
should be hidden from client and player. But the table is the false way,
this information is from the
same matter not for internal client use!
This can be avoided if we define a CLIENT_TYPE_XX. This the type, the
user/client identify the item,
and when we make it smart it is the type that the server can force the
client to know it as it.
I really like my puppy wher eyousee what you have actually applied at the
right place.
All what the client must now are the this:
CLIENT_TYPE_<armor type>
CLIENT_TYPE_<weapon type> // perhaps we got different weapon skills
in the feature?
CLIENT_TYPE_EATABLE
CLIENT_TYPE_KEY
CLIENT_TYPE_MONEY
CLIENT_TYPE_GEM // perhaps same as money
CLIENT_TYPE_TOOL // symbol/lockpick/talisman
CLIENT_TYPE_BOWS
CLIENT_TYPE_MAGICSTAFF
...
The real differences are only known by the server like the poison - food.
>
>
> ** 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.
It should be no problem with it, so lets do some work here in the next time,
it will give us great sounds.
>
>
>
> 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.
Just see my comment above.
>
>
>
> 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.
No big reason to drop the drawinfo, but when you extend the the stat cmd,
it can be generated on client side, you can drop a cmd and safe some
bandwidth,
so why not?
If the client show the stats value, the value can start blinking for 2
seconds in red
for example, if it drops, this will show it very nice to the player. Most
times, you
have extended your protection by spell or potion you do it why you must
fight or do some
action. This will cause often some messages and will make it hard to read.
Also, you are concentrated on map, so you need a fast marker for bad actions
like dropping
resistance in a fight with a dragon... (jik, nothing killed me more).
>
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?)
True, for this we need the perceive. I also like not to show the player all
of his
stats, i like the way to hide some special stuff totaly from him, some
hidden but
accessible by perceive.
But some should show the player. Skills exp/lev and protection are the one i
will show the player
because most newbies are confused by this hidden information.
Also, i know some newbies which wants see the points of the next exp level.
This is some stuff for extended info.
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
More information about the crossfire
mailing list