RE: [pcgen-xml] .MOD, .FORGET and .COPY
RE: [pcgen-xml] .MOD, .FORGET and .COPY
> Don't these examples mean that there is an required order in the
> processing of the LST files?
Not necessarily. .MOD, .FORGET, .COPY, etc items can be deferred until after all primary items have been loaded.
> >> 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.
> How do we get around Frugal's case of multiple data with the
> same name?
> I know there are numerous sources that have feats, spells, etc with
> common names. And they aren't mods of each other - they may all work
> perfectly with just the core rules, but don't have common names with
> other third party publishers.
> > 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.
> In many cases, if the DM is intentionally loading multiple sources, the
> "right" functionality may be for all of them to be available. The feat
> "Arcane Master" from source XYZ may be significantly different then the
> feat "Arcane Master" from source ABC.
Names may be identical, ID's should not. Just because the name of both is "Arcane Master" doesn't mean that the ID will be. If that means that all .MODs, etc, need to be keyed on the ID rather than the name, then do be it. In practice that likely means that some method of determining the key will have to be in the UI, along with possibly a method for entering the .MODs themselves.
I like Keith's "resolve once and move on" strategy.
> If we can trust a publisher to be /internally/ consistent (which may
> be a stretch), then a publisher part of the ID may be useful.
Not really a publisher issue. It's an issue with the person who's creating the XList files. I wouldn't expect publishers to conveniently put globally unique identifiers in their products, though that would be kinda nice. <g/>
> 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.
> Trying to fit Keith's idea of keeping it simple, but also allowing
> multiple of the same feat. I think we can rule out assuming that the
> creator of a LST file will always have a unique name - people
> can create their own.
I don't think it's too much of a stretch to *require* uniqueness in at least one field. It may be necessary not to enforce it unless there is a conflict, by, for instance, using the name of the item as the ID when an explicit ID isn't present, but once you get into duplicating items, it's "Hey, make the IDs unique and you won't have a problem."
- 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.)