Standardized Character Format, Lets make all these tools talk to each other! Options

[Bobson]

Inspired by the discussion that started in the Upgraded Character Generator thread, I decided to split it off into it's own thread, to see if we could get any kind of consensus. I've listed some implementation-neutral terminology (mainly so everyone else knows what I'm talking about when I use them) and a first pass at some goals. Please, if you have any suggestions or disagreements, let me know.

Format: The (hopeful) end result of this thread. A definition of the structure of a Sheet that meets as many of the goals below as possible.
Sheet: A document that defines some aspect of a SR4 character, in the correct Format. A sheet is "full" when it contains an entire SR4 character.
Character: The character, or piece of a character that appears in a Sheet.

1. Human readable
   
   1. Anyone opening up a Sheet should be able to read the Character without too much effort.
      
   2. The Sheet can be used as a character sheet (or as an addition to one) as-is (although not necessarily a very friendly one)
      
   3. Formulas and calculations are not required, but support for specifying how you managed to rack up that huge number should exist
      
   4. Note that this does not specify human writable. It is perfectly acceptable for the Format to be too complex for a person to write correctly by hand (or at least, too complex to be feasible to do so on a regular basis). We shouldn't preclude human modification, but we don't need to account for it either.
2. Machine writable
   
   1. The Format should be simple enough that it is not difficult to program an application to create a Sheet.
      
   2. Applications won't have to implement writing Sheets (I can already picture an app that takes a Sheet and plugs it into your choice of 5 different character sheets for printing), but if they do, it must be in the correct Format.
3. Machine readable
   
   1. The Format needs to be rigid enough that it's possible to read a Sheet into an application and then populate data based on that Sheet.
      
   2. Applications won't have to support importing Sheets, but if they do, they need to be able to read all the statistics they want and ignore anything extra. (i.e I can load a full Sheet into an equipment application, and it'll ignore all the non-equipment).
4. Segmented
   
   1. The Format should be sub-divided in such a way that it is perfectly acceptable to only output a piece of it. (Just an equipment section, or just a custom weapon section, for instance)
      
   2. I don't know if we should try for having any single piece of a Sheet be valid on it's own, or if we want to specify certain "breakpoints" where a Sheet can start.
5. Extensible
   
   1. The Format should support adding additional information to any defined part of the format.
      
   2. It should also support the ability to add new segments without breaking backwards compatibility with existing apps.
      
   3. There should be a specific section for Application-specific information, separate from the ability to just add more data wherever the programmer feels like adding it.

So, any thoughts?

[Bobson]

This is the post that kicked off the discussion, from here. I certainly admit to swiping some of his ideas in building my list (IMG:style_emoticons/default/wink.gif)

Yes, all we have to do is decide on a format. This is vital.. it cannot be altered with every release the way the character generator is.

I would like to create an SR4 standard character file format. So far I can think of the following requirements:

It must be ascii/ansi compatible. This keeps it simple to read/write from any programming language. Ideally someone could create a character on the spreadsheet, then save it to a file and import it into a C++ or Java Character generator.

It must be written so that new fields can be added without breaking previous versions. For example, if the first version includes attributes but not calculated attributes, and then later we decide to include calculated attributes, we need to be able to add calculated attributes to the file and have the file still readable by programs written to work with the old version.

So basically, two rules:
1. TEXT
2. Backwardly compatible


I was thinking of something kind of like config files, with bracketed headers, then variable names, followed by = then their value:

[Attributes]
strength=4
agility=3
[Qualities]
cyberware compatibility=10
vindictive=5 # Random comment here
[Resources]
debt paid=0


With the above example, I would have the following guidelines:
1. All data must be under a header
2. Headers must be in square brackets []
3. Each item must have a variable followed by an equal '=' sign, followed by a value
4. # can be used for comments

Once we agree on a format, I will create a new (hidden) worksheet which lists all variables, then has a cell that links to where the values of that variable is on the sheet, then has some formatting cells. Then end result will be outputted on a visible sheet, which can manually be exported by the user, or can be exported via a macro.

