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

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

Expand Messages
  • Keith Davies
    ... It d be nice if they weren t or couldn t be considered the same thing. I don t mind having, say, longknife defined in multiple sources from different
    Message 1 of 49 , Nov 17, 2003
      On Fri, Nov 14, 2003 at 03:03:32PM -0500, Brass Tilde wrote:
      > > > > 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/>

      It'd be nice if they weren't or couldn't be considered the same thing.
      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
    • 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
        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.)

      Your message has been successfully submitted and would be delivered to recipients shortly.