http://www.andargor.com/

SRD 3.5 XML and MySQL Database v1.2 Released
MySQL and XML data from the D&D 3.5 SRD, with full text. Includes Epic
and Psionic data with the XPH errata.

This was extracted directly from the RSRD, and is what I used to do my
stuff.

Currently included:

     * Classes
     * Feats
     * Monsters
     * Powers
     * Skills
     * Spells

Changes:

     * Classes in spell levels converted to long names
     * Added spell_stat and spell_type fields to classes
     * Removed stray anchor tag in full texts
     * Fixed monster stat blocks
     * Miscellaneous data fixes

There is no pretense at a "good" XML format, it is mainly a flat
format suitable for databases. But it makes parsing easier. Some
fields actually have HTML in them, but it's well-formed XML as well.



HTML Offline Searchable SRD 3.5 v1.2 released
Pure XML version is also available.

Changes in 1.2

     * Dragons fully statted.
     * XPH errata included.
     * Skills were combined into a single document, including Epic use
of skills.
     * Many data errors fixed.
     * Added indices: spells by level, powers by level, monsters by CR,
monsters by LA.


Changes in 1.1

     * The search function has been revamped. It should be a lot more
accurate now.
     * Bookmark functionality has been added. However, this is HIGHLY
experimental. The vagrancies of browsers, cookie quirks and javascript
security setting makes saving bookmark data very difficult. The script
may ask you to allow to save to file, if cookies are not available. If
so, your bookmarks will be saved under the menu directory, in
bookmarks.txt. In any case, use at your own risk. I'll try to
stabilize the feature in the next releases
       Bookmarks support drag and drop. Just drag a bookmark image
under another, and it'll be moved.
     * Some UI changes, as you may have noticed. You can hide the stuff
you don't use, but those settings are not saved
     * Miscellaneous content fixes were performed
     * Keyword hyperlinking is (hopefully) more accurate. Instead of
75% accuracy, it's now around 90%.


Enjoy!

Andargor

Two things I would like to work on are:

1.  The GUI front end.  Part of the GUI work should be making it very
easy for people to new classes, feats, etc.  If we can make it easy to
add that information the buy in for this program will be fairly quick...

2.  Switching out MySQL for Derby (What Cloudscape became when it was
open sourced).  I don't think that Derby is better the MySQL but it IS
a java program.  People wouldn't have to download and install MySQL to
get things to work...just a Java VM would be enough.

Thoughts?  Opinions about where I should put my time at first?

later,
Brian F.

--- In pcgen-xml@yahoogroups.com, "andargor" <andargor@y...> wrote:
>
> http://www.andargor.com/
>
> SRD 3.5 XML and MySQL Database v1.2 Released
> MySQL and XML data from the D&D 3.5 SRD, with full text. Includes Epic
> and Psionic data with the XPH errata.
>
> This was extracted directly from the RSRD, and is what I used to do my
> stuff.
>
> Currently included:
>
>     * Classes
>     * Feats
>     * Monsters
>     * Powers
>     * Skills
>     * Spells
>
> Changes:
>
>     * Classes in spell levels converted to long names
>     * Added spell_stat and spell_type fields to classes
>     * Removed stray anchor tag in full texts
>     * Fixed monster stat blocks
>     * Miscellaneous data fixes
>
> There is no pretense at a "good" XML format, it is mainly a flat
> format suitable for databases. But it makes parsing easier. Some
> fields actually have HTML in them, but it's well-formed XML as well.
>
>
>
> HTML Offline Searchable SRD 3.5 v1.2 released
> Pure XML version is also available.
>
> Changes in 1.2
>
>     * Dragons fully statted.
>     * XPH errata included.
>     * Skills were combined into a single document, including Epic use
> of skills.
>     * Many data errors fixed.
>     * Added indices: spells by level, powers by level, monsters by CR,
> monsters by LA.
>
>
> Changes in 1.1
>
>     * The search function has been revamped. It should be a lot more
> accurate now.
>     * Bookmark functionality has been added. However, this is HIGHLY
> experimental. The vagrancies of browsers, cookie quirks and javascript
> security setting makes saving bookmark data very difficult. The script
> may ask you to allow to save to file, if cookies are not available. If
> so, your bookmarks will be saved under the menu directory, in
> bookmarks.txt. In any case, use at your own risk. I'll try to
> stabilize the feature in the next releases
>       Bookmarks support drag and drop. Just drag a bookmark image
> under another, and it'll be moved.
>     * Some UI changes, as you may have noticed. You can hide the stuff
> you don't use, but those settings are not saved
>     * Miscellaneous content fixes were performed
>     * Keyword hyperlinking is (hopefully) more accurate. Instead of
> 75% accuracy, it's now around 90%.
>
>
> Enjoy!
>
> Andargor

--- In pcgen-xml@yahoogroups.com, ysgarran@c... wrote:

> Thoughts?  Opinions about where I should put my time at first?
>
> later,
> Brian F.

