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

Re: [pcgen-xml] Re: Okay - getting down to business

Expand Messages
  • Scott Ellsworth
    ... The former. Said key does not have to be english text, but I suspect it should be. It lives in the same space as a database table s primary key - a way
    Message 1 of 24 , Oct 3, 2002
    View Source
    • 0 Attachment
      On Thursday, October 3, 2002, at 11:12 AM, STILES, BRAD wrote:

      >> By having our new data model have a distinct, case sensitive key, but
      >> one that a user never sees, we have fast code, and a good user
      >> experience. In other words, there is only one entry for the stock
      >> fighter class - wotc.dnd.class.fighter or some such.
      >
      > Are you talking about a permanently defined key, that is part of the
      > data on disk, or one that is derived from the data at runtime? I
      > gather the former, but just want to make sure.

      The former. Said key does not have to be english text, but I suspect
      it should be. It lives in the same space as a database table's primary
      key - a way to insure that when something refers to a table entry, it
      gets exactly the entry it expected.

      Again, it does not really show up in user space - it is a data space
      thing that file editors or other storage systems see.

      Scott
    • STILES, BRAD
      ... Don t you run the risk of the key changing then, if the data upon which it s based changes? That means that some other piece of data that refers to it,
      Message 2 of 24 , Oct 3, 2002
      View Source
      • 0 Attachment
        > >
        > > Are you talking about a permanently defined key, that is
        > > part of the data on disk, or one that is derived from the
        > > data at runtime?
        >
        > In the file. Derived at runtime is basically how it works now.

        Don't you run the risk of the key changing then, if the data upon which it's
        based changes? That means that some other piece of data that refers to it,
        such as a character, won't be able to find it.

        Brad
      • Keith Davies
        ... In the file. Derived at runtime is basically how it works now. Keith -- Keith Davies keith.davies@kjdavies.org PCGen: , smartass You just can t
        Message 3 of 24 , Oct 3, 2002
        View Source
        • 0 Attachment
          On Thu, Oct 03, 2002 at 02:12:43PM -0400, STILES, BRAD wrote:
          > >
          > > By having our new data model have a distinct, case sensitive key, but
          > > one that a user never sees, we have fast code, and a good user
          > > experience. In other words, there is only one entry for the stock
          > > fighter class - wotc.dnd.class.fighter or some such.
          >
          > Are you talking about a permanently defined key, that is part of the data on
          > disk, or one that is derived from the data at runtime? I gather the former,
          > but just want to make sure.

          In the file. Derived at runtime is basically how it works now.


          Keith
          --
          Keith Davies
          keith.davies@...

          PCGen: <reaper/>, smartass
          "You just can't argue with a moron. It's like handling Nuclear
          waste. It's not good, it's not evil, but for Christ's sake, don't
          get any on you!!" -- Chuck, PCGen mailing list
        • Keith Davies
          ... The main IDs -- those of game-level objects -- would be more or less human text. Such as class.fighter and spell.fireball . There would be others,
          Message 4 of 24 , Oct 3, 2002
          View Source
          • 0 Attachment
            On Thu, Oct 03, 2002 at 11:30:03AM -0700, Scott Ellsworth wrote:
            >
            > On Thursday, October 3, 2002, at 11:12 AM, STILES, BRAD wrote:
            >
            > >> By having our new data model have a distinct, case sensitive key, but
            > >> one that a user never sees, we have fast code, and a good user
            > >> experience. In other words, there is only one entry for the stock
            > >> fighter class - wotc.dnd.class.fighter or some such.
            > >
            > > Are you talking about a permanently defined key, that is part of the
            > > data on disk, or one that is derived from the data at runtime? I
            > > gather the former, but just want to make sure.
            >
            > The former. Said key does not have to be english text, but I suspect
            > it should be. It lives in the same space as a database table's primary
            > key - a way to insure that when something refers to a table entry, it
            > gets exactly the entry it expected.

            The main IDs -- those of game-level objects -- would be more or less
            human text. Such as 'class.fighter' and 'spell.fireball'. There would
            be others, though, that wouldn't (such as a character's possession list
            -- ID's may be used to ensure that multiple equipment sets refer to the
            same things). OTOH, that could be done by just checking the totals
            against the possessions. I own four potions of healing; as long as no
            equipment set contains more than four, I'm fine. That might end up
            simpler, and greatly reduce the indexes.

            > Again, it does not really show up in user space - it is a data space
            > thing that file editors or other storage systems see.

            They'd be available for view during data entry -- when I add a weapon,
            the software might guess at the ID but a human should be the one to
            decide (or at least confirm it. After that, though, normal users should
            never need to see it.


            Keith
            --
            Keith Davies
            keith.davies@...

            PCGen: <reaper/>, smartass
            "You just can't argue with a moron. It's like handling Nuclear
            waste. It's not good, it's not evil, but for Christ's sake, don't
            get any on you!!" -- Chuck, PCGen mailing list
          • Keith Davies
            ... The IDs, once assigned, should never change. weapon.dagger always refers to the same thing. Given that we re talking about having a formal check-in for
            Message 5 of 24 , Oct 3, 2002
            View Source
            • 0 Attachment
              On Thu, Oct 03, 2002 at 02:32:18PM -0400, STILES, BRAD wrote:
              > > >
              > > > Are you talking about a permanently defined key, that is
              > > > part of the data on disk, or one that is derived from the
              > > > data at runtime?
              > >
              > > In the file. Derived at runtime is basically how it works now.
              >
              > Don't you run the risk of the key changing then, if the data upon which it's
              > based changes? That means that some other piece of data that refers to it,
              > such as a character, won't be able to find it.

              The IDs, once assigned, should never change. 'weapon.dagger' always
              refers to the same thing. Given that we're talking about having a
              formal check-in for data files, they should be changing (by us) anyway
              -- if a campaign needs a minor change to something, it should load the
              original and MOD it.

              IDs should never change.


              Keith
              --
              Keith Davies
              keith.davies@...

              PCGen: <reaper/>, smartass
              "You just can't argue with a moron. It's like handling Nuclear
              waste. It's not good, it's not evil, but for Christ's sake, don't
              get any on you!!" -- Chuck, PCGen mailing list
            • Keith Davies
              ... simple workaround - smash case on load. Everything gets keyed by upper or lower case value, but displays the label in original case. Thus, when loading
              Message 6 of 24 , Oct 8, 2002
              View Source
              • 0 Attachment
                On Thu, Oct 03, 2002 at 10:53:04AM -0700, Scott Ellsworth wrote:
                >
                > On Thursday, October 3, 2002, at 08:27 AM, Keith Davies wrote:
                >
                > > On Thu, Oct 03, 2002 at 02:38:43PM +0000, David wrote:
                > >> So...for instance...
                > >>
                > >> input engine --> linked lists ???
                > >>
                > >
                > > probably maps (associative arrays) rather than linked lists. Way much
                > > faster for lookups, and table scans don't take significantly longer
                > > because you're looking at everything anyway.
                >
                > This matches my experience. Without fail, converting to maps saves
                > oodles of time. We could do that now, save that our keys are in
                > arbitrary case, and there is resistance to changing that.

                simple workaround - smash case on load. Everything gets keyed by upper
                or lower case value, but displays the label in original case. Thus,
                when loading weapons.lst you add to the Weapons map, and whenever you
                look for something you first smash its case. 'course, you'd probably
                implement the Map interface, then use the specified Map subtype
                internally. That is,

                class SmashMap : implements Map {
                Map mymap;
                SmashMap() {
                mymap = new HashMap();
                }
                SmashMap( Map map) {
                mymap = map;
                // or mymap = map.clone(); if you want a copy
                }
                void insert( key, object) {
                mymap.insert( smash( key), object);
                }
                Object find( key) {
                return mymap.find( smash( key));
                }
                }

                (note: Java syntax and standard class structure may be incorrect; I'm
                making this up as I go.... It should be clear what I meant, though)

                This allows the files to remain in their current state, but internally
                the program can use better values. A possible improvement would be to
                modify the read code so that when a reference value is found (such as
                PREFERREDCLASS in RACE -- again making it up as I go) you smash case
                *there*, instead of when you try to resolve it.

                Between the two changes, you could switch to a Map-based internal
                structure and save yourself a bunch of slow lookups.

                > By having our new data model have a distinct, case sensitive key, but
                > one that a user never sees, we have fast code, and a good user
                > experience. In other words, there is only one entry for the stock
                > fighter class - wotc.dnd.class.fighter or some such. Fighters from
                > Killer Games would be killergames.class.fighter, and thus we could tell
                > immediately which is which. If the user wants to see them in the lists
                > as "Fighter" and "Fighter", we lose nothing, as _we_ and the program
                > know them as two different things. Further, our UI code is not slowed
                > down having to see if perhaps the user meant "WoTc.DnD.Class.Fighter".
                > (Lowercasing on the way in is an option, but I prefer to catch primary
                > key errors immediately, and deliver an error message.)

                Ah, you did mention it. It's not my preferred answer either -- trapping
                errors and giving warnings as soon as possible makes for better
                happiness.

                So, I agree entirely with that last paragraph.

                > > There's not a lot of sense to storing things ordered, either.
                >
                > When I need to store something in order, I get the keyset from the map,
                > order that by whatever sort keys matter (usually a single scan, and
                > very, very fast as I am just swapping a key in an array list), then use
                > that in my table model.
                >
                > The code is not that rough - the key is that we NEVER, EVER, EVER need
                > to resort unless someone adds or subtracts an item from the data model,
                > or they change the sort key. Even then, that is pretty fast.

                Once the load is complete, this shouldn't happen too often unless the
                user is specifically modifying that information (for instance, working
                on a file of weapon descriptions). Lazy evaluation should work well
                enough -- keep keying new items in as fast as possible, then sort it
                when the list gets looked at again. Thus,

                user clicks 'add weapons' button
                system displays 'add weapon form'
                until (close form) {
                while (user keys weapon description and doesn't press button) {
                system enable/disable commit button based on validation results
                }
                if (user pressed commit) {
                system stores weapon description
                system clears form
                } elsif (user pressed cancel) {
                system prompts for confirmation[1]
                if (confirmed) {
                discard entered values
                close form = true
                }
                }
                }
                system closes/frees 'add weapon form'

                Or something similar. It probably isn't necessary to sort the data each
                time, just when the form closes or the list is otherwise displayed in
                full.

                And damn, but it's awkward to try to write event-driven behavior
                algorithmically....

                > I suspect we could do something like this fairly easily for pcgen -
                > lists become lists of keys into the data store, and sort orders are
                > just lists of integers in the keyset, or lists of keys in order.

                Sounds right.


                Keith
                --
                Keith Davies
                keith.davies@...

                PCGen: <reaper/>, smartass
                "You just can't argue with a moron. It's like handling Nuclear
                waste. It's not good, it's not evil, but for Christ's sake, don't
                get any on you!!" -- Chuck, PCGen mailing list
              Your message has been successfully submitted and would be delivered to recipients shortly.