Re: [pcgen-xml] .MOD, .FORGET and .COPY
- On Fri, Nov 14, 2003 at 10:32:19PM +0000, Frugal wrote:
> On Friday 14 November 2003 20:03, Brass Tilde wrote:Different IDs, yes, but not necessarily different names. We'll have
> > It is. The PHB Ranger and the Monte Ranger are not the same thing. I can
> > see where some might want to apply their .MODs to "whichever Ranger is
> > loaded", but I think that sort of thing causes more problems than it
> > solves. The UI can be designed in such a way that the user doesn't need to
> > worry about the ID, but he must pay attention to which item he wants to
> > modify.
> If they are ment to be different and can both be used at the same
> time, then they should have different IDs and preferably different
information necessary to differentiate them at run time (the source:*
information, or at worst the file name), so let's do it then. That way
we don't need to clutter the names when there is no collision. I'll
agree that it may be confusing, but I suspect that most DM's, when
presented with a case like this, will either MOD one of the names or
drop one of the descriptions entirely.
> <class id="class.ranger_monte">Which is why I've been wanting to put IDs on the data segments and on
> <name>Ranger (Monte)</name>
> <!-- Monte's stuff goes here -->
> If the Monte Ranger is to override the SRD Ranger then when you load
> the Monte Ranger, delete the SRD one.
> <class trans:action="delete" refid="class.ranger" />
> <class id="class.ranger">
> <!-- Monte's stuff goes here -->
> > 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.
> The SRD is an unusual problem. Most people do not have a clue what the
> SRD is. There is no mention of it in the books, there is no mention
> of it on the wizards web site unless you know what search string to
> enter. So most people do not know that the SRD is the core rule books,
> so they add both.
> This is not such an issue with SRD plus free PHB/DMG/MM as they use
> the same LST files and the loader will not load the same physical LST
> file twice. However with the SRD plus the CMP PHB/DMG/MM we have
> different physical LST files, so they can both be loaded at the same
the files themselves -- rather than tracking by URI, track it be
'equivalent ID'. As it stands, you could even (so far as I know) load
two versions of the same file (pull the PHB from 5.4.0 and the PHB from
5.4.1) and it won't complain... until weird things start to happen.
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.)