Well, Frugal's got the "heart" pretty much done. I would guess that
the GUI would be important. No offense to Frugal, but it's nice to
have a focus on one aspect, and the demo was focused on the engine
aspect.

The idea would be to decouple the GUI from the engine internals. Just
have calls to the the engine. Certainly not any GUI code in the
enigne. This allows other plugins as well. I've only glanced at the
source code, so I don't know if it's possible.

On my side I'm still working on data. I don't know to what extent
Frugal has used it, or what's needed. He's written some XSLT/Java to
convert my data, but I guess my aim would be to streamline that
process and perhaps break down the data to "program friendly" level.

Andargor

> The idea would be to decouple the GUI from the engine internals. Just
> have calls to the the engine. Certainly not any GUI code in the
> enigne. This allows other plugins as well. I've only glanced at the
> source code, so I don't know if it's possible.

Definately, keep the two clearly seperated.  The worst case would be
an extra layer to keep the two seperated...even then it would be worth
while to keep the Model-View-Controller (or something else, as long as
the view code is does not become intertwined with the model code).

Brian F.

andargor wrote:

>Well, Frugal's got the "heart" pretty much done. I would guess that
>the GUI would be important. No offense to Frugal, but it's nice to
>have a focus on one aspect, and the demo was focused on the engine
>aspect.
>
>The idea would be to decouple the GUI from the engine internals. Just
>have calls to the the engine. Certainly not any GUI code in the
>enigne. This allows other plugins as well. I've only glanced at the
>source code, so I don't know if it's possible.
>
>

Are you implying that the GUI I have thrown together is not the
prettiest, most useful thing you have ever seen ;O)

There are a couple of things I wanted to try to imlpement. I am very
pleased with the skills tab, it is much more obvious what has been spent
where. I also like the bonus tab, where you can see exactly what goes to
make up any given bonus in the system.

regards,
Frugal

--- In pcgen-xml@yahoogroups.com, Frugal <frugal@p...> wrote:
> andargor wrote:
> Are you implying that the GUI I have thrown together is not the
> prettiest, most useful thing you have ever seen ;O)
>

Yes. :P

:)

Andargor

> end of a cable modem so do not expect blistering speed).
> <https://www.purplewombat.co.uk:444/repos/charactergen> and a viewcvs
> view of the code at: <http://www.purplewombat.co.uk/viewcvs>

Hi Frugal,

It looks like you are using eclipse for the development here.  Are you
using any particular eclipse plug-in for subversion?  Do you have a
cvs tool I can grab the code to play with?

thanks,
Brian F.

Hello All,

I am new to this project for PCGen.  Can someone direct me to
'beginner/newb' posts or FAQ's for using PCGen-XML.

Thanks

--- In pcgen-xml@yahoogroups.com, "pvoice70" <perry.curry@g...> wrote:
>
> Hello All,
>
> I am new to this project for PCGen.  Can someone direct me to
> 'beginner/newb' posts or FAQ's for using PCGen-XML.
>
> Thanks

I'm sorry to say that an XML version of PCGen doesn't exist, and plans
for it have been shelved for quite a while.

An alternative is being worked on by namely Frugal. Check out his
posts here, and if you're a coder, maybe you can help him out.

There is, of course, no documentation yet on anything XML here.

Andargor

It's not big and it's not clever, but it does work (sort of).

I have ironed out enuogh bugs that I an no longer ashamed to show this
to other people. It does not do very much at the moment but it shows
promise of what you can do with XML based data.

And I am going to be very stupid and release it 5 minutes before I go
away for 5 days ;)

http://www.purplewombat.co.uk/projects/charactergen/

regarsd,
Frugal

Can I get some basic help here setting things up with maven?  Default
goals don't seem to do much and I dont recognize the correct targets out
of the list of maven goals
(maven -g).

The 'chargen-0.1.jar' file that I'm generating doesn't have anything in
it besides a manifest file and license.txt.

Any help would be appreciated.

later,
Brian F.


Frugal wrote:

>It's not big and it's not clever, but it does work (sort of).
>
>I have ironed out enuogh bugs that I an no longer ashamed to show this
>to other people. It does not do very much at the moment but it shows
>promise of what you can do with XML based data.
>
>And I am going to be very stupid and release it 5 minutes before I go
>away for 5 days ;)
>
>http://www.purplewombat.co.uk/projects/charactergen/
>
>regarsd,
>Frugal
>
>
>

On Friday 15 April 2005 21:02, Ysgarran wrote:
> Can I get some basic help here setting things up with maven?  Default
> goals don't seem to do much and I dont recognize the correct targets out
> of the list of maven goals
> (maven -g).
>
> The 'chargen-0.1.jar' file that I'm generating doesn't have anything in
> it besides a manifest file and license.txt.
>
> Any help would be appreciated.

See, I told you it was a bad idea posting that before I went away for a few
days ;)

The top level goal you want will be "deploy-all" That will build all of the
jar files are populate a top level directory of 'target/deploy/' with
everything you need to run the app. Once you have done a successfull
deploy-all you can cd into target/deploy and run 'java -jar
chargen-gui-0.1.jar'.

