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

[DamienKnight]

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.

That nomenclature is insufficient, as augmentation is non-specific as to what dice pools it affects. Sure, if you have a natural 3 body and 3 points of bone density you have 6 dice for damage and knockdown, and only 3 for everything else...
But what if you have a Superthyroid Gland? It raises body by 1, but not just for damage tests and knockdown, but also for toxins and such.

Really Body is the most complicated attribute as it is used to resist many kinds of damage, and it is possible to have bonuses to some but maybe not all types of damages.

I can list a few possibilities, all which can be independently enhanced through cyber/bio/adept bonuses:

Damage Resistance (generic, ie. Falling, getting shot, your-head-asplode, etc).
Natural Toxins
Ingested
Inhaled
Contact
Diseases
Non-Natural Toxins
Ingested
Inhaled
Contact
Knockdown
Healing
Endurance
Physical Magical Damage

I think the simplist denotation is 3(4)+3, indicating 3 natural, +1 augmented body from bioware(counts for all tests), +3 body for generic damage tests. For the xml standard, do we need to seperately track all of these modifiers? It shouldnt be manditory, but support for each variable seems like a good idea.

[dobbersp]

having the natural and modified body (and other stats) should be sufficient for the standard.
Determining the other values should be related to the other portions of the standard
(the cyberware and cyberparts, which you are referencing, determine pools for the tests, and not the stats themselves)

Or the additional attributes should at least be optional.

[Bobson]

having the natural and modified body (and other stats) should be sufficient for the standard.
Determining the other values should be related to the other portions of the standard
(the cyberware and cyberparts, which you are referencing, determine pools for the tests, and not the stats themselves)

Or the additional attributes should at least be optional.

Definitely optional - the question really is is it worth including them? For an answer to that, I tend to look at a prettyprinter app (PPA), since that's what I imagine the major consumer of the format to be (you build in your favorite generator(s), combine, and then feed to the PPA to get a character sheet in the format you want). Based on that perspective, we want to include as many possible pre-calculated values as possible, because a PPA wouldn't neccesarily have huge data sets of all the cyberware and what it does to your sheet...

[Dumori]

yeah for a PPA or a some thing like that we would want it as indeepth as we could.

[DireRadiant]

You need to make sure you separate the storage format for the data, and the process for building up a character sheet from it. As you've discovered character attribute bonuses related to gear can be added to the character in different ways. The rules for when that Body value from gear applies varies, so it can't simply be added to the characters base Body.

[Bobson]

You need to make sure you separate the storage format for the data, and the process for building up a character sheet from it. As you've discovered character attribute bonuses related to gear can be added to the character in different ways. The rules for when that Body value from gear applies varies, so it can't simply be added to the characters base Body.

I think what I'm going to say is that I'm not going to modify the Body attribute, but I'll throw in a "Damage Resistance" type tag somewhere, where calculated values for any or all of them can be added. But it'd only be for permanent modifiers - anything that's gear based should be noted under gear in the GameEffects tag. A PPA can just concatenate all GameEffects tags into a misc section. Or I might add just a "Body for Damage rEsistance" type of tag into Body, and let the rest go into the gear listing...

[DamienKnight]

Might I suggest something along these lines:

[ Spoiler ]

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

This seems sufficient. Bob, any chance of getting an updated graphical representation?

[Bobson]

This seems sufficient. Bob, any chance of getting an updated graphical representation?

