RE: [pcgen-xml] .MOD, .FORGET and .COPY
- On Fri, 14 Nov 2003 18:57:12 -0500, Brass Tilde wrote:
>>�>�Personally, I don't see the need for mod, forget and copy.No, I just copy/paste the entire thing into my the lst file and make my changes. This works just fine for me; no reason to code it in by hand. Besides, I thought the talk was geared toward an application for creating the data files, not toward someone entering the data by hand. The application can easily copy the original object, accept whatever modifications the user wants, and save it in its entirety to the new lst file.
>�Wow. �That's a pretty limited view. �Do you not see the advantages of
>�copying something and changing *one* item, as opposed to creating an
>�entirely new item and hoping you get everything to match? �Or being able to
>�*change* one thing about a class without coding the whole thing yourself?
I think another, potentially large, problem exists with this scheme; what happens when an object is a modification of another object that is in a non-existent lst file? The windows specific installer for PCGen allows you to select which data files to install, if I recall. I should be able to have just the lst files for the PHB, and Book foo and create a character valid for those sources, even if Book foo has a version of an object in Book bar.
I'm just offering an alternative way of thinking about these things. I'm sure the team will do whatever it thinks is best. I do think the argument of "Why not, PCGen does it now." is the wrong way to look at it. I think converting to XML is the perfect opportunity to redo things in PCGen that don't work, or are hard to make work, currently.
- 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.)