Thanks for the code. I've only done very minimal stuff with XML in VS, so it's good to have someone who knows more about it than me around

As for the validation, I'd guess it's VS2008, because I made the XML in the same program that I made the XSD in
If you want to message me a sample of the errors it's giving you, I'd love to see them.

Okay, figured out why I was getting the errors. I removed the namespaces, as I found out they're not actually required in this case, and now it works great. The code in my last post was updated.

If you want to load the XML into an XMLDocument for use while validating in the process, replace the last few lines with the following:

Any errors found during validation will be loaded into the List object during the "doc.Load(reader)" call. Handling XML in .NET is pretty easy overall. You'll find yourself using XmlNode objects all over the place. As an example, the following lines of code will grab the Base section into an XMLNode object:

Then you can access the inner nodes of that section easily.
To grab the name, use: node("Name").InnerText
To grab the BaseRace, use: node("Metatype")("BaseRace").InnerText

For grabbing a set of nodes, use this:

I have been doing some research on XML in spreadsheets for the SR4CharacterGenerator Upgraded Beta and found a great tool from microsoft that is a plugin for excel 2003.

http://msdn.microsoft.com/en-us/library/aa...office.11).aspx

This really makes it a million times easier to generate XSD files for exporting/importing XML data in a spreadsheet.

I tried using the XSD Bobson wrote and it is working a bit, but I figured out a few things.

1. Lists in XML are wonderful and definately should be a part of any character sheet XSD, but they are incompatible with Excel for Import functions, since they cannot import across Merged cells, and almost every list in any character generator spreadsheet is going to have merged cells for formatting purposes.
2. Excel 2003 spreadsheets can have multiple embedded XSD files.

Basically this means that I am going to have to setup a hidden character data page for mapping export values in order to be able to export using Bobson's XSD. Importing into the character Generator from the XSD will not be very useful because it wont work with any of the lists (Skills, Powers, Spells, Gear, etc).

For actually saving and moving characters between different versions of the spreadsheet, I am writing a custom XSD. It will basically map to any Green/Blue area in the spreadsheet. *Edit: The Character Generator available through my signature has a sample .xsd for exporting data from the Main_Sheet, and importing it back in. It currently only works with Microsoft excel.

I agree with this, although this would be a rule practiced by developers who use the Schema, and not actually reflected in the schema. Bobson, correct me if I am wrong, but as far as the schema is concerned, every field is 'optional'. If I connect your schema to the Upgraded Character Generator and only map the 'Character Name' field, I am able to successfully export and create a valid xml file, which includes only as much of the structure as in necessary to contain the character name.

This is vital, as it allows one single document to have multiple imported sources. For example lets say a programmer, we will call him Hatchetman, creates a Java program for printing formatted character sheets. His program allows manual entry of all relevant data, but does no actual data validation, and does not really aid you in filling in the blanks (ie, you list your skills, there is no list to pick from).

So Joe Schmoe shadowrun player decides to create his character in a full-featured character generator spreadsheet, then export the character data out to xml following the SRSchema-v4. He then imports the xml data into Hatchetman's program for printing out a fancy character sheet.

But... the full-featured character generator did not include an option to create a vehicle with mods... so Joe Schmoe finds another spreadsheet which is designed specifically for designing vehicles, which also happens to be setup for exporting in SRSchema-v4. He creates his tres-chique ultra fab limo, exports the vehicle's data into an .xml, and imports it into Hatcheman's Java based character sheet printing program. The import does not overwrite the data that already exists for the character, because the .xml only contains tags for the vehicle data. While it may overwrite any vehicles uploaded from the character generator, it will not overwrite character name, attributes, spells etc. that had already been uploaded.

So basically, every field technically is optional. It may be useful for developers to specify what they agree is the minimum amount of data to 'fully' display a character, but it is a moot point, as each program should be prepared to handle missing bits of data, and the scope of each spreadsheet/program may be different.

Version 9i of the Upgraded Character Generator has my first implementation of .xml output.

I created a custom .xsd for storing data from the Main_Sheet, including skills, contacts, playername, charname, race, etc.

I am allowing time for the community to provide feedback on this before I further develop the custom .xsd for loading/saving character data. Please provide feedback if you have an opportunity to test the .xml outputting features of this new version.

See the comment on the 'Save' statment above the Lengend on the Main_Sheet for instructions. This has been tested in Excel 2003 sp2 only.

That's exactly right. I've tried to make each field 'minOccurs="0"' so that it can be left out, although there's a few I either missed or chose not to add it to (for instance, if you specify <baseattributes>, you need to specify all 8, you can't just specify body or charisma). But is a perfectly valid (although pointless) character per this schema.

And congrats on figuring out how to integrate to the spreadsheet I've been kindof busy lately, which is why I haven't been around much, and it's great to come back to see such a big step forward