I could then create a macro which reads a data file and overwrites all data on the sheet with data from the file. After that, users could easily export/import their characters between new versions of the sheet (woohoo). If any good character generator programs are created, they can write them to import these sr4 character sheets.

Oh, I would want to use an extension like 's4c' to indicate it is a 'Shadowrun 4th edition Character' file. Or it could simply be a .txt file extension.

Any thoughts or input from the community on this? I havent started implementing any of this, so I am very open to alternative ideas.

And two examples from a later post:

Ah, modded items. That does present us with a multi-level item that is not easily expressed in a .ini style text file.

Here is how I would do it:

[Custom Weapon 1]
base=SMG
mod1=ExtendedClip
mod2=Sling
maxslots=7
name=Ares Hellfire
description=An smg designed by Wolf, based on the old Uzi III model.
[Custom Armor 1]
armor=Lined Coat
mod1=Insulated
mod1rating=4

But perhaps this could be expressed in xml style:

CODE

<SR4Character>
    <Gear>
        <Ranged Weapons>
            <Standard Weapon>Ares Predator</Standard Weapon>
            <Standard Weapon>Colt America L36</Standard Weapon>
            <Custom Weapon>
                <Name>Hellfire</Name>
                <Mod>Extended Clip</Mod>
                <Mod>Sling</Mod>
                <Base>SMG</Base>
                <Description>An smg designed by Wolf, based on the old Uzi III model.</Description>
            </Custom Weapon>
        </Ranged Weapons>
        <Armor>
            <Standard Armor>Lined Coat</Standard Armor>
            <Custom Armor>
                <Name>Lined Coat</Name>
                <Base>Lined Coat</Base>
                <Mod>
                    <Type>Insulation</Type>
                    <Rating>4</Rating>
                </Mod>
            </Custom Armor>
        </Armor>
    </Gear>
</SR4Character>

The benefit I see from xml is that there is no limit to how many mods/custom items you have, whereas the .ini example names the group after the mod/custom item number.

In my opinion it would be easier to code around the Custom Weapon limit in an ini file than it would be to organize this with xml, but perhaps the xml would look more professional and be a little more standard?

Coding in xml is going to take me longer, and be less readable by a text editor, and more error prone when edited by xml editors...

[cryptoknight]

I'm not very good with XML... but it's way more flexible and useful.

I also like the fact that by going an XML route, you can create your own character sheets in whatever style you like by creating an XSLT to transform the character sheet into HTML.

[DamienKnight]

Formulas and calculations are not required, but support for specifying how you managed to rack up that huge number should exist

When I create the output for the Upgraded Character Generator, I am only outputting fields that are entered by a user, leaving out any calculated fields.

(Edit: I have been convinced to include calculated columns for the output, which my input will ignore.)

Ie. I have how many points they put into their attribute, what race they are, and what pieces of cyberware they have, but I am not outputting their final attribute after it has been modified by race, cyberware and qualities, etc.

This helps the sheet be more compatible. For instance, in varying stages of the Upgraded Character Genenerators creation, I may have had support for Cyberware but not extended races. With a non-modified attribute, my sheet would not be confused by a final modified attribute that used calculations I had not programmed for.

This is not to say the standard shouldnt include modified/calculated values, just that I will not be using them with the Generator, and most advanced generators will likely calculate these end fields themselves.

A big motivation for me for getting this standard out there is for formatted character sheets. Right now there are two limited CharSheets in the Upgraded Character Generator. Rather than creating formatted sheets for every feasible character combination inside the generator, it would be great if you could output the character data, then load it into a program that was specifically setup for turning character data into formatted sheets. This is a project I may be interested in helping with once the Character Generator is more complete.

Oh, and another note, I am currently setting up the Generator to use both XML and config.ini style output. When this is done it should provide a possible rough draft to review the merits of each and decide which will make the better standard.

[Bobson]

When I create the output for the Upgraded Character Generator, I am only outputting fields that are entered by a user, leaving out any calculated fields.

Ie. I have how many points they put into their attribute, what race they are, and what pieces of cyberware they have, but I am not outputting their final attribute after it has been modified by race, cyberware and qualities, etc.

