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

Re: Okay - getting down to business

Expand Messages
  • David
    Has there been anything done on building or creating a utility to convert the .pcc/.lst files? I ve looked at files extensively and concluded after a while
    Message 1 of 24 , Oct 3, 2002
    View Source
    • 0 Attachment
      Has there been anything done on building or creating a utility to
      convert the .pcc/.lst files? I've looked at files extensively and
      concluded after a while that the time it takes to build a converter
      may well take longer than simply converting the files manually. I
      know in this bazarre world of tecnocrats like us, this is a rather
      absurd idea. As tedious as it may be, it may be one of the most
      feasible options.

      dB



      --- In pcgen-xml@y..., Scott Ellsworth <scott@a...> wrote:
      > So, the consequence I see is this - we will end up converting
      classes
      > of things, and we will want to have an auto-conversion script for
      the
      > list files, as otherwise, we get to write both a converter _and_ a
      > parser for the same data. Less fun than it could be.
      >
    • David
      Star Wars...all metric. dB ... perhaps ... I ll
      Message 2 of 24 , Oct 3, 2002
      View Source
      • 0 Attachment
        Star Wars...all metric.

        dB



        --- In pcgen-xml@y..., Keith Davies <keith.davies@k...> wrote:
        > Supposing a game comes out where the measures do use SI, though,
        perhaps
        > a flag indicating the unit of measurement would be appropriate.
        I'll
        > think on that for a while.
      • Damian
        From: David ... The new d20 Mecha game in the latest Dragon also uses metric. Although they simply use a rough 2m=5ft convention.
        Message 3 of 24 , Oct 3, 2002
        View Source
        • 0 Attachment
          From: "David" <cyboarg@...>
          > Star Wars...all metric.

          The new d20 Mecha game in the latest Dragon also uses metric. Although they
          simply use a rough 2m=5ft convention.

          -Damian
        • Keith Davies
          ... probably maps (associative arrays) rather than linked lists. Way much faster for lookups, and table scans don t take significantly longer because you re
          Message 4 of 24 , Oct 3, 2002
          View Source
          • 0 Attachment
            On Thu, Oct 03, 2002 at 02:38:43PM +0000, David wrote:
            > So...for instance...
            >
            > input engine --> linked lists ???
            >
            > Items within a linked list are easily indexed and referenced.
            > Depending on the efficiency of the indexing, you have a virtual
            > database running internally. I've done such a thing with control
            > arrays and other lists in VB as a home-grown web server. Very, very
            > fast (yes, even in VB). ;]

            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.

            There's not a lot of sense to storing things ordered, either. Whenever
            we display a list it is subject to almost arbitrary ordering by the
            user, so maintaining the list in any particular order doesn't have much
            point. OTOH, if there are common orderings that are used, or if such
            are specified by the user ("always show me spells in name alpha order")
            we might cache and maintain a list of references to spells, ordered by
            name of the spells... but this is an optimization I think shouldn't be
            dealt with right 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
            ... It s something I have considered, especially given the scope of the changes we ll be making. However, even a simple script that *tries* -- does a first
            Message 5 of 24 , Oct 3, 2002
            View Source
            • 0 Attachment
              On Thu, Oct 03, 2002 at 02:42:18PM +0000, David wrote:
              > Has there been anything done on building or creating a utility to
              > convert the .pcc/.lst files? I've looked at files extensively and
              > concluded after a while that the time it takes to build a converter
              > may well take longer than simply converting the files manually. I
              > know in this bazarre world of tecnocrats like us, this is a rather
              > absurd idea. As tedious as it may be, it may be one of the most
              > feasible options.

              It's something I have considered, especially given the scope of the
              changes we'll be making. However, even a simple script that *tries* --
              does a first pass making decent guesses -- can go a long way to helping
              get the data converted.

              The actual conversion methods used are something we'll deal with later.
              What we need first is something to convert *to*.


              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
            • Scott Ellsworth
              ... 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
              Message 6 of 24 , Oct 3, 2002
              View Source
              • 0 Attachment
                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.

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

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

                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.

                Scott
              • STILES, BRAD
                ... 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,
                Message 7 of 24 , Oct 3, 2002
                View Source
                • 0 Attachment
                  >
                  > 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.

                  Brad
                • 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 8 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 9 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 10 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 11 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 12 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 13 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.