I'll try and test it out this week, and let you know how it goes.


As a side note, I've fixed the links to download v4.

I have released version 9j of the Upgraded Character Generator (see link in my signature for download). The new version has a complete .xsd integrated with it which allows users to export all of their character data into an .xml, which can then be used to import them back into a blank sheet. This hopefully means characters will not have to be completely recreated each time a new version is released. Please check the .xml export feature out and let me know if you have any suggestions.

One of the biggest problems I am having with importing .xml in excel is that it seems to always import numbers as text. The field it is importing to is specified as 'Number' with no decimal, and the .xsd restricts the node to have integer only... but to no avail.

This is a real problem since the numbers as text break certain features, such as nuyen symbol formatting, and hampers math formulas that depend on the imported field.

Also, more important to this thread, I have embedded SRSchema_v4.xsd into the 9j spreadsheet. As I warned before, this will only be usable as an export, as many of its nodes do not correspond with data entry nodes on my spreadsheet.

Basically, I created a new sheet in the workbook called 'xmlExport', and started a list of nodes from the Community standard. I then wrote next to the list formulas for retrieving the values from the rest of the workbook, then took the SRSchema_v4 that I had embedded and started mapping nodes to the formula cells in xmlExport. I only got as far as the base nodes and some of the attribute nodes.

Bobson, if you could setup a character w/ Name, Alias, Race etc., and assign their attributes in my Chargen sheet, then export it to the SRSchema_v4 (Character_Map) and see if the xml created is along the lines you were shooting for, that would be spectacular.

Note that Chargen attribute node will only display BP. My sheet has no way of distinguishing between starting Karma-bought attributes and Karma-raised attributes.

Also, I am not sure what you are going for with the Additional Dice-Source/#Dice nodes. Should I list 'Wares Damage Reduction" and "1" or would you want it broken down to which ware gave which dice?

Wow what a cool spreadsheet! The neat thing about using the .xml files is that any future program could import them as well. Computer games, character creation programs, RPG table programs, whatever.

Good job!

it looks like you are up to version 4 of the xsd file. If that is the current version of the file I'll could start working up a style sheet that will generate an xhtml character sheet.

One other thing you may consider is adding a version attribute to the character element to forestall any update issues.

FL

I note that under skills you have an unlimited number of specs per skill..... Am I missing a rule somewhere or is this an oversite?

Has to be an oversite as only one specialization is allowed per skill per RAW.

Great thread. I'm in the process of writing a SR character generator, and my initial pass through ended up going the ini like route. But after asking around, it seems like xml is the way to go. This generator will be multi-platform. I'm writing it in openBSD in C++, but I will have ports for both windows and mac.

Do you guys have a preference for how the xml looks? I'd like to code up the attributes to xml tomorrow.

So from what I take out of this so far, is that you've established an XML standard, but you still don't have anything better than an Spreadsheet. a very nice spreadsheet, but a spreadsheet none the less.

I would like to propose my free services as a programmer.
I know HTML/CSS, PHP, MySQL, Javascript for online programming
I know C++/Java for application programming

assuming I build both tools to allow printing and XML exporting/import you could use the online or offline tools that I would build (with help please) without too much trouble.

Right now I'm reading a friend's SR4th Books to get the gist of how to even get a hold of it logically, but also if someone could provide a mock up of the XML (or even a fully done character in XML) that I can test around with that would be great.

Edit: also, I run a Linux box, I'm assuming there's at least one Mac user around, so I would be building to be used with all three OSes (Windows, Mac , Linux)

I've got three computers here on my desk...linux, xp and osx.

I'm certain willing and able to test as I have all those OS bases covered at home.

Frantastic, I also found the Schema and Example XML files for this case. Once I have the logic down in my head for the Character Generator, we can then really get start on doing something awesome.

Cool! I'm working on the basic design and algorithms for some stuff for Google wave. I'm making a dice roller robot but I will move on to charsheet/map gadgets so I'll try to get that char sheet for SR4 on this standard. Howver keeping in mind that that will be one of the last things i work on the roller and map gadget are much more important than the charsheet.