This helps the sheet be more compatible. For instance, in varying stages of the Upgraded Character Genenerators creation, I may have had support for Cyberware but not extended races. With a non-modified attribute, my sheet would not be confused by a final modified attribute that used calculations I had not programmed for.

This is not to say the standard shouldnt include modified/calculated values, just that I will not be using them with the Generator, and most advanced generators will likely calculate these end fields themselves.

I can certainly see why you wouldn't want to import the numbers, but I think your logic above is an even stronger case for outputting the modified versions (or at least, outputting them as a total modified value). If some sheets do more calculations than others, you can't assume that the program that'll be reading your sheet will be able to do the calculations you're able to do.

What I had in mind with that specific point you quoted was basically an optional note field which might read "(4 base, +2 specialty, +1 bioware, +3 adept power)" or something, just for human consumption, and then the number stored in the field would be just 10. Or maybe we can make everything store a base and optional modified value (4/10? base="4" modified="10"? 4(+6)?) so that anything capable of doing the calculation can do so, but those that aren't (like a pure pretty-printer app) don't have to have that logic.

A big motivation for me for getting this standard out there is for formatted character sheets. Right now there are two limited CharSheets in the Upgraded Character Generator. Rather than creating formatted sheets for every feasible character combination inside the generator, it would be great if you could output the character data, then load it into a program that was specifically setup for turning character data into formatted sheets.

I would love to see a pretty-printer app written. That's also my main motivation for pushing this along. Print characters from your spreadsheet, with vehicles from zsguthy's, and other gear from Chrysalis's...

[Connor]

I'd love to see a standard XML format for character data. I'm restarting the development on a Mac-based character generator and would definitely be up for supporting such a format.

In my research I have come across this on Wordman's archive: Shadowrun XML Standard

I think it might be a good starting point for developing a 4th edition standard. Also, it seems to address some of the concerns above, such as tracking initial, modified, and augmented attributes and knowing where the bonuses come from.

[Bobson]

I'd love to see a standard XML format for character data. I'm restarting the development on a Mac-based character generator and would definitely be up for supporting such a format.

In my research I have come across this on Wordman's archive: Shadowrun XML Standard

I think it might be a good starting point for developing a 4th edition standard. Also, it seems to address some of the concerns above, such as tracking initial, modified, and augmented attributes and knowing where the bonuses come from.