You might need to install the emma plugin (emma.sf.net).

I have this horrible tendancy to tinker with software and I can not remember
if the project will compile without emma or not. I will try to experiment
when this teething baby lets me near a keyboard ;)

--
regards,
Frugal

Still having some problems.   Lets start from the very top:
What version of the JVM did you use?
   I tried JDK 1.5 and JDK 1.4.2_06
   I would think that you would be isolated from classpath issued (thats
the point of Maven and Ant like builds, right?) but I could be wrong here.

the problem I have doesn't seem to be related to the code coverage tool
you are using, emma.
the exact error I'm currently getting is:

Overriding previous definition of reference to maven.castor.classpath
     [echo] classpath=
     [echo] C:\Documents and
Settings\Fred/.maven/repository/castor/jars/castor-0.9.5-xml.jar
     [echo] Generating sources for ./src/pcgen.xsd

BUILD FAILED
File...... c:\Java\games\charactergen-0.1\maven.xml
Element... maven:reactor
Line...... 5
Column.... 137
Unable to obtain goal [java:compile] -- C:\Documents and
Settings\Fred\.maven\cache\maven-castor-plugin-1.2\plugin.jelly:92:38:
<ant:java>java.lang.NoClassDefFoundError:
org/apache/xml/serialize/XMLSerializer
Total time: 2 seconds
Finished at: Mon Apr 18 15:14:06 EDT 2005

Frugal, you got any thoughts or ideas here?

later,
Brian.

>See, I told you it was a bad idea posting that before I went away for a few
>days ;)
>
>The top level goal you want will be "deploy-all" That will build all of the
>jar files are populate a top level directory of 'target/deploy/' with
>everything you need to run the app. Once you have done a successfull
>deploy-all you can cd into target/deploy and run 'java -jar
>chargen-gui-0.1.jar'.
>
>You might need to install the emma plugin (emma.sf.net).
>
>I have this horrible tendancy to tinker with software and I can not remember
>if the project will compile without emma or not. I will try to experiment
>when this teething baby lets me near a keyboard ;)
>
>--
>regards,
>Frugal
>
>

I've updated the SRD 3.5 on my site ( http://www.andargor.com ). Changes:

- Many error fixes.
- Domains are now in the database and XML data formats.

Further, these formats are available:

Hyperlinked HTML Files, for browsing (Monster images included)

     * Offline Searchable HTML version of the SRD 3.5
     * Plain Hyperlinked HTML version of the SRD 3.5
     * Windows Help File (.chm) version


XML files, for parsing

     * Custom XML version with XSL for HTML conversion
     * Hyperlinked DocBook XML version. Monster images included.


Database

     * MySQL and XML data


Enjoy!

Andargor

Hi group, searching in the Internet I found two products for XML which
incorporate a very robust debugger for XSL/XSLT, I would like you to
see these products and then, give me your opinion about the
development environment or recommend me some other that you know.


XML IDE's
- http://xslt-process.sourceforge.net
- http://www.mentattech.com/themes/mentat/alchemist/index.html

Regards,

Widfrid

Yo les tengo una propuesta, ya que se cambiaria el modelo de guardar
datos, por que no diseñar un nuevo modelo de datos mas sencillo y
desarrollar a partir de ese modelo.
Yo cree un modelo XML que me funciona para guardar mis personajes, se
encuenta en los archivos como CGargola-XML-Model, como soy de México
esta en español y todavía no esta desarrollado correctamente el DTD y
el XSD, y la presentación del XSLT es muy sencilla.
Estoy pensando en desarrollar mi propio programa pero al encontrar que
el PCGen y que esta desarrollando su versión XML, me detuve para ver si
el proyecto se encamina por donde yo y mi grupo queremos o desarrollar
el nuestro propio, espero se tome en cuenta más a los jugadores de
latino América, ya que no todos leen ingles.
Espero les sirva mi archivo y consideren mi propuesta.
Alograg
PS:
Please read Spanish, much work costs to me to express me in english, if
you cannot, i will try to express me in english.
Thanks

--- In pcgen-xml@yahoogroups.com, "Gargola" <alograg@y...> wrote:
> Yo les tengo una propuesta, ya que se cambiaria el modelo de guardar
> datos, por que no diseñar un nuevo modelo de datos mas sencillo y
> desarrollar a partir de ese modelo.
> Yo cree un modelo XML que me funciona para guardar mis personajes, se
> encuenta en los archivos como CGargola-XML-Model, como soy de México
> esta en español y todavía no esta desarrollado correctamente el DTD y
> el XSD, y la presentación del XSLT es muy sencilla.
> Estoy pensando en desarrollar mi propio programa pero al encontrar que
> el PCGen y que esta desarrollando su versión XML, me detuve para ver si
> el proyecto se encamina por donde yo y mi grupo queremos o desarrollar
> el nuestro propio, espero se tome en cuenta más a los jugadores de
> latino América, ya que no todos leen ingles.
> Espero les sirva mi archivo y consideren mi propuesta.
> Alograg
> PS:
> Please read Spanish, much work costs to me to express me in english, if
> you cannot, i will try to express me in english.
> Thanks

