Re: [pcgen-xml] .MOD, .FORGET and .COPY
- On Fri, Nov 14, 2003 at 07:53:24AM -0700, Rich Allen wrote:
> Hope you don't mind me butting in; I've been following this conversation with interest since I can't hardly wait until PCGen switched to an XML format...This is fairly close to how I did it originally. There are reasons to
> On Fri, 14 Nov 2003 08:36:25 -0000 (GMT), Frugal wrote:
> > Publisher A has a feat 'foo'
> > Publisher B has a feat 'foo'
> > Publisher C expands on the feat 'foo' from publisher A.
> > when we convert do we have :
> > A_feats.xml
> > <feat id="feat.foo" />
> > B_feats.xml
> > <feat id="feat.foo" />
> > C_feats.xml
> > <feat trans="modify" id="feat.foo" />
> In my opinion, the following is how it should look (obviously, the format of the id attribute isn't as important as the use of the attribute itself):
> <feat name="foo" id="A.book.feats.foo" />
> <feat name="foo" id="B.book.feats.foo" />
> <feat name="foo" id="C.book.feats.foo" trans="modify"
> transid="A.book.feats.foo" />
not do it this way, though.
1. Make name a child element. It is important enough, and complex
enough, to warrant it. Specifically, there are other pieces of
information that are part of it beyond just the text of the name,
specifically the 'ispi' flag (and any other related flags) and an
optional abbreviation. These could be made other attributes (like
'nameispi'), but making them attributes of <name> will be more
consistent with other fields. We can reduce the symbol count
somewhat by using a smaller, consistently-applied set of attributes
2. There are times that the same thing -- exactly the same thing -- is
defined in more than one source. For instance, there are feats in
Sword and Fist that are also published in a later splat book.
Including multiple IDs for exactly the same thing will cause problems
3. Use namespaces to separate conceptually different things. Game
information may be split on game mode or rule set, but transaction
and source behaviour is expected to be consistent between them.
Putting these things in their own namespaces makes them easier to
manage and implement.
Keith Davies "Your ability to bang your head against
keith.davies@... reality in the hope that reality will
crack first is impressive, but futile"
-- Geoffrey Brent, rec.games.frp.dnd
- On Nov 14, 2003, at 3:47 PM, Brass Tilde wrote:
>> On Friday 14 November 2003 20:03, Brass Tilde wrote:Yep. Serious ones. Go take a look at how we manage things in pcgen
>> We currently have >6Mb of data files... 30,000 lines so
>> probably 25,000 items
> And you had performace problems with that tiny little thing? One of
> tables in our main database, constantly transacted against, currently
> over 4 million rows. Several others have in excess of a million. That
> doesn't count the ancillary databases used for non-Core operations. No
> primary keys *really* sucks in that environment.
currently. There are no primary keys, and we analyze strings like
"Foo|BAR|fizBot|PREQ:STR>3:Green" with a string tokenizer on "|" and
then several more on ":" to see whether we should show something in
green or bold, then eval the prequisite (stored in string form) to see
if the character meets it, and thus should be show in red.
Last time I checked, showing the feat screen with just the Big 3 and
Monte's ranger requires running something like 85,000 strings through a
bonus checker. I believe that some optimization work has been done
since then, but we have not set up real dependencies between objects,
partially because of a lack of keys, and thus we end up re-doing a lot
of work on tab display.
This technique was not a bad one when we had just a few items, with
relatively simple formulas, but we now have zillions of them. Having
unique ids and objects would make it really, really easy to find
objects by key, so we could then parse the formulas only once and
evaluate them as needed without lots of code knowing the difference.
If all we do is provide a unique id that can be used in maps/sets for
object lookup, and get all the refs hooked up right. we will have done
a good thing. If we also parse the formulas once, we will cause
probably three or four orders of magnitude improvement in
display/calculation speed. As a bonus, we could determine those things
to be drawn in a given font/color and paint those, which can result in
three orders of magnitude improvement in draw time on MacOS X.
(Changing fonts/colors is pricey, as it goes through a compositor.)