[CF-Devel] arch types & xbm&xpm libs
Michael Toennies
michael.toennies at nord-com.net
Tue Jul 17 08:38:30 CDT 2001
Well, this preloading of a image set on client side is one thing we
really should think over when we arrived a user number of x.
Theoretical the submit of the png data is a way to thread the
server/bandwith,
when you often relogin with deleted cache. Thinking about it is of course a
issue of the future, but we should have it in mind.
The best i can think about it, is to make reall full set and in each set a
kind of
init file. The client then sends this to the server, so the server knows
which
set the client is use - when the server then has access to this set, he can
try to
update the pngs, when he don't know it, the client must live with his own.
This will be a problem of course with user made map, when we allow the user
the create
new arch types too for map sets... We don't do it yet, so its ok.
I have no real idea what the best it - for client coding i don't really care
about the set,
i just must know the size and then i blit it.
>
Michael Toennies wrote:
>
> Should it not be time to remove them from server CVS?
>
>
Probably. I will note the biggest issue on this is people still
>
using the
>
older sets and prefering them for whatever reason (if you have
>
monochrome, the
>
xbm make sense, if you have limited screen size, ie laptop, the xpm may be
>
preferable over the png, etc).
>
>
a related question on this is dealing with multiple png sets.
>
As I see it,
>
current there are the main png set, the alternate png set, and
>
the iso png set.
>
>
In the long run, one of the following should probably happen:
>
1) Server does not provide images at all. If a site adds images,
>
they provide
>
them through other means (ftp or the like) In this sense, the
>
client deals with
>
all image stuff (basically like cached is always on). This
>
simplifies code, but
>
may make hopping to different servers more of a pain (OTOH, you
>
could very well
>
have some sites which have every image available). This is
>
almost certainly
>
what commercial programs do, but they can also always rely on the
>
fact that they
>
know what the server and client is transmitting. I don't know if
>
this is ideal
>
- the code for both client and server for transmitting images isn't that
>
complicated.
>
2) Remain as is, with server only supplying one image set, if a
>
user wants to
>
use another, they must download the appropriate files. This is
>
basically what
>
we have here.
>
3) Server provides some number of images sets. this could be done more
>
intelligently in the sense that the main set remains as is (has
>
everything),
>
where as the other ones only collect the images that are custom
>
to that set.
>
Thus, the crossfire.png-alt may only have a couple hundred
>
images. When the
>
server needs to send an image to the client, it checks the
>
specific set the
>
client is using, and if it doesn't have it there, it goes to the
>
main set and
>
uses that image.
>
>
As an aside, I think there is a little too much focus on the
>
alternate set in
>
this sense - it seems right now whenever someone improves an
>
image, it pretty
>
much goes to the alternate set. I think there are many cases
>
where the improved
>
image should really have replaced what is a mediocre image in
>
what is currently
>
the main set. I know that one of the original motivations of the
>
alternate set
>
was to deal to have a set that did not use scaled up images
>
(presumably, if all
>
those had gotten redone by hand at the proper scale, that would
>
make some more
>
images between the two sets common.
>
>
Well, you should remember that the type/subtype is part of the item data -
they should only
accessible to player/client when he had identified the item. So, there
should be a genric
type xxx/UNIDENTIFIED.
WHEN the player then had identified the item, he should be have the right to
know the type.
For the key/shovel notice that you can trick this: When you have a open
keyring, the server
insert the shovel in the keyring even when not identified. This gives me a
few times someting
to think, because in pterms random quests are also keys with other faces and
they go direct
in my keyring. So, at i try to find them this item, i don't find it in my
main inventory.
I need some time, before i start to search my keyring for it...
This should be fixed: if not identified, don't insert a key in keyring...?
Hm, better we handle
this with subtype... if type is not key/key (perhaps key/OTHER) then not
insert it in key ring.
We should hold this in mind.
I mainly need this type info for the inventory doll of the client. I must
know exactly the type
of an item i wear/wield - means i must know how the server handle this item
when i wear it.
This should be really an information the client/player has the right to
know.
On the other side, we REALLY can do with the script stuff some nice thing
with type/subtype.
I think there to make real weapon/armor type stuff, like a priest only can
wield mace/rod stuff
or wizards don't can wield 2 hand sword or something...
When we do this, we have now room to create special items. A powerful demon
slaying dagger is yet
senseless, for a non sword wizard of course it is a must.
This subtype thing then has manily effect on server side.
>
>
>
> Another point is this ugly item_type module and the way the client
>
> try to get and idea of the type.
>
>
>
> Well, we only need a way to include the real type information
>
in the arch
>
> type.
>
> Mainly, we need to update the items with it - all stuff which a
>
client can
>
> put in his
>
> inventory.
>
>
>
> Really, this should be a must! The old methode is a hack and a
>
violation of
>
> the rules of the
>
> arch object system. The arch object system is dynamic and server side.
>
> What the client try is static and not server side. In fact,
>
current client
>
> item type code is
>
> outdated in the second it is written.
>
>
>
> I should be really not the horrible work to include a type (and
>
perhaps a
>
> subtype information) in the
>
> item arches.
>
>
There is of course an object type in the archs. The problem is
>
that sending it
>
then violates another rule - the rule that the client is assumed non
>
trustworthy, and sending data that the item that appears like
>
shovel is really a
>
key or the like.
>
>
One other motivation I originally had in the client having an
>
item types field
>
was to effectively let the end user determine how they wanted
>
their stuff sorted
>
by changing values in that file as appropriate. The ordering of
>
the object
>
types in the arch is not in any order - just a sample:
>
>
#define ROD 3
>
#define POTION 5
>
#define FOOD 6
>
#define POISON 7
>
#define BOOK 8
>
#define ARROW 13
>
#define BOW 14
>
#define WEAPON 15
>
#define ARMOUR 16
>
#define SPECIAL_KEY 21
>
#define KEY 24
>
#define SHIELD 33
>
#define HELMET 34
>
#define HORN 35
>
#define MONEY 36
>
#define AMULET 39
>
#define DRINK 54
>
#define GEM 60
>
#define RING 70
>
I could go on, but I think its reasonably easy to see that
>
things may not get
>
grouped nearly as well as you want it (keys are between armour
>
and shield, and
>
things like cloak, gauntlets, boots are still further down the
>
list. So if the
>
client sorts by this official item type, its pretty non sensical.
>
You could of
>
course have the client re-map this values to other values for purposes of
>
sorting, but that seems to reduce the hackiness of the current
>
setup by a minor
>
degree.
>
>
The ideal solution is probably as you mention - put in something like a
>
public_type field, which then gets sent to the client. Doing type/subtype
>
problem makes the most sense, as that way you can put all of
>
armor, shield,
>
boots, gloves, into the main armor type, and then assign subtypes
>
for each of
>
those. One nice thing this setup would have is that if new
>
subtypes got added
>
on the server, the client would still work fine, since it doesn't
>
really care
>
how the binding works out. This is different than say if we had
>
that re-mapping
>
table on the client, as it would get a new type that it doesn't
>
know about and
>
have no idea to re-map it.
>
>
Note that putting those fields in is a big difference from the
>
type/subtype
>
redo I have suggested would make more sense for the object
>
structure. But even
>
if this redo of the object structure is redone, the type/subtype
>
(which could
>
just be done as something like 'client_type 8/14', where 8 is the
>
major type,
>
and 14 the subtype, having this client_type still prevents the problem of
>
sending more information to the client than perhaps should be
>
done (like poison
>
for example, of the fact that the shovel may be a ring,etc).
>
_______________________________________________
>
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