Help - Search - Members - Calendar
Full Version: Standardized Character Format
Dumpshock Forums > Discussion > Community Projects
Pages: 1, 2
Bobson
Oct 29 2008, 09:29 PM
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
Oct 29 2008, 09:44 PM
This is the post that kicked off the discussion, from here. I certainly admit to swiping some of his ideas in building my list wink.gif

QUOTE (DamienKnight @ Oct 21 2008, 10:27 PM) *
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:

QUOTE (DamienKnight @ Oct 23 2008, 04:32 PM) *
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
Oct 30 2008, 03:36 PM
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
Oct 30 2008, 06:17 PM
QUOTE
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
Oct 30 2008, 08:02 PM
QUOTE (DamienKnight @ Oct 30 2008, 02:17 PM) *
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.


QUOTE
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
Nov 1 2008, 01:38 AM
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
Nov 2 2008, 07:02 AM
QUOTE (Connor @ Oct 31 2008, 08:38 PM) *
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 ]


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
Nov 2 2008, 05:33 PM
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
Nov 3 2008, 01:40 PM
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
Nov 3 2008, 02:54 PM
QUOTE (ClearsTheScreen @ Nov 3 2008, 08:40 AM) *
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.

QUOTE
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
Nov 3 2008, 03:35 PM
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
Nov 3 2008, 04:05 PM
QUOTE (Bobson @ Nov 3 2008, 11:35 AM) *
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 ]

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
Nov 3 2008, 11:12 PM
QUOTE (DamienKnight @ Nov 3 2008, 11:05 AM) *
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
Nov 4 2008, 07:25 PM
QUOTE (Bobson @ Nov 3 2008, 07:12 PM) *
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
Nov 4 2008, 08:00 PM
QUOTE (DamienKnight @ Nov 4 2008, 02:25 PM) *
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
Nov 4 2008, 08:41 PM
QUOTE (DamienKnight @ Nov 4 2008, 02:25 PM) *
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
Nov 6 2008, 05:48 PM
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
Nov 6 2008, 08:46 PM
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
Nov 7 2008, 01:47 AM
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
Nov 7 2008, 01:59 AM
QUOTE (dog_xinu @ Nov 6 2008, 08:47 PM) *
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
Nov 7 2008, 05:18 PM
How does the 'IsGrouped' flag work for skills? Could you list a couple of examples of how skills would be represented?
Connor
Nov 8 2008, 05:58 AM
QUOTE (Bobson @ Nov 6 2008, 02:46 PM) *
Maybe I can modify the "Rating" type to optionally split "BaseRating" into "ChargenValue" and "KarmaValue" or something:

[ Spoiler ]


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
Nov 10 2008, 02:07 AM
QUOTE (Connor @ Nov 8 2008, 12:58 AM) *
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. wink.gif
cryptoknight
Nov 10 2008, 04:17 PM
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
Nov 14 2008, 09:39 PM
QUOTE (Connor @ Oct 31 2008, 08:38 PM) *
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.
DamienKnight
Nov 17 2008, 04:10 PM
QUOTE (cryptoknight @ Nov 10 2008, 12:17 PM) *
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
Nov 18 2008, 02:36 AM
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
Nov 18 2008, 01:54 PM
QUOTE (dobbersp @ Nov 17 2008, 09:36 PM) *
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
Nov 18 2008, 05:24 PM
yeah for a PPA or a some thing like that we would want it as indeepth as we could.
DireRadiant
Nov 18 2008, 06:59 PM
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
Nov 19 2008, 07:56 PM
QUOTE (DireRadiant @ Nov 18 2008, 01:59 PM) *
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
Nov 22 2008, 07:45 AM
QUOTE (Connor @ Nov 8 2008, 01:58 AM) *
Might I suggest something along these lines:
[ Spoiler ]


This seems sufficient. Bob, any chance of getting an updated graphical representation?
Bobson
Nov 22 2008, 10:50 PM
QUOTE (DamienKnight @ Nov 22 2008, 02:45 AM) *
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. smile.gif
Bobson
Nov 24 2008, 07:39 PM
QUOTE (Bobson @ Nov 22 2008, 05:50 PM) *
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. 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
Nov 26 2008, 01:04 AM
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
Nov 26 2008, 02:06 PM
QUOTE (dobbersp @ Nov 25 2008, 08:04 PM) *
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 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.

QUOTE
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
Dec 10 2008, 09:48 AM
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
Dec 10 2008, 06:01 PM
QUOTE (dobbersp @ Dec 10 2008, 02:48 AM) *
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
Dec 10 2008, 09:37 PM
QUOTE (ahammer @ Dec 10 2008, 10:01 AM) *
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
Dec 10 2008, 11:28 PM
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
Dec 11 2008, 05:55 AM
QUOTE (dobbersp @ Dec 10 2008, 04:48 AM) *
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.

QUOTE
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.

QUOTE (ahammer @ Dec 10 2008, 01:01 PM) *
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
Dec 11 2008, 08:33 AM
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
Dec 11 2008, 08:04 PM
QUOTE (Bobson @ Dec 10 2008, 10:55 PM) *
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
Dec 11 2008, 10:17 PM
QUOTE (ahammer @ Dec 11 2008, 03:04 PM) *
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 nyahnyah.gif
Bobson
Dec 11 2008, 11:26 PM
QUOTE (Bobson @ Dec 11 2008, 12:55 AM) *
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
Dec 12 2008, 11:12 PM
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
Dec 17 2008, 06:00 AM
QUOTE (DamienKnight @ Nov 17 2008, 10:10 AM) *
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
Dec 17 2008, 07:49 AM
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
Dec 17 2008, 02:35 PM
QUOTE (dobbersp @ Dec 17 2008, 02:49 AM) *
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.

QUOTE
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.

QUOTE
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
Dec 17 2008, 03:00 PM
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.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Dumpshock Forums © 2001-2012