Hola,

I don't speak spanish myself (just survival spanish for trips :), but
I used Google Translate to read your message. I'll post here so
non-spanish speakers can understand what you are saying. I'll answer
after.

Translation (approximate):

"I have a proposal to them, since exchange the model to keep data, so
that not to design a new simple data modeling but and to develop from
that model.  I create I model XML that works me to keep my personages,
encuenta in the archives like CGargola-XML-Model, as I am still of
Mexico this in Spanish and not this correctly developed to the DTD and
the XSD, and the presentation of the XSLT is very simple.  I am
thinking about developing to my own program but when finding that the
PCGen and that this developing its version XML, I stopped to see if
the project is directed by where I and my group we want or to develop
the our own one, I hope is taken into account more the players from
Latin America, since all do not read ingles.  I hope serves my file to
them and consider my proposal."



Unfortunately, currently there are no plans to convert PCGen data sets
to XML, although this has been discussed for quite some time.

I've been thinking about some sort of conversion program to/from
XML/PCGen data set for a long time. However I don't have the time for
it, and it would be moderately difficult because of the PCGen internal
handling of feats and class features.

I did open a FREQ to allow OpenRPG import/export (they use XML), which
would essentially allow people to share character files. I don't think
its a high priority, but I am still hoping it will be implemented.

As for your own custom XML format, from what I understand, I would
suggest you use a "well known" format so that you can reuse it with
other tools. Perhaps taking a look at the formats for OpenRPG,
DMGenie, and other tools would help.

As for Spanish support, I'm not sure, but I think PCGen supports it...
Are you looking for Spanish output sheets? Or perhaps you were talking
about an XML output sheet in Spanish? That is already supported.

I hope I understood correctly... :)

Regards,

Andargor

>I've been thinking about some sort of conversion program to/from
>XML/PCGen data set for a long time. However I don't have the time for
>it, and it would be moderately difficult because of the PCGen internal
>handling of feats and class features.
>
>
>
Back a ways when one of the programmers went into PCGen and put in a
persistence layer I wrote some code that converted the LST files into
XML files.  I believe that particular set of code is long gone but I
will probalby take a look for it anyways when I get home tonight.

I did not read the LST files myself, what I did is put hooks into the
persistence layer.  That code would take the PCGen internal
representation and write it back out into an XML format.  What do you
think, would it be usefull to go back down that path or not?

Ysgarran.

p.s.
Now that I think about it, that code is probably sitting on a hard drive
that is not currently connected to any computers.  I have my doubts
about how usefull it is at this moment since I believe that PCGen code
base has migrated quite a bit since that time.

On Thu, Sep 29, 2005 at 12:34:29PM -0400, Ysgarran wrote:
>
> >I've been thinking about some sort of conversion program to/from
> >XML/PCGen data set for a long time. However I don't have the time for
> >it, and it would be moderately difficult because of the PCGen internal
> >handling of feats and class features.
>
> Back a ways when one of the programmers went into PCGen and put in a
> persistence layer I wrote some code that converted the LST files into
> XML files.  I believe that particular set of code is long gone but I
> will probalby take a look for it anyways when I get home tonight.
>
> I did not read the LST files myself, what I did is put hooks into the
> persistence layer.  That code would take the PCGen internal
> representation and write it back out into an XML format.  What do you
> think, would it be usefull to go back down that path or not?

Not terribly, I think.  It was decided a long time (*long* time -- about
three years ago) that simply changing the syntax from not-XML-LST to
XML-LST just makes the data more verbose without adding much benefit,
and that it would be better to actually model the data rather than the
LST files.

There would be some benefit from the XML perspective in modeling LST
with XML -- makes it easier to work with other XML tools, at least --
but PCGen wouldn't gain anything from this at this point.  It would
largely simplify the parsing code, I think, but that would be new code
that would need to be tested, etc., and would invalidate the tools data
monkeys currently use.

That said, it looks like the changes being made now are bringing the
data model somewhat closer to what we were developing here a couple of
years ago.  Not entirely, but with the changes being made to the
architecture it may be possible to bring a reasonable XML representation
to the program.

Just chatting with Devon.  The code changes will make it easier, and he
wants to use XML when CDOM gets brought in.  At least for the character
file format -- he still wants to use the LST files for other data, for
now at least.

*However*, what he's just asked me for is an interesting thing... and
pretty simple, actually.


Keith
--
Keith Davies                 "Always code as if the guy who ends up
keith.davies@...     maintaining your code is a psychopath
keith.davies@...        who knows where you live."
http://www.kjdavies.org/        -- Damian Conway

I did not read the LST files myself, what I did is put hooks into the
persistence layer. That code would take the PCGen internal
representation and write it back out into an XML format. What do you
think, would it be usefull to go back down that path or not? 

Not terribly, I think. It was decided a long time (*long* time -- about
three years ago) that simply changing the syntax from not-XML-LST to
XML-LST just makes the data more verbose without adding much benefit,
and that it would be better to actually model the data rather than the
LST files.

