Re: [pcgen-xml] .MOD, .FORGET and .COPY

... I ve come to the conclusion that the XML files -- LST files themselves as well, actually -- are not *truly* data files. They contain data, but the data

Message 1 of 49
, Nov 13, 2003

0 Attachment

On Thu, Nov 13, 2003 at 03:13:30PM +0000, Frugal wrote:

>
> How are you propossing to handle the .MOD, .FORGET and .COPY tags?

I've come to the conclusion that the XML files -- LST files themselves
as well, actually -- are not *truly* data files. They contain data, but
the data actually describes a series of transactions to be performed in
the internal data model. The *default* action is 'add this item', but
others -- such as 'copy and call it this', or 'modify this', or 'delete
this' -- are possible.

This got me over a huge problem I had with ID conflicts.

> I can see a couple of ways to handle them, but I am not sure which way
> you want to do it with ergard to Entity IDs...
>
> <skill id="skill.bluff">
> <name>Bluff</name>
> </skill>
>
> Then is the MODed item either:
>
> <skill id="skill.bluff">
> <name>Bluffish</name>
> </skill>
>
> or
>
> <skill id="skill.bluff.mod">
> <name>Bluffish</name>
> </skill>
>
> Basically, how unique to IDs have to be...

An ID is expected to always refer to the same thing. What I would do
for the above is:

I actually like the second form better, except that it is not consistent
with the common form. Which might not be a *bad* thing, actually, if
the common form actually is the most frequently found.

The trans namespace is obviously for 'transaction'. Ignore the delete
transactions in my example below, they're shown here only for
completeness.

> This is also going to be an issue when auto converting the data. There
> are currently 6 different occurances of "Speak Language" in the LST
> files currently shipped with PCGen and 5 named "Demolitions".
>
> Do we prefix the skill ID with the short datasource tag
> (srd.skill.speak.language). If so how do we know which of them will be
> referred to by the MOD.

I'd *really* rather not. It'd get way too ugly. What I'd like to see
is, when the data is loaded, the transactions logged to the items. It'd
probably help no end when trying to debug the data, too. The interface
doesn't do it now, but an examination mode might show something like:

Bluff
inserted phb.skills.xml
modified something.else.xml {name}

Jim's Bluff
copied jim.campaign.xml [skill.bluff] {name}

The presentation of source information above doesn't much matter. Even
if it were only a list of what files touched the item (not what the
files changed) it'd probably be a big help.

> Do we have more than one skill with the same tag. If so, do we load
> just the first? Load them in sequence and overwrite the existing data?
> Load the first and then throw and exception on the second and
> subsequent ones ?

What I'd like to see is, when finding a second game object with the same
ID as an earlier one, is for both items to be presented to the user and
the user select one for use. The decision could be logged to the PCC
file being created and life goes on. The *next* time this file is
loaded, the collision will already have a resolution.

This assumes, of course, that loading a series of sources creates an
implicit PCC.

Keith
--
Keith Davies "Your ability to bang your head againstkeith.davies@... reality in the hope that reality will
crack first is impressive, but futile"
-- Geoffrey Brent, rec.games.frp.dnd

Scott Ellsworth

... Yep. Serious ones. Go take a look at how we manage things in pcgen currently. There are no primary keys, and we analyze strings like

Message 49 of 49
, Nov 23, 2003

0 Attachment

On Nov 14, 2003, at 3:47 PM, Brass Tilde wrote:

>> On Friday 14 November 2003 20:03, Brass Tilde wrote:
>
>> 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
> the
> tables in our main database, constantly transacted against, currently
> has
> 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.

Yep. Serious ones. Go take a look at how we manage things in pcgen
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.)

Scott

Your message has been successfully submitted and would be delivered to recipients shortly.