Well, I already have a good SR4 dice parser (in my blog) along with a great Standard Dice Notation parser. If you need to use them (all you really need is the UI stuff to your preferences, and maybe a tweak or two) feel free to use my Dice roller and parser code. (in PHP, but I'm sure you can kinda convert it to your needs)

Well, after much procrastination I've finally made a start on a java-based character generator. One thing I've been wondering about, though: Along with the standard file format for character sheets, has anyone thought about a standard format for library data? It seems a little inefficient if there's so many character generator apps under development, but all the authors have to input massive lists of gear prices and similar. That's the main thing that put me off updating my generator to handle SR.

(sorry if I've missed an obvious post somewhere, I've been lurking sporadically for a while but haven't seen it mentioned)


I'd expect to represent this by something like ... (off the top of my head)

Some optional tags to represent circumstances where the stat is different. A generator could add these as a result of ware/qualities/etc. If I were writing a prettyprinter, I'd put these in brackets under the stat (because that's how I do it on hand-written sheets). Maybe give the user a list and ask them which ones they want to display.



My preference would be to just display these skills. If a generator has added them, its likely that the user has entered them.

I am not sure that an actual data library can be created due to copyright issues... I think I read somewhere that the non excel character generators actually violate microsoft's copyrights to shadowrun programs.

Microsoft sold that license to Smith and Tinker, a company ran by Jordan Weisman, one of the original SR creators.
http://en.wikipedia.org/wiki/Shadowrun#Video_games

While Microsoft was quick to beat down any Fan created digital SR content for a long time, near the end they were allowing Shadowrun Online to continue development.

Shadowrun Online died, but now Smith and Tinker have hinted at created an SR mmo. To my knowledge, Smith and Tinker have not used the license to stop any Fan Created data.

However, creating a database of Shadowrun data does not Violate the license that was previously owned by Microsoft and is currently owned by Smith and Tinker. It violates the License owned by Catalyst labs, who sells table upon table of shadowrun data in digital format (Books in PDF).

I do not see any reason that Excel spreadsheets are excluded... they include digital content that is Owned by Catalyst. My guess is that since they do not have a competing character Generating program, they allow character generators to be passed around.

To be safe, a generator needs to not be independent of the SR books. Ie. You may include a list of Qualities available, and even a list of BP and karma costs, but detailed descriptions from the books should not be included. Instead, include references to the books themselves (Book and Page number) so players can look up the details themselves. In that way, the character sheet serves to assist character creation, without substituting ownership of the actual Catalyst owned materials.

In fact, it could even promote sales. Imagine you own only the SR4 Core Book, and decide to create a character with one of the many generators out there. Say you select qualities and see interesting looking qualities that are not in the Core book. You see a reference on the generator that says the quality is in the Runners Companion... so now you want to go Buy the Runners Companion so you can read up on this quality you saw on the Generator.

At any rate, information from the books should not include detailed descriptions, and definately not text copied and pasted out of the books. As far as pure lists go, the unthreatened existence of character generators suggests that Catalyst will not try and stop you. Just remember, their survival depends on people buying books, and so long as your community driven content does not keep people from needing the books, then Catalyst is probably not going to waste the time and effort suing you.

Also, the writers are cool people, and we should respect the excellent game they have worked hard to deliver to us.

I've maintained a semblance of documentation alongside my data files. If anyone wants, we can use those as a starting point.

This is one of the things we found at PCGen, we've had many people post on our mailing list that they've bought several books because we listed the mechanical effects and a short description of the feat/spell/class (for anyone not familiar with v3.5 of "The game that causes cancer", the feats and spells and such have a one or two line benefit text that we use).

I suppose this thread is technically dead but I thought I'd point out two possible errors.

EssenceCost is duplicated under Cybereye, Cyberear, Cyberlimb, and Cybertorso.
Rating is duplicated for Cybereye and Cyberear.

Edit: Scratch that, the datafiles are no longer available online. Hmm, guess I'll have to fix 'em and post them somewhere.

Ack, why didn't I see this thread earlier? I'd like to know where this ended and something that I can compare with since my chargen tool already uses XML but attributes etc. have not exactly the same values or fields as suggested above.

Is this standard dead? I've been trying to sink my teeth back into programming, particularly C#, and figured a Shadowrun Character Generator/Character Management program would be a good place to start. I'd love to code to a community standard, but the lack of activity is saddening.

I'd gladly let you see/use or work on the c# code I did for my chargen. If you want to cooperate or simply take over or use is fine with me. I'd love to get a reason to resume the project.

I'd be interested in checking it out at least. Like I said, I'm fairly new/rusty at programming, so this is a learning experience. I'd also planned on doing a BP creator/manager since that's what my group is using, but looking at yours might give some ideas/reference.

Is there a current status to this project? For the record, I was thinking it might be cool to parse an XML with a standard format but system agnostic. Honestly, this whole project (generic chargen) could be implemented in any of a dozen different ways and no one is the best (thought platform agnostic is always considered a plus, so Java, python, XML + XSLT, etc).

I'm also interested in the state of this standard.

Once upon a time (before I washed my hands of SR4 forever) I had a project for an SR4 character generator that had a partly-specified XML format together with some CSS to produce a reasonably human-viewable character sheet. I don't remember if there was enough there to be useful, and this was all within roughly a month or two of SR4's release so there's probably a bunch of new cases to handle, but if I can dig up what I had I'll post it on the off-chance that it might be useful.

Edit: never volunteer to share work you did five years ago. If I can fight through the embarrassment I might still post it, but I'm not sure there's anything worthwhile there.

~J