Re: [crossfire] msg/endmsg in maps/objects
Kevin R. Bulgrien wrote: Mark Wedel wrote: On a broader scale, there is a problem with most of the msg/endmsg in maps/objects. They are pre-formatted for a certain width. If your text window is wider, it isn't terrible - it just doesn't use the full width. If your window is a bit smaller, it gets really ugly, as it will display a full line, then perhaps 1 word, then another full line, etc. Ideally, I think most of the newlines from the msg/endmsg structures should be removed - the client is plenty smart enough to do proper wrapping. There are also a few messages which should have the '[fixed]' tag added, since they are maps or diagrams, and just don't look right when printed with the proportional font. I have been wondering about this for some time. I agree the formatting needs to go in general. The formatting is not consistent and so one never knows how to format or reformat content. It is good to know that it is okay to string the paragraphs on the same line. Most newlines is right, considering that some should be left in order to separate paragraphs and/or allow certain lines of text to be rendered on a line by itself. I'd ask also for some clarification of whether there is a common practice to follow with respect to whitespace between sentences. There is a variation in that one space is used much of the time, but two spaces also exists. I'd be tempted to say that for simplicity, we use whatever is most prevalent right now. So if the most prevalent is 1 space after the period, that is what we should use. I'm not sure if it is worth it to go through all the maps and update just for that. But if doing it as part of a newline conversion, etc it could make sense to fix those. And a lot of these changes also need to be made in the server, in terms of the messages it prints. In cases where there are several draw_infos() strung together, in many cases I've been changing that to just one draw_info on the basis to let the client wrap the text. In some cases, this doesn't work because there is specific formatting, but not that often. How about blank lines? Is this discouraged in order to consume less vertical space, or is it seen to be acceptable for improving readability for longer multi-paragraph output? I'd say they should be there for readability. Without a blank line, it can be very difficult to really see where the paragraph breaks are. In addition, this really only comes up with NPC messages - generally, I'd say those are a relatively small portion of the total text output (things like attack messages being much more prevalant), and I can't imagine a couple extra newlines being that big a deal. Is there an advantage to using leading whitespace acceptable to inset example text? I think so, but wonder what others might think. Depends on what you mean by example text. Also, look at the server/doc/mediaTags file - it supports a limited number of HTML like tags. What this really means is that within a message itself, you can change various attributes (like make the text italic, or change the color, use fixed width fonts, etc). Using those tags is probably better than using indentation. Is there a document anywhere that might be used to help map editors know how to write these messages? If not, a wiki page might be in order. These topics are of special interest to me since I have an interest in working on grammatical, spelling, and conversation improvements on maps as I play them. I don't think there is a document on indentation, punctuation, etc. So one should probably be written. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Gridarta CFJavaEditor Jar?
On Sunday 24 September 2006 11:45 pm Kevin R. Bulgrien wrote: Could someone make a jar file from the CFJavaEditor sources on the Gridarta project? I have so far been unable to get a working build environment. I get errors when I try the command-line build instructions in INSTALL.txt, and I am having great difficultly getting ant installed. [...] I was provided with a working copy by one of the Gridarta developers and have it availalble here: http://www.eracc.com/files/crossfire/CFJavaEditor.jar. The same developer has been given FTP access to that directory to keep an up to date copy of CFJavaEditor.jar available. I was unable to use the arch directory from SVN and thought it was my build of Gridarta at fault but that turned out not to be the case. Apparently the problem was with many of the graphics being converted to text during the migration from CVS to SVN. I understand Mark Wedel has now fixed this problem(?). Gene Alexander -- Mandriva Linux release 2006.0 (Official) for i586 09:59:10 up 3 days, 2:30, 14 users, load average: 0.26, 0.20, 0.18 ERA Computers Consulting - http://www.eracc.com/ - get VOIP here! eComStation, Linux, FreeBSD, OpenServer UnixWare preloads sales ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] draw_ext_info/message update/redo
On 9/24/06, Mark Wedel [EMAIL PROTECTED] wrote: ... The main advantages I see of the drawextinfo is this: - Support for the media tags (bold text, different fonts, etc). I'd expect these to be infrequently used, as in general the global tag/attribute should be used. But I think use in NPC messages giving clues what can be discussed with them by doing bold or underline would be very good (we should probalby decide what the form for that syntax highlighting it is, so that it is consistent accross all the maps/NPCs) Or we could make a new tag like [triggerword]. The server then could decide on it's formatting. Also, if it is passed to the client, the client could make the hilighted phrase clickable. - Instead of the server telling the client the color to use and the client blindly following it, the client now knows the type of messages. So with some extra logic, I could decide that I want the level gain message to be in a specific font in bright green, even though the server says those should be in red. It would also allow for easier filtering (if chat/say/shout have their own types, easier to have a conversation pane, etc). Very useful in my opinion. I really like the colors that me chats: uses. Though that could be considered a bug. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] draw_ext_info/message update/redo
Andrew Fuchs wrote: On 9/24/06, Mark Wedel [EMAIL PROTECTED] wrote: ... The main advantages I see of the drawextinfo is this: - Support for the media tags (bold text, different fonts, etc). I'd expect these to be infrequently used, as in general the global tag/attribute should be used. But I think use in NPC messages giving clues what can be discussed with them by doing bold or underline would be very good (we should probalby decide what the form for that syntax highlighting it is, so that it is consistent accross all the maps/NPCs) Or we could make a new tag like [triggerword]. The server then could decide on it's formatting. Also, if it is passed to the client, the client could make the hilighted phrase clickable. That could be reasonable. However, I think that should just get passed to the client, and the client decides what to do with it, not the server. My general philosophy is to try to offload those decisions/that work to the client - in a sense, we should try not to hold preferences on the server unless they are a per character type of issue. And if passed to the client, it could of course make it clickable (just generated the appropriate say command). A possible interesting extension could be something like [img=sword.111] or the like. The image itself being one of the images in the arch directory. Then you actually could have pictures of monsters with the scroll that describes them, etc. And from a more complex level, you could actually have real maps to places, not the ascii maps. The map would have to be put in the arch tree, and a the images collected, but that is certainly better than anything we have now. - Instead of the server telling the client the color to use and the client blindly following it, the client now knows the type of messages. So with some extra logic, I could decide that I want the level gain message to be in a specific font in bright green, even though the server says those should be in red. It would also allow for easier filtering (if chat/say/shout have their own types, easier to have a conversation pane, etc). Very useful in my opinion. I really like the colors that me chats: uses. Though that could be considered a bug. To me, the filter/font is less desirable than the filtering. With this change, it will now be possible to really have a tab just for chat related messages, etc. I think to actually be able to set colors/fonts, we may need to trim down the number of subtypes, and/or make some common values. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
