Re: [crossfire] Feature proposition: [img] tag
Hello. I agree that you probably want other text - only popping up an image is not useful. Up to the map designer putting the text :) 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're talking about trunk, so let's forget older clients. We should take the opportunity to break things. 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. Yup. As for the rest, client side issues for most. Nicolas -- http://nicolas.weeger.org [Mon p'tit coin du web] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Feature proposition: [img] tag
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.
Re: [crossfire] Feature proposition: [img] tag
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? Note that anything that deals with popups can be annoying in some areas. If you read some scroll and it suddenly popped up a window, I'm not sure I'd like that. It'd probably be better as a default for the message to just be displayed, something like 'This scroll contains a map. Click on map image for a larger view (small map image displayed)' Client-side issue. My opinion: let's implement the tag in basic form, use it, and adjust later if needed. Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Feature proposition: [img] tag
Nicolas Weeger 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? Note that anything that deals with popups can be annoying in some areas. If you read some scroll and it suddenly popped up a window, I'm not sure I'd like that. It'd probably be better as a default for the message to just be displayed, something like 'This scroll contains a map. Click on map image for a larger view (small map image displayed)' Client-side issue. My opinion: let's implement the tag in basic form, use it, and adjust later if needed. Fair enough. I think my point may be more that the spec (for lack of better work) should be aware we may want to add extra specifiers, and while they client has not requirement to handle them (since we don't know what they are), it shouldn't suddenly break if they show up. 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. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Feature proposition: [img] tag
Nicolas Weeger wrote: Hello. Off the top of the head, I could imagine some quick cases, like: - Book containing information about a monster, and containing a picture of that monster - Same for other objects (more likely artifacts or unique rare stuff). However, from a tutorial perspective, displaying the different objects inline would make things much clearer, eg 'pull the lever [img=lever] to open the gate' type of thing - Last case could be maps of the area - in this case, it could just be images used from the editor and shrunk down to a smaller initial size. However, in all cases, some hint about resizing may be needed. For example, if a player is playing with a low resolution setup and has done something like -mapscale 50, probably any objects you are talking about that are map related should be similarly scaled. I'm not 100% sure on that. For large images (map areas), the client would likely need to scale down if it is too wide to fit in the message window (height isn't as much a problem, as at least you can scroll the window up/down). I'm presuming this will do inlining, and not pop up the image, but I suppose it depends on usage - one could envision maps perhaps being popped up since they are fairly standalone, but in the tutorial example, you probably don't want that popping up. Well, I was thinking of popup images, big ones, with maps or zoomed items. But regular pics inline would work too. So maybe it should be [img] and [popup] at the same time? :) More likely want to have something like an img tag with hints, for things like popup, desired size, etc. Note that anything that deals with popups can be annoying in some areas. If you read some scroll and it suddenly popped up a window, I'm not sure I'd like that. It'd probably be better as a default for the message to just be displayed, something like 'This scroll contains a map. Click on map image for a larger view (small map image displayed)' It could be really annoying if you are reading through a bunch of scrolls trying to find the one that actually has useful info to keep having windows pop up. OTOH, this is really a client side issue - up to the client to decide what to do with it. One could envision that on high res displays, an image up to 150x150 may be fine to display in the text window. But on a low res screen, anything more than about 30x30 may be too big to reasonably display. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Feature proposition: [img] tag
Hello. I'd like to suggest a [img name=xxx] tag for client-side rich tags, as defined in mediaTags. As implied, the tag would display a picture from its name :) Uses: - illustrate a text - show a bigger picture of something (map, illustration, ...). What do you think? Nicolas I guess this is supposed to pop-up an image in the client or somehow inlining an image in the output stream? Can you describe what you envision a client doing for this type of tag? Are there constraints on image size, or other attributes? Not opposed in principle, but am not real sure we have content developers that are drawing and/or acquiring such images for actual use in maps. I think you have said in the past we need content more than unused features, though I see this as having potential for richer game play. Anyway, not to discourage your efforts, I suppose that does not need to matter so much. Kevin ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Feature proposition: [img] tag
Kevin Bulgrien wrote: Hello. I'd like to suggest a [img name=xxx] tag for client-side rich tags, as defined in mediaTags. As implied, the tag would display a picture from its name :) Uses: - illustrate a text - show a bigger picture of something (map, illustration, ...). What do you think? Nicolas I guess this is supposed to pop-up an image in the client or somehow inlining an image in the output stream? Can you describe what you envision a client doing for this type of tag? Are there constraints on image size, or other attributes? Off the top of the head, I could imagine some quick cases, like: - Book containing information about a monster, and containing a picture of that monster - Same for other objects (more likely artifacts or unique rare stuff). However, from a tutorial perspective, displaying the different objects inline would make things much clearer, eg 'pull the lever [img=lever] to open the gate' type of thing - Last case could be maps of the area - in this case, it could just be images used from the editor and shrunk down to a smaller initial size. However, in all cases, some hint about resizing may be needed. For example, if a player is playing with a low resolution setup and has done something like -mapscale 50, probably any objects you are talking about that are map related should be similarly scaled. I'm not 100% sure on that. For large images (map areas), the client would likely need to scale down if it is too wide to fit in the message window (height isn't as much a problem, as at least you can scroll the window up/down). I'm presuming this will do inlining, and not pop up the image, but I suppose it depends on usage - one could envision maps perhaps being popped up since they are fairly standalone, but in the tutorial example, you probably don't want that popping up. Not opposed in principle, but am not real sure we have content developers that are drawing and/or acquiring such images for actual use in maps. I think you have said in the past we need content more than unused features, though I see this as having potential for richer game play. Anyway, not to discourage your efforts, I suppose that does not need to matter so much. At least in my examples above, those are pretty much all in game images that currently exist (the map one would have to get created, but that can be done from the editor fairly easily). I'm not 100% sure what type of images Ryo was thinking on the initial proposal. I'm not sure how hard all of this is - I'd have to look at the display widget thing to see about images, but I think the support is already pretty much there by GTK. Any image resizing can be done with the same routines that is used to rescale map/icon images. I do think some size restrictions/suggestions are warranted. Unless you are doing pop up windows, a 1000x1000 image is not that useful - it would pretty much always have to get resized to fit in the text display area. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Feature proposition: [img] tag
Hello. I'd like to suggest a [img name=xxx] tag for client-side rich tags, as defined in mediaTags. As implied, the tag would display a picture from its name :) Uses: - illustrate a text - show a bigger picture of something (map, illustration, ...). What do you think? Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Feature proposition: [img] tag
Nicolas Weeger wrote: Hello. I'd like to suggest a [img name=xxx] tag for client-side rich tags, as defined in mediaTags. As implied, the tag would display a picture from its name :) Uses: - illustrate a text - show a bigger picture of something (map, illustration, ...). I think it is a good idea. Quick thoughts: - I'd guess that this might be static content in some cases, in which is refers to an actual image name. In that case, if the client is not using image caching, it would have no idea if it has the image or not (since it only gets image numbers in that case). I think simplest all around would be to enforce the idea that clients must do image caching - it simplifies code in a bunch of areas. - I'd also imagine one could have images that are not directly associated with any archetypes (say a map of the area). There is nothing that prevents that, as IIRC the client script will pick up any files of appropriate name in the arch directory, but it may be desirable to have a storage for such images someplace else, since if they are not used by archetypes, they don't really belong in that directory structure. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
