Re: [pcgen-xml] .MOD, .FORGET and .COPY
- On Fri, Nov 14, 2003 at 03:03:32PM -0500, Brass Tilde wrote:
>It'd be nice if they weren't or couldn't be considered the same thing.
> > > > However, it may also be misleading - if srd.skill.bluff is
> > > > really srd.skill.bluff as modified by source XYZ and modified
> > > > again by source ABC, is "srd" really the best descriptor for it?
> > >
> > > Yes, because the SRD version of it is what is being modified.
> > *probably*. It's arguable that the 'SRD Bluff' and the 'PHB Bluff'
> > are in fact the same thing.
> True. In fact, it's quite likely to be so, especially given the
> situation created by the SRD and CMP files. Loads of people are
> trying to load them both at the same time, whether through ignorance
> or some other reason I've been unable to fathom, causing all manner of
> problem. With unique ID's between them, they can both be loaded at
> the same time, and with a UI to create the MODs, etc, unambiguously,
> things become much simpler. I'll freely admit to liking the ability
> to modify whichever version of an item is loaded, I just don't think
> it's worth it. <shrug/>
I don't mind having, say, 'longknife' defined in multiple sources from
different publishers; they may or may not have the same game
representation, but that's not relevent. They are different objects,
even if they look exactly the same.
Bluff, OTOH, is the same skill whether it comes from SRD or from PHB.
As such, I'd argue that the elements should have the same ID; they do in
fact describe exactly the same thing. Not two things that look the
same, exactly the same thing.
It's a semi-obscure point, but an important one. I don't think we
should have different IDs based on source; I did at one point
(originally I think it would've been 'skill.wotc.phb.bluff' rather than
'skill.bluff'), but I think that led to a bunch of really big IDs with
relatively little increased utility.
Now, if we choose to treat things from different sources as being
different objects, even if they are exactly the same thing so far as we
can see, things become simple. We can't easily substitute one for the
other, though -- an object that requires SRD Ranger won't work with PHB
Ranger. This seems rather lame. It makes for a simpler model, but it's
still pretty lame. Especially if you try to use things from more than
one source. For instance, a character wishes to take two prestige
classes, each with a Bluff requirement -- one is from CMP and uses PHB
Bluff, the other is from PCGen and uses SRD Bluff... the odds of the
character meeting both prereqs is pretty slim, and the reason for
failure won't be obvious. If the prereq is on 'skill.bluff', though,
things are easy.
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.)