Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Scott Ellsworth
    ... [...] ... Let me second that. The lack of a single, global, unique ID is a primary reason why the current data model parses and reparses strings. We
    Message 1 of 49 , Nov 13, 2003
    • 0 Attachment
      On Nov 13, 2003, at 12:45 PM, STILES, BRAD wrote:

      > > How do we get around Frugal's case of multiple data with the
      > > same name?
      [...]

      > 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.

      Let me second that. The lack of a single, global, unique ID is a
      primary reason why the current data model parses and reparses strings.

      We really, really should have a system where everything in the program
      has a unique or unique-for-type field, as that makes it trivial to know
      what is loaded, who modified it, and when it has gotten out of date.
      It also makes it easy to track dependencies - my STR is modified by a
      bonus from my SRD belt of giant strength, my Mighty Strength feat from
      Thugs and Villians, and a few other things. A change to one of those
      definitions means that I can fix up what needs to be fixed.

      Perhaps more important - it makes it possible to know whether or not a
      character uses anything from a loaded source, so that what is exported
      is only what is needed. Also, if a source changes, perhaps due to
      copyright, SRD, or screwup, I can tell immediately on load what got
      altered. I can even write code on load to make SURE that everything
      makes sense.

      > If that means that all .MODs, etc, need to be keyed on the ID rather
      > than the name, then do be it.

      This is correct, IMO. If I have made Wizards use the Sorcerer table
      for spells, I do not really want it to grab the "Zap and Blast" version
      of the Sorcerer - I want it explicit that it is the SRD.

      This does mean we might have duplicates if you load three splat books
      with the same feat, but that can be handled, I suspect, and should be.

      Scott
    • 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.