Hi All,

I just finished an interesting IM conversation with Devon.  Here's what
he's looking for -- and it's pretty easy, I think.

Continue using LST format for PCC files, for now at least.  We may
revisit it later and convert the LST files to XML.

The character file would consist of three sections.  Each section is
optional, but there are reasons for each.


Section 1

   The first is the primary working data for PCGen.  It logs all
   construction decisions, but no consequences.  For instance, it will
   log that you add a level of fighter, the hit points gained, the feat
   selected, and where the skill points were assigned.

   By using this structure (which is similar to that of CDOM), it becomes
   possible to roll back decisions.  It'll be possible to remove levels,
   for example.

Section 2

   The second expands on the first, showing the 'non-decision' data.
   For instance, where section shows "add a level of fighter, gain 8 hit
   points, take Cleave, assign 3 skill points to Swim skill", this would
   show "add a level of fighter, gain 8 hit points, take Cleave, assign 3
   skill points to Swim skill, +1 BAB, +1 Fort".

   Actually, I'd like to go a step further and show running totals:
   "add a level of fighter (now Ftr8), gain 8 hit points (57 total), take
   Cleave, assign 3 skill points to Swim skill (6 ranks now), +1 BAB (+8
   total), +1 Fort (+6 total)".

   (All examples above 'translated to English')

   This has two primary purposes.  One is to allow third-party tools to
   reconstruct the character at various points -- show what a character
   looked like at fourth level, when now nineth.  It should also be very
   useful for debugging purposes, especially if it shows running totals.
   It would basically be a (partial) dump of the character after each
   transformation.  (I'd limit it to just showing the bits that actually
   change at each transformation, or it'd be an ugly thing to try to
   examine.)

Section 3

   The third is the reason we're doing all this.  It contains the
   character in final form.  All totals shown, no subtotals, etc. (except
   where they are themselves useful, such as Touch AC).

   This section could be imported into other programs, pushed through a
   transformation to be output, or even imported by PCGen for
   presentation (but *not* for deconstruction, I think... way too hard).


I considered having multiple versions of the character in the third
section (in case you want a copy of the character at each character
level) but for now I wouldn't worry about it.  The first shows how the
character is constructed (sufficent to reconstruct), the second shows
details (for examination -- debugging or third-party reconstruction),
the third shows only the results.

Happily, all three sections will be relatively easy to design.


Keith
--
Keith Davies                 "Always code as if the guy who ends up
keith.davies@...     maintaining your code is a psychopath
keith.davies@...        who knows where you live."
http://www.kjdavies.org/        -- Damian Conway

This would be awesome ... I would especially like to be able to (if I were
GMing) be able to look at the way points were utilized at each level.  It
would also allow the character to be played at any of his levels, which is
great when visiting different games, I would love to be able to do some
journaling in this section as well.

-----Original Message-----
From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com] On Behalf
Of Keith Davies
Sent: Thursday, September 29, 2005 16:02
To: PCGen-XML
Subject: [pcgen-xml] It lives! And is reborn!

Hi All,

I just finished an interesting IM conversation with Devon.  Here's what
he's looking for -- and it's pretty easy, I think.

Continue using LST format for PCC files, for now at least.  We may
revisit it later and convert the LST files to XML.

The character file would consist of three sections.  Each section is
optional, but there are reasons for each.


Section 1

   The first is the primary working data for PCGen.  It logs all
   construction decisions, but no consequences.  For instance, it will
   log that you add a level of fighter, the hit points gained, the feat
   selected, and where the skill points were assigned.

   By using this structure (which is similar to that of CDOM), it becomes
   possible to roll back decisions.  It'll be possible to remove levels,
   for example.

Section 2

   The second expands on the first, showing the 'non-decision' data.
   For instance, where section shows "add a level of fighter, gain 8 hit
   points, take Cleave, assign 3 skill points to Swim skill", this would
   show "add a level of fighter, gain 8 hit points, take Cleave, assign 3
   skill points to Swim skill, +1 BAB, +1 Fort".

   Actually, I'd like to go a step further and show running totals:
   "add a level of fighter (now Ftr8), gain 8 hit points (57 total), take
   Cleave, assign 3 skill points to Swim skill (6 ranks now), +1 BAB (+8
   total), +1 Fort (+6 total)".

   (All examples above 'translated to English')

   This has two primary purposes.  One is to allow third-party tools to
   reconstruct the character at various points -- show what a character
   looked like at fourth level, when now nineth.  It should also be very
   useful for debugging purposes, especially if it shows running totals.
   It would basically be a (partial) dump of the character after each
   transformation.  (I'd limit it to just showing the bits that actually
   change at each transformation, or it'd be an ugly thing to try to
   examine.)

Section 3

   The third is the reason we're doing all this.  It contains the
   character in final form.  All totals shown, no subtotals, etc. (except
   where they are themselves useful, such as Touch AC).

   This section could be imported into other programs, pushed through a
   transformation to be output, or even imported by PCGen for
   presentation (but *not* for deconstruction, I think... way too hard).


