[crossfire] Feature proposition: [img] tag

[Mark Wedel]

Andreas Kirschbaum wrote:
 >>>> 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.

  I agree that you probably want other text - only popping up an image is not 
useful.

  I see it more as a hint to the client that this could be something to display 
in its own window and not inline.  Even if displayed in its own window, I think 
the text that goes with it should be displayed in that window.

  Older clients pose more an issue.  If you are doing something like maps, it 
seems fairly difficult to try to support that with old clients (you could 
perhaps do an ASCII map).  You also get the case of you probably really don't 
want to display that ASCII map if you can display the actual PNG image.

  We could perhaps do something like 'if you support images, use this text, if 
you don't, use this other text', but that seems overly complicated.

  As long as the major clients support it, I think it is reasonable to state 
that there is no requirement to be backwards compatible - I think that adds a 
lot of complication, and it is simpler to just have the users use the latest client.

  That said, no reason to make things intentionally difficult - one could 
imagine there are cases where it is inconvenient for the player to bring up the 
image, so if the message can make things useful (or at least have a description) 
makes things friendlier.

  For example, having a message that is just something like 'this scroll 
contains a map [img=...]' is not very useful - more useful is something like 
'this scroll contains a map of the area around Navar City', 'or contains a map 
showing where dungeon ... is'

  In that way, the player has enough information to know if they really care 
what that image is.  Maybe you already know what is around Navar City - so don't 
care about that map, but don't know where a dungeon is, so do care about that one.

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

  That was just an example - that was the only option I could think of off the 
top of my head - there could be others.  But my point wasn't to propose those 
options, just we should design for possibility that there may be options we add 
to that tag.


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

  I suppose this could be something that is settable on the client.  I 
personally find pop up windows pretty annoying, and would only want to use them 
when really necessary.

  I don't consider a book that has 3 lines of text something that is needed to 
got into a pop up window - that can display just fine in the messages pane.

  But I don't really want different behavior based on the content of the book - 
it would be odd/confusing for some books to display in the message pane, and 
others to do a pop up window.

  Note also that one problem is that the book/card/paper, etc, types are based 
to object type/subtype.  Thus, if you wanted to make objects of that type that 
don't do popups, you now need a new object type/subtype (maybe mapping to an 
existing readable type).  That in itself isn't really flexible either.

 >
 > 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):

  I agree.  Since we don't have any image names that start with numbers, it is 
pretty easy for the server to parse that difference.

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

  It probably wouldn't be as bad as you might things, since in general the 
messages would be short, and it would only need to be done when the client tries 
to access something that has that type.  The server could optimize this by 
checking for img tags at load time and setting a field to denote if the message 
has one or not - if it doesn't, then the server doesn't need to do any work.

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

  The problem here also is that image numbers are not consistent - so it is not 
like the server can do this just once - it has to do it every time the message 
is used.  In some ways, this is more costly as option A, as it has to 
copy/modify the message string at each use.

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

  I agree.