I'll have one up on Monday, probably in the afternoon. I'll implement something like the above quote into the rating values for attributes (and possibly skills, although they wouldn't need all the fields), and finish adding the technomancer block (my current project), then post it.

The graphics aren't going to be quite as pretty, since I had to switch editors - I'm working from demo software, and I finally had to reboot and close the old one (which just refuses to start once it's one-week trial is up), and the new one, while it has a month-long trial, isn't as pretty. They should be similar enough to be useful, though. I think I'll also try to post a sample XML with all optional fields specified, since that's one thing the new one does better. (IMG:style_emoticons/default/smile.gif)

[Bobson]

I'll have one up on Monday, probably in the afternoon. I'll implement something like the above quote into the rating values for attributes (and possibly skills, although they wouldn't need all the fields), and finish adding the technomancer block (my current project), then post it.

The graphics aren't going to be quite as pretty, since I had to switch editors - I'm working from demo software, and I finally had to reboot and close the old one (which just refuses to start once it's one-week trial is up), and the new one, while it has a month-long trial, isn't as pretty. They should be similar enough to be useful, though. I think I'll also try to post a sample XML with all optional fields specified, since that's one thing the new one does better. (IMG:style_emoticons/default/smile.gif)

Ok, it's up.

Schema document
Visual representation
Sample XML (it's valid, but not all that useful, and I didn't do more than skim through it briefly)

[dobbersp]

whenever i get around to implementing this, im going to need some help figuring out what all this means.
I have no idea what type of UML that is....and i dont really know xml, though i have an idea of how it generally works.

dont explain anything yet, because im not ready to take on this aspect of the project yet, but when the time comes
i hope i'll have some help from you kind folks ^^


It looks good btw.


d:- D

PS (examples like that "valid but not useful" one would be sweet too)

[Bobson]

whenever i get around to implementing this, im going to need some help figuring out what all this means.
I have no idea what type of UML that is....and i dont really know xml, though i have an idea of how it generally works.

dont explain anything yet, because im not ready to take on this aspect of the project yet, but when the time comes
i hope i'll have some help from you kind folks ^^

I'll be glad to help (IMG:style_emoticons/default/smile.gif)

The short description is that the XML schema is an XML document which specifies what a "valid" format for another XML is. It specifies what tags can appear where, restrictions on the values that can appear in those tags, and so on. You can implement a reader for a schema, and then be assured that you will be able to process any XML that validates against that schema, and you can write out XML that matches a schema and be assured that any reader that implements it will handle it correctly.

PS (examples like that "valid but not useful" one would be sweet too)

Once it's done I'll probably create a few examples, using my 800-bp characters from that thread. That'll show how a character can advance with karma, and it'll try out all the basic sections as well as the magic section and several types of gear (cyberware, vehicles, and armor).

[dobbersp]

hokay, whenever you can get an example up, I would love to take a look at it.

I also had a question about skill names.
If the names of the skills implemented in the different programs using the standard are slightly off,
they wont work right?

say, "Athletics" and "athletics"
or similar minor discrepancies (other than capitalization, like a misspelling)

[ahammer]

hokay, whenever you can get an example up, I would love to take a look at it.

I also had a question about skill names.
If the names of the skills implemented in the different programs using the standard are slightly off,
they wont work right?

say, "Athletics" and "athletics"
or similar minor discrepancies (other than capitalization, like a misspelling)

base on what I have seen I see no reason you could not program it to work misspelling and all.

i know im kind of late to this game but my I suget that you put what the char has and the esses/ karma cost for cyberwere/biowere on two diffrent xml sheets and some other cost ie( adpt power). so that if I take a char from one game and we change gm or groups you can redo you char using there xml setting file.

also I think some of your items need a flag for prebuild or postbuild. im going to want to be able to show how much the char would cost in build and karma cost currently and I dont want to have the item he got after he made his char to facter into this.(or even show both values)

also I think somone sould make a char gen in Runtime Language like java or mono/.net so that it would work with all os with one code base (and exeable) open source of couse but that sould wait till we get close to the format being done.
(edit: miss the fact somone is doing one in vb.net opps)

[dobbersp]

also I think somone sould make a char gen in Runtime Language like java or mono/.net so that it would work with all os with one code base (and exeable) open source of couse but that sould wait till we get close to the format being done.
(edit: miss the fact somone is doing one in vb.net opps)

This is off topic, but do you know if its possible to run a vb.net prog on another OS?

*I just looked at the mono page, and it looks like you can actually run .NET progs with it on Linux and MAC without recompiling....
thats pretty rad...

can anyone confirm this?

[ahammer]

yes that is why I lested it as a opp like java make it once and you done.

thou you do have to be on the look out becuse somthing just dont work in mono yet but it getting closer to .net every day now

4.0 spost to be out about the same time as msoft it helps that it is part of msoft deal with Novell.

also it works a lot better if you uses gtk dll on windows and linux then winforms but winforms work mostly last time I tryed it.

asp.net work two look a wikipeda to see that it does infact work.

[Bobson]

hokay, whenever you can get an example up, I would love to take a look at it.

Work's been really hectic lately so I haven't had much chance to work on it. [insert mutters about one month trial being wasted.] I'll see what I can do tomorrow or early next week as far as getting an actual character up.

I also had a question about skill names.
If the names of the skills implemented in the different programs using the standard are slightly off,
they wont work right?

say, "Athletics" and "athletics"
or similar minor discrepancies (other than capitalization, like a misspelling)

XML is, by default, not case sensitive, but interpretation is up to each individual parser. "Athletics" and "athletics" should be treated equivalently, but "Athletics" and "Athlatics" would be two separate skills. A parser could look at the latter and error with an "I don't know that skill" or silently ignore it, as the programmer desires. Either is acceptable behavior.

also I think some of your items need a flag for prebuild or postbuild. im going to want to be able to show how much the char would cost in build and karma cost currently and I dont want to have the item he got after he made his char to facter into this.(or even show both values)

I like this idea, but it's not really feasible to include in the spec itself. You can always save different copies of the file for each session that it changes. However, I can easily add a <RunLog> section, which lets you specify how much karma and nuyen you get from a run, and a <SpendingLog> section where you can record what you spent Karma and Nuyen on. That'll let you reverse-engineer the starting character from an experienced one, and without adding a flag to every tag in the system.

[dobbersp]

no worries bobson.
ive still got finals this week, and some semblance of a 'thesis paper' to write.

Im thinking my implementation of a "parser"
will list everything that is not recognized from the import in a message after importing.

something like, the following items were not recognized:
Skill-"Hopscotch"
Skill-"Bar Tending"
Gear-"stink bomb"
. . .
. . .
etc.

It sounded like DamienKnight is going to implement the standard too,
so it will be baller when this all works.
I can only aspire to create a chargen that has half the features that that excel sheet has....

carry on.

[ahammer]

I like this idea, but it's not really feasible to include in the spec itself. You can always save different copies of the file for each session that it changes. However, I can easily add a <RunLog> section, which lets you specify how much karma and nuyen you get from a run, and a <SpendingLog> section where you can record what you spent Karma and Nuyen on. That'll let you reverse-engineer the starting character from an experienced one, and without adding a flag to every tag in the system.

would you mind if I use your xml as a base and change it to how I think it sould be done. then we can make up are mind as a group who format would be better overall?

[Bobson]

would you mind if I use your xml as a base and change it to how I think it sould be done. then we can make up are mind as a group who format would be better overall?

Please do!

But don't tell Damien. He might write something into his spreadsheet to wipe both our hard drives in revenge for making it harder on him (IMG:style_emoticons/default/nyahnyah.gif)

[Bobson]

Work's been really hectic lately so I haven't had much chance to work on it. [insert mutters about one month trial being wasted.] I'll see what I can do tomorrow or early next week as far as getting an actual character up.

Ok, all done. Also, a new version of the spec, and I realized I'm still missing Foci, among other things I didn't need for this character, so they'll be in v5.

Here's what I have now:
The XSD itself.
The graphical representation of the XSD.
Sir Thomas from the 800-BP thread, in XML. Most of him anyway.

[dobbersp]

sweet.

this thread desperately needed another post. I'm working on getting my website up so i can host the prog.
then its finals, then trouble shooting/support, and finally implementing the import/export. oiy.

[Narse]

That nomenclature is insufficient...
...

I can list a few possibilities, all which can be independently enhanced through cyber/bio/adept bonuses:

Damage Resistance (generic, ie. Falling, getting shot, your-head-asplode, etc).
Natural Toxins
Ingested
Inhaled
Contact
Diseases
Non-Natural Toxins
Ingested
Inhaled
Contact
Knockdown
Healing
Endurance
Physical Magical Damage

I think the simplist denotation is 3(4)+3, indicating 3 natural, +1 augmented body from bioware(counts for all tests), +3 body for generic damage tests. For the xml standard, do we need to seperately track all of these modifiers? It shouldnt be manditory, but support for each variable seems like a good idea.

Not to single out this one post or anything but I want to weigh in on the topic of which information to include. A while ago I did some initial pre-design thinking about how to implement a program that would allow simulation of the game mechanics. I decided to give up because it would be more than I could handle, for precisely this reason. There are likely hundreds of what I call 'fields' that a player/GM may need to know for a character. By 'fields' I refer to any data that would need to be represented or calculated for a character (or other game world entity, including things like vehicles) to ensure proper interaction with the game environment. Generally these fields are determined from basic character statistics (e.g. attribute + skill rating for skill rolls) and some miscellaneous modifiers. The combination of numerous possible sources for miscellaneous modifiers (cyber & bio, magic, adept powers, gear, etc.) and the fact that some that seem to be the same are actually distinct, as illustrated by the above post, meaning that there are likely hundreds of these that any one piece of cyber or other modifying effect could affect, makes calculating all of the field values (each is necessary in certain circumstances) a Herculean task.

To provide some example of how many of these fields may need to be calculated: all of those listed in the above post are fields, many skills have multiple fields as modifiers apply to only one type of test: e.g. visual perception, auditory perception, olfactory perception, tactile perception (although some of these modifiers only have to do with feeling temperature!), gustatory perception (all of these have things that modify them listed in the books). Furthermore there are also dicepools (all of which are have values that may need to be calculated and therefore require a field to store them, even if it is just a part of the code that stores how they are calculated) that don't depend on skills: the above mentioned damage resistance, attribute only tests (as mentioned in SR4), adiction tests, and many tests defined in only one place. There are also non-dice pool field values that need to be calculated like the ever important health boxes (8 + cieling(body/2) + cyberlimbs, assuming I'm not forgeting something else that adds or subtracts from the number), or worn armor totals (just thinking about how to code calcualting the effective armor totals of a character with armor from several sources is unpleasant.) But this category also includes things like initiative passes, movement speeds and jumping distances.

Figuring out a good way to store and negotiate the tangled web of effects won't be easy (at least not for someone like me) but should be able to be done if one is willing to spend the time and be really anal about it. But the clincher is exclusivity. Many modifiers don't stack with one another. And I for one can't figure out a good way to check for these conflicts, at least not without committing to the most painful way of coding the calculations I can think of.

Essentially my points are as follows:
1. There are too many derived values to reasonably include in your specification
2. There is no point to include derived values that are so difficult to calculate in code that it is unlikely that any program would do so or at least do so correctly.

Fortuantely some of the values are little used and most are typically much easier for human's to calculate (if they remember everything that affects the field in question, that is the crux of the problem isn't it?). These are values that you shouldn't worry about including in your standard. A good example would be movement speed: it doesn't come into play terribly often, the values are all centrally located in one table, and very few effects modify the values. I think you should let the end users worry about things like movement speed.
Unfortunately, there are some values, like damage resistance, that are very important, come up frequently, and are difficult to calculate (Tons of things modify damage resistance... ugh, it also doesn't help that effective armor is a comonent of damage resitance, that is difficult enough to calculate and it doesn't help that the rules are vague enough as to leave some room for interpretation on how all the forms of armor effects stack with each other.)

So I suppose my recomendation is to only concentrate on really important derived values, like number of health boxes, or current essence value, and make any derived value fields that are difficult to calculate (e.g. damage resistance) optional, if you do feel that they must be included.

Anyhow, best of luck to you all, I look forward to seeing a more complete version of your standard.

[dobbersp]

ok, how does all this stuff work? If anyone knows about some handy Visual Basic.net stuff thats already implemented for XML do let me know.
I dont want to do more work than i have to.

what is this buisness about validating a file? How do you go about checking a file against a schema?

what do all of the images mean on the diagram? the empty white square?
the plack squares that look like parallel and series circuits?
the right angle made of three black squares?

I get the cardinality, what with the 0..1 and stuff, but im gonna have to take a crash course in all of this to get it up and running.

d:- D

[Bobson]

ok, how does all this stuff work? If anyone knows about some handy Visual Basic.net stuff thats already implemented for XML do let me know.
I dont want to do more work than i have to.

I don't know of any examples off hand, but there's specifically an XMLDocument class you can work with. Just google it and you can find some examples and tutorials.

what is this buisness about validating a file? How do you go about checking a file against a schema?

Basically, an XML document can be well-formed (which means all the tags are made correctly, they're all closed appropriately and so on) and/or valid (which means that when compared to the xsd / XML Schema it follows all the rules that the schema specifies). I'm not entirely sure how to code something that checks the schema, but I know there's validators available online where you can paste in the XML and the schema and it'll compare them.

what do all of the images mean on the diagram? the empty white square?
the plack squares that look like parallel and series circuits?
the right angle made of three black squares?

I get the cardinality, what with the 0..1 and stuff, but im gonna have to take a crash course in all of this to get it up and running.

d:- D

The blank square has no real meaning. It just says "There's a bunch of stuff here." The black squares linked in various ways are more interesting.

The four squares linked in series are just that - a series (xsd:sequence). All the elements linked to it have to appear in that order (if they appear at all). Thus <Base><Name></Name><Alias></Alias></Base> is valid, but <Base><Alias></Alias><Name></Name></Base> is not.

The parallel black boxes mean that there need be no sequence to the tags linked to it (xsd:all). Thus the attributes can be in any order. I started out preferring that, but there's things you can do with sequences you can't do with alls, so I've been gradually converting them over.

The line running into 4 vertical squares is a choice element. You can only put one of the tags it connects to there. So you can have a Magic or a Resonance attribute between Edge and Essence, but you can't have both. And because of the 0..1 under it, you can also have neither.

The plus-in-a-box symbol after an element means that there's more elements specified under it, but that they're not showing because they're described further down in the document. I didn't realize it didn't tell you what it was, but it's one of the tags starting with a white box towards the end - you should be able to figure out what which one is relevant (attributes tie to the Rating type).

The three boxes stacked in a right angle mean almost the same thing. But rather than being a tag which contains all the other tags referenced at the bottom, it denotes that all those tags are put right there. Again, the details are specified down at the bottom, with the tags that start with that symbol. As an example, look at the RatedItem group (near the bottom, just below a quarter of the way up the document). It references the Item group which is described just above it. So anywhere that you see RatedItem in the full spec above, it means "in this spot, you can have any of the tags listed under the Item group, followed by an optional Rating tag".

I know it's not very intuitive, but the rules for it are pretty simple once you figure them out (it took me quite a while to get the hang of it). Let me know if that wasn't clear enough and I'll try to explain more.

[Deus Innomen]

Hey folks. New to the forums, new-ish to Shadowrun, long time developer. Thought I'd poke my head in and help out where I can.

It's actually fairly easy to use XSDs to validate XML documents in .NET 2.0 and beyond. Take a look at the following block of sample code:

CODE

    Imports System.Collections.Generic
    Imports System.IO
    Imports System.Xml
    Imports System.Xml.Schema

    Private validationErrors As New List(Of String)

    Sub Main()
        Dim schemas As New XmlSchemaSet()
        schemas.Add(Nothing, "SR4.xsd")

        Dim settings As New XmlReaderSettings()
        settings.ValidationType = ValidationType.Schema
        settings.Schemas = schemas
        AddHandler settings.ValidationEventHandler, AddressOf ValidationCallback

        Dim reader As XmlReader = XmlReader.Create("SampleChar.xml", settings)
        While reader.Read()

        End While

        Console.WriteLine("Number of errors found: " & validationErrors.Count.ToString())
    End Sub

    Private Sub ValidationCallback(ByVal sender As Object, ByVal e As ValidationEventArgs)
        validationErrors.Add(e.Message)
    End Sub

This assumes that the XSD is saved as SR4.xsd and the character is saved in SampleChar.xml.

Hope that helps. And doesn't add too much confusion to the process.

Updated to correct code to prevent the validation errors. It was only happening when I was trying to assign a namespace to the files.