I considered having multiple versions of the character in the third
section (in case you want a copy of the character at each character
level) but for now I wouldn't worry about it.  The first shows how the
character is constructed (sufficent to reconstruct), the second shows
details (for examination -- debugging or third-party reconstruction),
the third shows only the results.

Happily, all three sections will be relatively easy to design.


Keith
--
Keith Davies                 "Always code as if the guy who ends up
keith.davies@...     maintaining your code is a psychopath
keith.davies@...        who knows where you live."
http://www.kjdavies.org/        -- Damian Conway




Yahoo! Groups Links

> Section 1
>
> Section 2
>
>   The second expands on the first, showing the 'non-decision' data.
>   For instance, where section shows "add a level of fighter,
>   gain 8 hit points, take Cleave, assign 3 skill points to Swim skill",
>   this would  show "add a level of fighter, gain 8 hit points, take
>   Cleave, assign 3 skill points to Swim skill, +1 BAB, +1 Fort".

Why have two sections containing the same data?  Ease of processing, or some
other reason?  It would seem simpler to either confine section 2 to the
"non-decision" data, in your case +1 BAB, +1 Fort, or to just eliminate
section 1 entirely.  Unless I've missed something obvious, or you've left
something out.

>   Actually, I'd like to go a step further and show running totals:

Which is what section 3 is for, no?

As I say, if I've missed something, let me know.

On Thu, Sep 29, 2005 at 09:42:09PM +0000, gamer_dude@... wrote:
> I know I'm new to PCGen and the e-lists, but I have a reasonable
> background in computers, data, etc. and for what it is worth offer my
> 2 bits.

Please don't quote like that.  It's very hard to read.  I've fixed it
this time.

> > I just finished an interesting IM conversation with Devon.  Here's
> > what he's looking for -- and it's pretty easy, I think.  Continue
> > using LST format for PCC files, for now at least.  We may revisit it
> > later and convert the LST files to XML.  The character file would
> > consist of three sections.  Each section is optional, but there are
> > reasons for each.
>
> I like the idea of eventually going to XML.  Getting rid of all the
> tabs in favor of tags would make things easier  to 'read'.

That was part of my original impetus -- making all syntactical elements
visible.  Another was properly representing the hierarchical data.

> > Section 1 The first is the primary working data for PCGen.  It logs
> > all construction decisions, but no consequences.  For instance, it
> > will  log that you add a level of fighter, the hit points gained,
> > the feat  selected, and where the skill points were assigned.  ...
> >
> > Section 2 The second expands on the first, showing the
> > 'non-decision' data...  Actually, I'd like to go a step further and
> > show running totals:  "add a level of fighter (now Ftr8), gain 8 hit
> > points (57 total), take Cleave, assign 3 skill points to Swim skill
> > (6 ranks now), +1 BAB (+8 total), +1 Fort (+6 total)".
> >
> >  (All examples above 'translated to English')
> >
> > This has two primary purposes.  One is to allow third-party tools to
> > reconstruct the character at various points -- show what a character
> > looked like at fourth level, when now nineth.  It should also be
> > very  useful for debugging purposes, especially if it shows running
> > totals.  It would basically be a (partial) dump of the character
> > after each transformation.  (I'd limit it to just showing the bits
> > that actually  change at each transformation, or it'd be an ugly
> > thing to try to  examine.)

> Great Idea!  Being able to roll a character back WITHOUT having to
> save it at each level is a concept overdue.  Imagine a program like
> PCGen offering the option to view (and print) a character at each
> stage of it's life.  Wow talk about almost no headaches when the big
> warrior gets drained of two levels in the middle of the session.
>
> My only concern in reading the suggestion is "why have TWO sections
> with basically identical data?"  I think the proposed section 2 could
> easily handle the purposes of what sections 1 and 2 are for, without
> the near complete duplication of the same information.

These two sections have different purpose and application, despite being
somewhat similar.

The first is intended to tell PCGen how the character is constructed.
It depends on the rest of the data (class definitions, etc.) being
available.  It is expected to have minimal redundancy.  It will be
highly resilient in the face of changes to these definitions.

The second would be *very* redundant, but also very incomplete.  That
is, if you have eight levels of fighter, it describes the effects of
those levels of fighter on your character... with no indicatation that
the fighter class even has a ninth level.  It could be transformed to
create the third section, if necessary, but contains way more than is
needed by PCGen.

Also, and very important to me, it runs the risk of introducing
inconsistency.  If the definition of an entity changes, the information
in the second section could be rendered incorrect.

I don't mind being *wrong*, but I had being inconsistent.

Now, this potential inconsistency isn't a problem the way I propose to
use it.  In fact, it's quite useful because it makes it very easy to see
what changes are being made and when, which can uncover problems with
the data or software.  I.e. *here*, inconsistency serves a useful
purpose.

Granted, we could simply ignore the inconsistencies, just picking up
what we need when loading it for editing by PCGen.

