[Re: [CF-Devel] Future of Crossfire]

[Mark Wedel]

On 21 May 2001, DAVID DELBECQ wrote:
>
     
      You say you don't want iso because you don't have time to create iso monsters,
     
     >
     
      or at least convert. It's your right but don't forget we can parse a lot of
     
     >
     
      flat object (ground and so on) to iso esaily (just some deformation). What
     
     >
     
      concern monster, 1 square monsters can, at least for the moment, be parsed
     
     >
     
      like that (they look good for iso). What concern multiple square monsters, i
     
     >
     
      believe it's a problem but once again, we could for the begin of the
     
     >
     
      developpement, parse them as flat objects which stand up in the front square.
     
     >
     
      The critical point of this are walls, doors, exits, houses, sign and other
     
     >
     
      vertical objects.
     
     >
     
      What i think is you fear your set will go to trap because of iso before being
     
     >
     
      known. Well don't know for the moment how it could be possible when i see the
     
     >
     
      speed at which developpers are speaking before doing something interesting.
     
     

 I've been working on crossfire for around 10 years now, and in that I've
gone through the xbm to xpm image conversion and the xpm to png conversion
process.

 Such conversions are not a trivial process.  to xpm to png is arguably
a more trivial one (only size increasing), and that is still being worked
on.

 Many of the images were converted & resized automatically, and people
generally really dislike those images.  I have a feeling the same thing
will happen with iso for images converted automatically.

 If the iso version can coexist with the overhead version, this helps
out a lot.  But in the long run (or even short run), I don't think we want
two image sets.

 But in any case, nothing ever will happen unless people decide to work on it.
Even if everyone decides the iso is a good thing (which will not happen
judging from the discussion, and I know I won't), it still won't happen if no
one actually works on it.

 Realistically, to get iso done in a reasonable time frame, you probably need
4-5 people working on it pretty seriously.

 Now in the design of the client was the 'vision' that it could run with
whatever graphic format it wants.  If someone wanted to run with 64x64 images,
they could do so - its just a matter of getting 64x64 images for their client.
Same remains true of the iso, as long as extra server support is not needed.
However, I have a feeling for iso to look/work right, some changes would
be needed (current images may not work good for all forms)


>
     
      I don't think you've understood what i meant. I said server use its processing
     
     >
     
      time to transfer files to other players. Even if the socket do most of the
     
     >
     
      job, i though transferring pictures to the client shouldn't be the work of the
     
     >
     
      server (and why should the server have pictures anyway???). The purpose of
     
     >
     
      this transfer is to keep a coherent set. Ok, but most servers use the same set
     
     >
     
      and i proposed to have a message during the server connection which gives
     
     >
     
      information on where to find an download these picture (could be local or on a
     
     >
     
      public ftp!)
     
     
 As said in another message, the processing time the server takes on this is
trivial.  The big issue might be network bandwidth (also see other message
about whether a seperate connection actually helps on that or not).

 The reason the server has to have images is that you need some source that
you know must the images you need.

 Suppose this example:  I run a small server, and add a custom map set which
also adds some new archs and images.  For whatever reason, I can not update
the master image server (I could provide a potential large reasons why this
may not happen).  The client has to be able to get the new images I'm using.

 But there is a lot to be send for simplicity.  You may very well be
behind a firewall which lets high port number connections (ie, crossfire)
out, but mandates use of proxies for ftp and http.  Do you really now want
to not only have the client be able to deal with those protocols, but
also able to deal with proxies as intermediaries?  Its very nice to know that
if you can play the game, you can get all the info you need.

Realistically, supplemental image servers may not be bad.  Shipping an image
set with the client may not be bad.  But having that be the only way to get
images would be bad - I think at some level the client must be able to get
images from the server for a variety of reasons.  So the best that can be done
is to discourage that behaviour if it really is undesirable.

>
     
     
     >
     
      I didn't say the client was heavy (except perhaps for the directx one, but it
     
     >
     
      a directx problem). Let's say am a newbie player, i downloaded and lauched the
     
     >
     
      client. I connect to a server, create a player. Then, the server says to type
     
     >
     
      a lot of crappy things in the console. I want to cast spells, i have to type
     
     >
     
      thinks, bind blablabla.. then i can cast. Well am newbie, where on hell can i
     
     >
     
      find a list of commands. Help?? Yes this command work. What?! is this a telnet
     
     >
     
      game with a graphical board? Well i prefer to go away.
     
     >
     
      This could be good, for example to have a small, findable, button where you
     
     >
     
      can click to choose you spell. I would be very happy to have an interface
     
     >
     
      where keyboard is not used to type crazy things among the console (or at least
     
     >
     
      in some rare cases).
     
     
 If really important, pull down menus to cast spells could be added.
Realistically, no advanced player will ever use those windows (or very seldom
- just for the spells you cast once in a blue moon that you don't want to
bind).  Binding spells tends to be much faster in the long run.

 I know there is desirability to have things mouse navigitable.  But even for
other games, I usually try to find whatever keyboard shortcuts are available
pretty quickly.

 Also, currently the spells the player knows about are not communicated
effectively to the client (the client can invisibly send a cast command
to the server and then parse the returning drawinfo data).  But some better
form such that the client could know the spell lists and some information
about them would probably be desirable - it could then generate the menus
based on this info.

Useful info IMO: spell paths player has repelled, attuned, denied
spell info: spell name, type (fire, cold, cure, etc), sp, type (priest/mage),
and spellpath (if different from described type), perhaps image

Client could then draw nice little icons, put little markers depending on how
the players spellpath matches with the spell (so you can more easily see if
you are casting an attuned spell for example).

 With something like 170 spells out there, the lists would need to get broken
down into types at some form.

 Ideally, of course, the spell popup menus would let you set bindings
for the spells right there.

 IMO, doing all the above would be a nice addition of a feature. Its just a
bit of work to do (I don't think any of it is actually really hard to do).  At
least on the unix side, this would be a gtk client issue only.