Infocard XML coding

adoxa, could you submit your various tools to our download section? I think they fit there better than in forum posts as attachments.

aren’t they all stored on adoxa’s homepage?

@Sethernis: Thank you.

@wodk4: Yeah, I should, just too lazy. Plus I only do minimal testing, so I’d like a bit of feedback before committing. Plugins I won’t, though, just too many of 'em. Hm, could probably zip 'em all together as a collection.

@Gisteron: Yes, all my tools are on my site. Only a few plugins are, but I’ll eventually get around to putting them all on.

adoxa, FRC looks neat, I’m sure it will be useful for devs.

For people who don’t deal with the dlls themselves, lets say people who are just the content generation part of a dev team and all just submit resources to the final person who puts them into a dll, I’ve got some things that might make life a bit easier. Because even though many of us can look at raw code and visualize what it will look like, it’s sometimes nice to not have to deal with the low level stuff, and a real preview is always nice.

Here is a set of 3 related functions, all using the XML translator class I posted above, that are an extremely simple copy/paste/click interface for editing cards on the fly and generating valid xml for them. These are by no means intended to be used for major batch jobs, that’s a whole different kettle of fish, but for quick validation I’ve already found them useful myself.

#1 - XML Preview - given raw XML, will validate the syntax and display it in HTML how it will look ingame
#2 - BBCode Editor - using bbcode, will generate XML from the bbcode and show the in-game preview
#3 - Rich-Text Editor - edit rich-text cards, generate XML, and preview. I’ve tested it to work for copy/pasting formatting from a MS Word 2007 document in the current version of Firefox with Windows XP and 7, and it handles paragraphs, color, and sometimes alignment too. Other combinations of OS/Browser/Text Editor may or may not work for importing directly, but it will correctly handle any formatting you give it on the page itself. (IE8/FF/Opera/Safari, Chrome doesn’t have the API last I tested)

I’m not trying to step over your feet here adoxa, but when working with infocard people in the Disco team, they seemed to like these for the ease of use. If someone finds bugs that aren’t already listed, feel free to send me a PM here.

adoxa wrote:

[…]
data=“65281” (0x0000FF01) -> red + bold

Does anyone know how to make cyan + bold?

Or, even better, an overview of how to make colors + attributes? I had a vague memory of a fairly complete description of all the various options and/or an editor rendering text strings that could be pasted into FLED-Ids, but all I could find is this thread. And, maybe the info might is here - if so, I’m just not smart enough to deduce it.

http://www.asciizeichen.de/RGB.html for the first 6 numbers after 0x, guess the last are used for bold, normal and italic but dont know the code

Huor wrote:
http://www.asciizeichen.de/RGB.html for the first 6 numbers after 0x, guess the last are used for bold, normal and italic but dont know the code

Thanx!! Will it work wth hex (0x) values, or will I have to recalculate them into decimals? Of well, I can find that out soon enough.

FriendlyFire wrote:
FLDev’ll generate the code for you, otherwise remember the data tag has to be of the format BGR (RGB in reverse order), so say #AAF289 bold becomes 0x89F2AA01. You can write them directly in hex provided you prepend them with 0x.

Thanks!! It now all makes sense to me

A couple of years ago I wrote a script to validate all Discovery development infocards based on Adoxa’s description in #4.
Today I ran it against our server-side overrides in dsacesrv.cfg and it was upset about this in an infocard:
<tra color=“0x-524056832” italic=“default”>(notice the minus before the number and the extra digit)
FL seems to tolerate this instead of treating it as invalid XML, producing this:

Which seems to be the same if the minus and extra digit are removed.</tra>

It’s not invalid XML, but it is an invalid unsigned number. Recall that hex numbers have one subtracted, so the conversion to 0 produces a value of -1, which is white.