It's probably a matter of preference.  The first section as I've
described it is *necessary*.  The second section isn't, but is useful.
I don't like mixing optional data and required data in the same
containers, especially when it isn't evident through examination which
is which.

Also, frankly, the first section as described is pretty easy to
implement.  The second will be harder and probably more error-prone.
There's a certain amount of overlap between them and probably code
reuse, but we can prove the first section fairly easily.  The second
will be more work.

IOW, I want a nice, simple, easily implemented and proven section, and a
rather-useful-but-not-*required* section... especially if that second
section will be harder to implement and prove.

> > Section 3
> >
> > The third is the reason we're doing all this.  It contains the
> > character in final form.  All totals shown, no subtotals, etc.
> > (except where they are themselves useful, such as Touch AC).
> >
> > This section could be imported into other programs, pushed through a
> > transformation to be output, or even imported by PCGen for
> > presentation (but *not* for deconstruction, I think... way too
> > hard).
>
> First thought that comes to mind is... Wouldn't it be simpler to just
> have a field noting the current level of the character.  When a
> character has to be 'rolled-back' a nubmer of levels, none of the
> leveling information would be deleted, and instead of storing a
> duplicate of the information contained in the "current character
> level", the file just stores a simple field indicating the current
> character level.  No destruction of data and allows the GM/Player to
> store the character at their current level while using a minimum of
> space for all the information.

Not really.

See, the first section knows nothing about running totals.  It's useless
without the rest of the data.

The second section *does* know about running totals, but *doesn't*
include a snapshot of the entire character with each transformation.  It
would be huge, which makes it harder to use for a couple of reasons.

1. storage requirements.  Who cares?  It seems highly unlike that it'd
    get big enough to matter.

2. examination difficulty.  This is a much more important one, IMO.  If
    you show the entire state, that means the whole thing needs to be
    examined if you're trying to figure out what happened.  If you only
    highlight what changed (including the new (and possibly old) values)
    then it's very easy to see the effects of the change.

I see no reason why you couldn't generate the third section "as at" a
particular transformation (right after 4th level, say), despite having
10 levels of information present.  In fact, you could generate *just*
the third section, without including either of the others.


Keith
--
Keith Davies                 "Always code as if the guy who ends up
keith.davies@...     maintaining your code is a psychopath
keith.davies@...        who knows where you live."
http://www.kjdavies.org/        -- Damian Conway

On Thu, Sep 29, 2005 at 06:21:00PM -0400, Brass Tilde wrote:
> > Section 1
> >
> > Section 2
> >
> >   The second expands on the first, showing the 'non-decision' data.
> >   For instance, where section shows "add a level of fighter,
> >   gain 8 hit points, take Cleave, assign 3 skill points to Swim skill",
> >   this would  show "add a level of fighter, gain 8 hit points, take
> >   Cleave, assign 3 skill points to Swim skill, +1 BAB, +1 Fort".
>
> Why have two sections containing the same data?  Ease of processing,
> or some other reason?

Ease of processing and implementation, to start.

. Section 1 is relatively easy to implement and prove.  It has minimal
   redundancy (but depends on the rest of the data being present).  It
   has only what is needed to construct the character.  It's also highly
   resilient in the face of data changes -- a change to the rest of the
   data won't introduce inconsistency because there's nothing to be
   inconsistent with.

. Section 2 contains potentially huge redundancy, even apart from it
   being a superset of Section 1.  It shows the effects of the decisions
   made and stored in Section 1.  It's primarily of interest to PCGen
   developers (LST and code) since it makes it easier to see exactly what
   happened -- what the program and data decided to do, rather than what
   the monkeys *thought* would happen.

> It would seem simpler to either confine section 2 to the
> "non-decision" data, in your case +1 BAB, +1 Fort, or to just
> eliminate section 1 entirely.

Ease of processing again.  In part, showing the decision information is
necessary because it makes it possible for a human to map between the
decisions and their effects, and putting them all in one place makes
them easier to see.

See, the decisions are nested:

   add level {
     // may add ability score bump
     // may add feat (before or after class level)
     add level of class {
       add hit points
       add skill points
       may add feat
       may add spells known
       // etc.
     }
     // may add feat (before or after class level)
   }

As such, it's necessary to hold the 'parent decisions' for the internal
ones to be at all meaningful.

Also, I'd like to store "old value, change, new value" in here.  This
lets an examiner see "what it was, what happened, what it is now", very
useful for debugging.  The structure also demonstrates where the change
came from, making it clear what happened.  Consider:

   change {
     Str += 1
     BAB = 8
     BFort = 6
     Feats += Improved Critical(greatsword)
     Feats += Greater Weapon Focus(greatsword)
     Skills: Swim += 3
   }

vs.

   add level (8) {
     Str += 1
     add level of fighter (8) {
       hit points: 57 + 8 == 65
       BFort: 5 + 1 = 6
       Feats += Greater Weapon Focus(greatsword)
       Skills: Swim += 3
     }
     Feats += Improved Critical(greatsword)
   }

