Infocard XML coding

When you say <number>, is that the numeric equivalent of the hex value used in #RGB, or is it the number that would be the color component of the data=“0xBGRA” field? (I’m assuming the second, but want to verify)

Similarly, when it is ‘0x<hexnumber>’, I’m assuming that’s the same thing that would be in the data field, except ignoring the last (attribute) pair?</hexnumber></number>

In both cases, <number>is just a straight decimal number, equivalent to the 0x number, so it does include the attribute. e.g. #010203 == 0x03020100 == 50462976. (I think, anyway.)

If you choose to use a number for the color, one is subtracted from it, for some reason.

You mean from each color individually, or from the whole number?

The number as a whole. e.g. 50462976 -> 50462975 == 0x030200FF. (Again, I think. It’s just as easy for you to experiment, as for me.)</number>

After a week or two of work on a web-based infocard development ‘application’ for the Discovery dev team, I have a part of that code that I want to release to the dev community at large, and I hope that it is useful to someone.

A php class that facilitates working with XML infocards:
http://cshake.homeip.net/disco/class.FreelancerXML.phps

Features:

• Input and output XML card strings, user-specified encoding

• Input and output bbcode-style format

• Validates input XML infocards, giving details on any errors

• Outputs valid XHTML that shows exactly what the infocards will look like in-game (when given the blue background)

• Input and output HTML for use in, and generated by, browser-based rich-text editors (compatibility issues with adding new paragraphs or linebreaks in IE8, no support for text justification in IE or Opera, everything else works fine in those, everything works in Firefox 3.6)

• Fully usable in both 32- and 64-bit environments

The BBCode translator works for all possible XML tags, and will produce functionally identical infocard markup when converted back and forth an unlimited number of times.
The supported ‘bbcode’ tags are:```
[b] [i] [u] [align] [font] [color]

The XML writer will use the ‘pretty’ human-readable color=“red”, bold=“true” style TRA tags by default, but will also output the ‘raw’ data/mask/def style tags if desired. In the case of reading in a ‘pretty’ style infocard, the output will be identical (even if converted to bbcode and back). When reading in a ‘raw’ style infocard, the output will be identical if not converted to bbcode, but if it is converted the mask and default values may be slightly different, but will function identically in-game. This comes from me always masking all the color bits when a color is specified, and always masking 0xF8 when a font is specified, while 0x38 (font numbers 0-7) is usually used in the vanilla cards.

The code is (I believe) fully commented and readable. Except for the use of variable-type arrays it should be easy enough to port to C/C++ if the FLDev people want to improve their ‘bbcode’ editor.

Thank you very much to adoxa for the <tra> explanation here!

[edit]6/10/10 - did some fixes, changed the link to the latest version instead of a specific one.[/edit][/color][/font][/align][/u][/i][/b]</tra>

No worries. I did miss one thing, though: TRA is Text Render Attributes, not transform (and RDL is Render Display List).

Here’s a question, how can you change info cards? Can someone explain how to change them from A to Z?

Use Freelancer Developer or FLEd-ids, both are self-explaining I think…

Or Freelancer Resource Compiler.

Tried FRC, I can’t get my head around it and yes I have ran it from command line since you used that programming method.

Having a go at FLEd.

Thanks for the info guys

I was so pleased with FRC, yet no one seems to use it. I thought it was so simple, but perhaps not.

E:\contrib\games\Freelancer\frc>type test.frc
S 1 name
H 2 infocard

E:\contrib\games\Freelancer\frc>frc test

E:\contrib\games\Freelancer\frc>..\res2rc test.dll

E:\contrib\games\Freelancer\frc>type test.rc
STRINGTABLE
{
1,      "name"
}

2 23
{
L"<rdl><push>\
<text>infocard</text><para>\</para></push></rdl> "
}

```What's so hard about that?

I love your FRC adoxa its a lot easier to edit/add text then using old FLEdids.

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.