[crossfire] Feature proposition: [img] tag

[Andreas Kirschbaum]

> > > More likely want to have something like an img tag with hints, for
> > > things like popup, desired size, etc.
> >
> > Then let's do the whole trick and use some XHTML subset?

I'd rather keep the existing media tags implementation rather than
switching to another encoding. We do not need maximal flexibility with
many options. Instead we need a very small and fixed set of tags to make
map-making easy. (Map-maker don't have to remember/choose between many
options, map-maker don't have to check whether the message actually
works on all systems and clients.)

My two cents regarding image scaling (or other options): don't add such
options; it complicates both client implementations and the correct use
within messages created by map-makers. Instead refer to a correctly
sized image:

 - refer to a 1x1 tile image for inline-images within text (e.g. for
   monster or item descriptions in scrolls explaining these);

 - refer to a (say) 5x5 tile image for a picture of the map that the
   scroll talks about.

Having an image-only message (i.e., [img popup=1]) IMO is not too
useful; you'll almost always want some explanatory text as older clients
will not recognize the [img] tag and thus (silently) ignore it.


> It could otherwise be a real pain if we decide we want to add
> something like [img popup=1], and the client is only looking for [img]
> and suddenly doesn't work right.
>
> So in that case, an old client would still recognize that as a valid
> img tag - it wouldn't know what that popup=1 thing means, but would
> display the image just like it always had.

I agree with the general idea that options should be optional. But I
disagree that a "popup=1" option is needed at all:

We already have type information in drawinfo messages. These types can
be used to decide whether the text goes to the message area or into a
popup window. For example,

 - BOOK/CARD/PAPER/SIGN/etc. messages should display a popup window as
   these messages are (normally) generated by direct user-input (an item
   has been applied).

 - Types like COMMAND/ATTRIBUTE/SKILL/ATTACK/etc. go into the message
   area as these are generated asynchronously without direct user
   action.

That said, explicit popup=1 images for messages that go into the message
area would "be a real pain", and explicit popups for messages that are
displayed as popup windows are not too useful.


I have created a prototype implementation for JXClient. It implements
[img=<name of image>] without any options. The image is displayed as
inline within the text.

Open issue is how to request the image contents from the server:

Option a) [img=<name of image>], for example [img=altar.111]

  Problem: the "askface" protocol command needs an image number. It is
  not generally possible for a client to do a lookup from image name to
  image number. To do this, the server must send a "face2" command
  before it sends the [img] tag: the "face2" information allows the
  client to map between image name and image number.

  Alternatively, the client could do a "requestinfo image_sums" to get
  all available mappings.

Option b) [img=<number of image>], for example [img=1234]

  Problem: the server needs to convert [img=altar.111] into [img=1234]
  within msg..endmsg fields, and generate suitable "face2" commands.

Option c) [img=<name of image>] and make the 'askface' protocol command
  more flexible:

  Currently "askface <number of image>" is used. Additionally allow
  "askface <name of image>". Clients would parse "[img]" tags, then
  request the needed face by name.


I'd vote for Option c):

 - Option a) forces the server to parse all drawinfo messages for [img]
   tags. I'd rather avoid this overhead.

 - Option a) using image_sums causes a (client-sided) lag of 5 seconds
   and about 90KB overhead when connecting to the server. I don't think
   this is acceptable.

 - Option b) forces the server to convert all [img] tags within drawinfo
   messages. I'd rather avoid this overhead.

 - Option c) seems to be easily implementable (both client-side and
   server-side) and will not cause any side-effects to clients not
   knowing about the [img] tag.