Interesting. I've been working on building a Schema in my spare time at work, but it's good to have an example in front of me (I'd never worked with schemas before). I'll look it over and see what I can take away from it.

Here's what I have so far:

[ Spoiler ]

CODE

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" id="SR4">
<xsd:element name="Character">
    <xsd:complexType mixed="false">
        <xsd:all>
            <xsd:element name="Base" minOccurs="0">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="Name" minOccurs="0"/>
                        <xsd:element name="Alias" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element name="Metatype" minOccurs="0" type="MetaType"/>
                        <xsd:element name="Age" minOccurs="0"/>
                        <xsd:element name="Sex" minOccurs="0"/>
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
            <xsd:element name="Attributes" minOccurs="0">
                <xsd:complexType>
                    <xsd:all>
                        <xsd:element name="BaseAttributes" minOccurs="0">
                            <xsd:complexType>
                                <xsd:all>
                                    <xsd:element name="Body" type="Rating"/>
                                    <xsd:element name="Agility" type="Rating"/>
                                    <xsd:element name="Reaction" type="Rating"/>
                                    <xsd:element name="Strength" type="Rating"/>
                                    <xsd:element name="Charisma" type="Rating"/>
                                    <xsd:element name="Intuition" type="Rating"/>
                                    <xsd:element name="Logic" type="Rating"/>
                                    <xsd:element name="Willpower" type="Rating"/>
                                </xsd:all>
                            </xsd:complexType>
                        </xsd:element>
                        <xsd:element name="SpecialAttributes" minOccurs="0">
                            <xsd:complexType>
                                <xsd:sequence>
                                    <xsd:element name="Edge"/>
                                    <xsd:choice minOccurs="0">
                                        <xsd:element name="Magic"/>
                                        <xsd:element name="Resonance"/>
                                    </xsd:choice>
                                    <xsd:element name="Essence"/>
                                </xsd:sequence>
                            </xsd:complexType>
                        </xsd:element>
                        <xsd:element name="DerivedAttributes" minOccurs="0">
                            <xsd:complexType>
                                <xsd:all>
                                    <xsd:element name="Initative" minOccurs="1" type="Initative"/>
                                    <xsd:element name="AstralInitative" minOccurs="0" type="Initative"/>
                                    <xsd:element name="MatrixInitative" minOccurs="0" type="Initative"/>
                                </xsd:all>
                            </xsd:complexType>
                        </xsd:element>
                    </xsd:all>
                </xsd:complexType>
            </xsd:element>
            <xsd:element name="Skills" minOccurs="0">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="ActiveSkills" minOccurs="0">
                            <xsd:complexType>
                                <xsd:sequence>
                                    <xsd:element name="Skill" minOccurs="1" maxOccurs="unbounded" type="Skill">
                                    </xsd:element>
                                </xsd:sequence>
                            </xsd:complexType>
                        </xsd:element>
                        <xsd:element name="KnowledgeSkills" minOccurs="0">
                            <xsd:complexType>
                                <xsd:sequence>
                                    <xsd:element name="Skill" minOccurs="1" maxOccurs="unbounded" type="Skill"/>
                                </xsd:sequence>
                            </xsd:complexType>
                        </xsd:element>
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
            <xsd:element name="Qualities" minOccurs="0">
                <xsd:complexType>
                    <xsd:sequence>
                        <xsd:element name="Quality" type="Quality"/>
                    </xsd:sequence>
                </xsd:complexType>
            </xsd:element>
            <xsd:element name="Contacts" minOccurs="0"/>
            <xsd:element name="Gear" minOccurs="0"/>
            <xsd:element name="PlayInformation" minOccurs="0">
                <xsd:complexType>
                    <xsd:all>
                        <xsd:element name="CurrentKarma" minOccurs="0"/>
                        <xsd:element name="TotalKarma" minOccurs="0"/>
                        <xsd:element name="StreetCred" minOccurs="0"/>
                        <xsd:element name="Notoriety" minOccurs="0"/>
                        <xsd:element name="PublicAwareness" minOccurs="0"/>
                        <xsd:element name="Background" minOccurs="0"/>
                        <xsd:element name="PlayLog" minOccurs="0"/>
                    </xsd:all>
                </xsd:complexType>
            </xsd:element>
        </xsd:all>
    </xsd:complexType>
    </xsd:element>
    <xsd:complexType name="MetaType">
        <xsd:all>
            <xsd:element name="BaseRace">
                <xsd:simpleType>
                      <xsd:restriction base="xsd:string">
                    <xsd:enumeration value="Human"/>
                    <xsd:enumeration value="Elf"/>
                    <xsd:enumeration value="Troll"/>
                    <xsd:enumeration value="Dwarf"/>
                    <xsd:enumeration value="Ork"/>
                      </xsd:restriction>
                </xsd:simpleType>
            </xsd:element>
            <xsd:element name="Infection" type="xsd:string" minOccurs="0">
            </xsd:element>
        </xsd:all>
    </xsd:complexType>
    <xsd:complexType name="Initative">
        <xsd:sequence>
            <xsd:element name="InitativeScore"/>
            <xsd:element name="InitativePasses"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="Rating">
        <xsd:sequence>
            <xsd:element name="BaseRating"/>
            <xsd:element name="ModifiedRating"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="Skill">
        <xsd:sequence>
            <xsd:element name="Name"/>
            <xsd:element name="IsGrouped" type="xsd:boolean"/>
            <xsd:element name="Rating" type="Rating"/>
            <xsd:element name="Specialty" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>
    <xsd:complexType name="Quality">
        <xsd:sequence>
            <xsd:element name="Name"/>
            <xsd:element name="Cost"/>
            <xsd:element name="QualityType"/>
        </xsd:sequence>
    </xsd:complexType>

</xsd:schema>

The basic idea is that you have a <Character> which has a number of sub-tags, all optional, and most of their subtags are optional, and so on. I haven't typed any of these yet - I know I ought to do that, and I haven't touched Gear which is going to be, by far, the most complex tag. But it's a start. If someone who's worked with schemas before can give me some feedback on the technical aspects of it, I'd appreciate it. I'd also love other feedback, but I'm really shaky on the technical part.

[dog_xinu]

none of my tools currently output as plain text (the [bracketed] format mentioned above) nor XML. If I had to vote on one of the two formats I would vote on XML. I use XML files at the office (and no I am an XML expert). I think the XML format will give us the most flexibility and not lock us down so we cant expand. If we can agree on format (bracketed text vs xml and within the filetype the format/style) then I will be more than willing to change all my stuff to use that format.

I am all about using standards.

[ClearsTheScreen]

Howdy!

Yes, I am completely new here, but please read this anyways, I'm just trying to help :)

Did you think about using someting different than INI-file format or XML? Like, for example, YAML: http://en.wikipedia.org/wiki/YAML
It is better human-readable than XML, more flexible than INI format and there already are libraries for many programming languages to handle YAML files.
I don't want to seem like a pro-YAML-groupie, but it looks better readable for me than XML and the INI-like text format.
(Then there is JSON http://en.wikipedia.org/wiki/JSON which seems Java(Script)-centric, but isn't really.)

On another note, as german gamer I would like it if the character set was not restricted to ASCII/ANSI. We germans have a few sepcial characters that indeed could crop up in character sheets. And, with all due respect to the C programmers, unicode is supported in all major programming languages (as far as I know). And even if you use XML, it would be nice to be able to use all the chars one's language provides. Or at least all non-ideographic languages, since I would understand that chinese might be a little large bite to chew.

I hope this helps seeking a good format and doesn't start file format flamewar :/

(And btw, XML is also a plain text format ;^^)

[Bobson]

Did you think about using someting different than INI-file format or XML? Like, for example, YAML: http://en.wikipedia.org/wiki/YAML
It is better human-readable than XML, more flexible than INI format and there already are libraries for many programming languages to handle YAML files.
I don't want to seem like a pro-YAML-groupie, but it looks better readable for me than XML and the INI-like text format.
(Then there is JSON http://en.wikipedia.org/wiki/JSON which seems Java(Script)-centric, but isn't really.)

I hadn't considered either one - I'm not sure I've even heard of JSON, and I've only seen YAML in passing. YAML, at least, certainly looks viable (I didn't look at JSON), if someone wants to build a standard for consideration.

On another note, as german gamer I would like it if the character set was not restricted to ASCII/ANSI. We germans have a few sepcial characters that indeed could crop up in character sheets. And, with all due respect to the C programmers, unicode is supported in all major programming languages (as far as I know). And even if you use XML, it would be nice to be able to use all the chars one's language provides. Or at least all non-ideographic languages, since I would understand that chinese might be a little large bite to chew.

As I understand it, XML supports any language that shows up in Unicode, provided whatever's reading it can handle that.

[Bobson]

So, here's a implementation-neutral question for people: Is it better to list all qualities of all types (normal, metagenetic, positive, negative...) as a single list, or to break them down into categories and then list them?

Specifically, should a list look like:

• Sensitive System (-15, Normal)
• Class I Surge (5, Normal)
• Dermal Deposits (10, Metagenetic)
• Extravagant Eyes (-5, Metagenetic)

Or would it be better to do it as follows:

• Positive Qualities:
  • Class I Surge (5)
• Negative Qualities:
  • Sensitive System (-15)
• Positive Metagenetic:
  • Dermal Deposits (10)
• Negative Metagenetic:
  • Extravagant Eyes (-5)

or some combination thereof?

[DamienKnight]

So, here's a implementation-neutral question for people: Is it better to list all qualities of all types (normal, metagenetic, positive, negative...) as a single list, or to break them down into categories and then list them?

Specifically, should a list look like:

[ Spoiler ]

• Sensitive System (-15, Normal)
• Class I Surge (5, Normal)
• Dermal Deposits (10, Metagenetic)
• Extravagant Eyes (-5, Metagenetic)

Or would it be better to do it as follows:

• Positive Qualities:
  • Class I Surge (5)
• Negative Qualities:
  • Sensitive System (-15)
• Positive Metagenetic:
  • Dermal Deposits (10)
• Negative Metagenetic:
  • Extravagant Eyes (-5)

or some combination thereof?

In my opinion, they should all be in one list. Certain qualities allowed to everyone count as metagenic, while other metagenics are available only as a metagenic quality. Does it matter where it comes from? The program pulling in the data should identify the qualities as metagenic or otherwise.

If we feel the need to include that data in the saved file, then the type of quality should be an attribute of the quality listed, rather than creating seperate lists. Ie, a quality is either Positive or negative, and either Non-metagenic, only-metagenic, metagenic compatible, or only-infected.

[Bobson]

In my opinion, they should all be in one list. Certain qualities allowed to everyone count as metagenic, while other metagenics are available only as a metagenic quality. Does it matter where it comes from? The program pulling in the data should identify the qualities as metagenic or otherwise.

If we feel the need to include that data in the saved file, then the type of quality should be an attribute of the quality listed, rather than creating seperate lists. Ie, a quality is either Positive or negative, and either Non-metagenic, only-metagenic, metagenic compatible, or only-infected.

Good point. Qualities in my XML Schema are now represented (in the documentation) as an unbounded array of:

CODE

<...>
<Name> ... </Name> [1]
<Cost> ... </Cost> [1]
<QualityType> ... </QualityType> [1]
</...>

Nice and simple.

For cyberware, I broke it all down into 6 categories: Eyes (0-1), Ears (0-1), Limbs (0-4), Torso (0-1), Skull (0-1), and Misc (0-*). All of them except Misc have a Component tag which can contain any arbitrary amount of cyberware, but which only stores capacity for each item, and Misc (as well as the eyes, ears, limbs and so on themselves) track essence. So I don't support the "Anything over capacity costs essence" rule doing this... I'm not sure if that's something I should change or not.

I also have gear divided into weapons, armor, ware, vehicles, and misc.

If anyone's interested, I can keep posting interim drafts, but they get long (the current draft is 417 lines of schema, and I still need to do vehicles, technomancy, bound spirits, and contacts).

[DamienKnight]

Good point.
If anyone's interested, I can keep posting interim drafts, but they get long (the current draft is 417 lines of schema, and I still need to do vehicles, technomancy, bound spirits, and contacts).

I say post away with your examples, just wrap them in spoiler tags so they dont crowd the forum.

[dog_xinu]

I say post away with your examples, just wrap them in spoiler tags so they dont crowd the forum.

or post the file somewhere on the net and post the URL in the forums. If you need a place to host the file, I can do it on my site. Either way (spoiler tags or URL) it doesnt matter to me.

[Bobson]

I say post away with your examples, just wrap them in spoiler tags so they dont crowd the forum.

Current iteration can be found here.

Graphical representation can be found here.

[DamienKnight]

Please check out the text file outputting sample that is available in version 7 of the Upgraded Character Generator Beta:

http://forums.dumpshock.com/index.php?show...3735&st=165

There are three hidden sheets, one for Character Data Mapping, one for ouputting in ini format, one for ouputting in XML format. Unhide these pages to see the method I am using to allow Text File outputting without macros in a generator spreadsheet.

In later versions I intend to flesh this out so that it encompasses all of the character data. Feedback in that discussion is appreciated, but as it pertains to the Character Data format, please post in this thread.

[Bobson]

Updated to flesh out magic (it now has initiation, bound spirits, and traditions) and vehicles (lots and lots there)


Current iteration can be found here.

Graphical representation can be found here.


I like the solution you've come up with to display both Ini and xml files. It brought a point to my attention, too: I'm not sure how to handle tracking the BP/Karma difference in XML, or even if we should (probably).

Maybe I can modify the "Rating" type to optionally split "BaseRating" into "ChargenValue" and "KarmaValue" or something:

CODE

<Body>
   <BaseRating>4</BaseRating>
   <ModifiedRating>6</ModifiedRating>
</Body>

Or

CODE

<Body>
   <BaseRating>
      <ChargenValue>3</ChargenValue>
      <KarmaValue>4</KarmaValue>
   </BaseRating>
   <ModifiedRating>6</ModifiedRating>
</Body>

as two options for describing the stat.

[dog_xinu]

Have we decided on a format? .INI? XML? YAML? (those were the top 3 I heard bouncing around this thread).

I would love to put some time into the programs to output to the agreed upon format but I would hate to do XML (for instance) and we agree upon YAML (for instance) and then would have to redo all the output routines.

[Bobson]

Have we decided on a format? .INI? XML? YAML? (those were the top 3 I heard bouncing around this thread).

I would love to put some time into the programs to output to the agreed upon format but I would hate to do XML (for instance) and we agree upon YAML (for instance) and then would have to redo all the output routines.

Well, no one's proposed anything solid for any other standard. I hate to say that XML wins by default, since that's not a good way to do things, but I'm not building a INI or YAML standard, and no one else has stepped up yet.

I'd love it if someone else did come up with another standard, so we could compare them, take ideas from each other, and so on...

[DamienKnight]

How does the 'IsGrouped' flag work for skills? Could you list a couple of examples of how skills would be represented?

[Connor]

Maybe I can modify the "Rating" type to optionally split "BaseRating" into "ChargenValue" and "KarmaValue" or something:

[ Spoiler ]

CODE

<Body>
   <BaseRating>4</BaseRating>
   <ModifiedRating>6</ModifiedRating>
</Body>

Or

CODE

<Body>
   <BaseRating>
      <ChargenValue>3</ChargenValue>
      <KarmaValue>4</KarmaValue>
   </BaseRating>
   <ModifiedRating>6</ModifiedRating>
</Body>

as two options for describing the stat.

Might I suggest something along these lines:

CODE

<Body>
    <CurrentRating>6</CurrentRating>
    <InitialValue>3</InitialValue>
    <RacialMod>0</RacialMod>
    <Natural>3</Natural>
    <Augmentation>3</Augmentation>
    <Improvement>0</Improvement>
</Body>

Tag names of course optional and could probably be improved.

CurrentRating: The final modified value of the attribute with all modifications taken into account. Helpful here in case a program or whatever just wants this vaule and doesn't want to do any math to figure it from the other values.

InitialValue: This is what you spent BPs (or Karma) on during character generation.

RacialMod: The value that the race alters the attribute.

Natural: The natural, unaugmented value; probably InitialValue+RacialMod.

Augmentation: Cyber/Bio/Gene/Magic/etc. modifiers

Improvement: Amount improved via Karma

[Bobson]

Might I suggest something along these lines:

CODE

<Body>
    <CurrentRating>6</CurrentRating>
    <InitialValue>3</InitialValue>
    <RacialMod>0</RacialMod>
    <Natural>3</Natural>
    <Augmentation>3</Augmentation>
    <Improvement>0</Improvement>
</Body>

I like this idea. It solves the "How did you reach that number?" problem, and provides for both karma and BP ratings. Of course, CurrentRating will be the only required tag, in the spirit of minimal requirements. (IMG:style_emoticons/default/wink.gif)

[cryptoknight]

But the current rating per SR nomenclature is really 3(6) for a standard character sheet to denote both base and augmented values.

i.e. to shrug off damage you use the (6)... but to resist toxins and stuff... Dermal Plating or Cyber Limbs with customized body aren't going to help you.

[Beetle]

I'm restarting the development on a Mac-based character generator and would definitely be up for supporting such a format.

I know it's not contributing to the subject as a whole, but Conner, thanks for making a Mac-based generator. I often feel left out as a Mac guy when it comes to user developed content. As a side note, your dice roller is really handy as a GM. Let's me be sneaky and not have my players go on alert when I start grabbing a big handful of dice.