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

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

Expand Messages
  • CC Noram Carstensen James
    ... id= skill.jims_bluff ... Don t these examples mean that there is an required order in the processing of the LST files? For example, if I have source A,
    Message 1 of 49 , Nov 13, 2003
    • 0 Attachment
      Keith wrote:
      > An ID is expected to always refer to the same thing. What I would
      > do for the above is:
      >
      > <skill id='skill.bluff'><!-- implicit 'trans:action="insert"' -->
      > <name>Bluff</name>
      > </skill>
      >
      > <!-- more stuff -->
      >
      > Then one of
      >
      > <skill trans:action="modify" refid="skill.bluff">
      > <name>Bluffish</name>
      > </skill>
      >
      > <skill trans:action="copy" refid="skill.bluff"
      id="skill.jims_bluff">
      > <name>Jims Bluff</name>
      > </skill>
      >
      > <skill trans:action="delete" refid="skill.bluff" />

      Don't these examples mean that there is an required order in the
      processing of the LST files?

      For example, if I have source A, which loads first, which creates
      skill.bluff, and source B, which mods skill.bluff, but then add a source
      C which loads between them and copy to a skill.jims_bluff and deletes
      the final, now we have an error in B because skill.bluff doesn't exist,
      but the problem isn't really in B, it's in the load order that has
      source C going between.

      I know we have the current rank system for loading to take care of
      things like this, but with only 9 levels of ranking many sources will
      have the same priority and will have their load order determined by
      other aspects.

      Frankly, I see mod and copy used for a few specific category of tasks.

      1. Error corrections / errata. (But more likely corrected in the base
      file.)
      2. Modifications to the base rules (core books / [R]SRD) for specific
      worlds/campaigns/publishers.
      3. Expansions by a publisher / house rules.

      >> This is also going to be an issue when auto converting the data.
      There
      >> are currently 6 different occurances of "Speak Language" in the LST
      >> files currently shipped with PCGen and 5 named "Demolitions".
      >>
      >> 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.
      >
      > I'd *really* rather not. It'd get way too ugly. What I'd like to see
      > is, when the data is loaded, the transactions logged to the items.
      It'd
      > probably help no end when trying to debug the data, too. The
      interface
      > doesn't do it now, but an examination mode might show something like:

      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.

      > The decision could be logged to the PCC
      > file being created and life goes on. The *next* time this file is
      > loaded, the collision will already have a resolution.

      This can lead to troubleshooting issues (not having the same "picks" for
      contradictory info), may need to be migrated with characters to new
      versions, etc. And how does this work out with multiple campaigns that
      have different choices the same sources?

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

      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. Which means we need some way of working this out at run time
      (or at least at LST read time, which is currently the same), which can
      make sense when source XYZ has transactions on an object with the same
      name as an object in source ABC, while still keeping both of them.

      Thoughts,
      Jim
    • 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.