(syntax obviously not XML, but shows structure)

Which would you rather see, from a debugger's point of view?

The second is much clearer what happened... but contains information
that isn't needed by PCGen.

> Unless I've missed something obvious, or you've left something out.

I don't think it was anything obvious, but I did have reasons.
>
> >   Actually, I'd like to go a step further and show running totals:
>
> Which is what section 3 is for, no?

No.  Well, not really.  Section three shows the final results.  Section
two shows only the running totals of what has changed -- showing *all*
running totals and the like would get unwieldy when trying to examine
it.


Keith
--
Keith Davies                 "Always code as if the guy who ends up
keith.davies@...     maintaining your code is a psychopath
keith.davies@...        who knows where you live."
http://www.kjdavies.org/        -- Damian Conway

I agree, this seemed lost on me as well.
	 I would love to be able to put PCGen into a mode where I can see the
character progress.  This is something difficult to do in P&P RPGs.  While
you could easily create a new character sheet for each level, you would miss
out on "granted +1 spell success by wild magic misfire at level 1.43".
Although this level of logging would make pcg files BIG (say at level 10
from a first level character), it would be very cool to be able to turn this
on and see the characters improvements and losses over the long term.

-----Original Message-----
From: pcgen-xml@yahoogroups.com [mailto:pcgen-xml@yahoogroups.com] On Behalf
Of Brass Tilde
Sent: Thursday, September 29, 2005 18:21
To: pcgen-xml@yahoogroups.com
Subject: RE: [pcgen-xml] It lives! And is reborn!

> Section 1
>
> Section 2
>
>   The second expands on the first, showing the 'non-decision' data.
>   For instance, where section shows "add a level of fighter,
>   gain 8 hit points, take Cleave, assign 3 skill points to Swim skill",
>   this would  show "add a level of fighter, gain 8 hit points, take
>   Cleave, assign 3 skill points to Swim skill, +1 BAB, +1 Fort".

Why have two sections containing the same data?  Ease of processing, or some
other reason?  It would seem simpler to either confine section 2 to the
"non-decision" data, in your case +1 BAB, +1 Fort, or to just eliminate
section 1 entirely.  Unless I've missed something obvious, or you've left
something out.

>   Actually, I'd like to go a step further and show running totals:

Which is what section 3 is for, no?

As I say, if I've missed something, let me know.

On 9/29/05, Keith Davies <keith.davies@...> wrote:
> These two sections have different purpose and application, despite being
> somewhat similar.

I'm surprised technically-literate people are having a hard time with
this.  I don't even think the sections are all that similar, though
I'd expect the structure of the second would largely mirror and extend
the structure of the first.

> Also, and very important to me, it runs the risk of introducing
> inconsistency.  If the definition of an entity changes, the information
> in the second section could be rendered incorrect.

I actually disagree on this point, however.  As the sections have been
described so far, I think of them this way:

   1.  User decisions.

   2.  Software decisions.

   3.  Fluffy stuff.

The third section can clearly be regenerated, but supplemental tools
that only care about the "current" value of the information only need
to look there.  This is nice to have, but could be dropped.

That leaves the first two, where all the contention seems to be.
Section 1 is obviously necessary, and seems well defined.  Section 2
*appears* derivative of section 1 + game rule information (race &
class definitions, etc.), and usually will be.  Where you're looking
at inconsistency, I see an opportunity to check that the character is
being viewed relative to the right "universe" (the game rule
information set); it also allows you to separate changes in game rules
from the characters created under different versions.

For example, suppose I create a character and play her until level 5.
The GM decides he doesn't like some rule, so forks the universe by
reducing the number of spells my character would have received at
level 3.  Whether my character loses a spell or not, since she's
already in play, depends on the GM's policy for handling that.  As
described, section 2 allows that decision to be handled either way.
The application that checks for this sort of inconsistency should
allow the policy to be applied on a case-by-case basis by inserting
"inconsistency approvals" into the second section for each
inconsistency.  This would allow a character from a legacy universe to
continue to be used in the new universe in the same way that happens
in real games.

> I don't mind being *wrong*, but I had being inconsistent.

Absolutely understandable!

> It's probably a matter of preference.  The first section as I've
> described it is *necessary*.  The second section isn't, but is useful.
> I don't like mixing optional data and required data in the same
> containers, especially when it isn't evident through examination which
> is which.

Understandable, but I think the information is necessary.

> Also, frankly, the first section as described is pretty easy to
> implement.  The second will be harder and probably more error-prone.
> There's a certain amount of overlap between them and probably code
> reuse, but we can prove the first section fairly easily.  The second
> will be more work.

Most definately.  They also serve clearly different purposes.

> 2. examination difficulty.  This is a much more important one, IMO.  If
>    you show the entire state, that means the whole thing needs to be
>    examined if you're trying to figure out what happened.  If you only
>    highlight what changed (including the new (and possibly old) values)
>    then it's very easy to see the effects of the change.

This is very valuable.  Anything that makes development easier is a good thing.


   -Fred

--
Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation