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

Re: [pcgen_developers] Re: Code Team meeting, Friday Nov 13

Expand Messages
  • James Dempsey
    (10:01:37 AM) James[Code_SB]: Alright, I have 10am in Canberra so time to start (10:01:49 AM) James[Code_SB]: Welcome everyone to the PCGen code meeting
    Message 1 of 5 , Nov 17, 2009
      (10:01:37 AM) James[Code_SB]: Alright, I have 10am in Canberra so time
      to start
      (10:01:49 AM) James[Code_SB]: Welcome everyone to the PCGen code meeting
      (10:02:18 AM) James[Code_SB]: The agenda for todays meeting is
      (10:02:20 AM) James[Code_SB]: 1. Status update (including readiness for
      (10:02:20 AM) James[Code_SB]: 2. New UI demo - path getting something
      out before Christmas
      (10:02:20 AM) James[Code_SB]: 3. Output sheets/output tokens
      (10:02:20 AM) James[Code_SB]: 4. Other business
      (10:02:52 AM) James[Code_SB]: Any objections or extra suggestions?
      (10:03:08 AM) [Arch_SB]thpr: Not unless Nuance shows up
      (10:03:19 AM) James[Code_SB]: ok
      (10:03:37 AM) James[Code_SB]: 1. Status update (including readiness for
      (10:03:44 AM) James[Code_SB]: I'll start
      (10:04:26 AM) James[Code_SB]: I've been doing a bit of bug fixing for
      5.16 and think all the essential ones (bar one) have been dealt with
      (10:05:16 AM) James[Code_SB]: Currently stuck on the purchase points
      issue and while I have a fix done I need to go back and look at how it
      affects older characters and if it makes sense for them. So that has
      slowed me down a bit.
      (10:05:52 AM) James[Code_SB]: Tom, did you want to go next?
      (10:06:36 AM) [Arch_SB]thpr: Sure
      (10:06:56 AM) [Arch_SB]thpr: My machine is currently running the unit
      tests for the SPELLLEVEL issue
      (10:07:05 AM) [Arch_SB]thpr: so that should be fixed here in about 15
      mins once it finishes
      (10:07:34 AM) [Arch_SB]thpr: (for 5.16.2)
      (10:07:58 AM) James[Code_SB]: We have one unit test failure in the trunk
      currently - looks like a data change we need to do an update for
      (10:08:14 AM) [Arch_SB]thpr: oh, I hadn't noticed that
      (10:08:18 AM) [Arch_SB]thpr: because my fix is in the 5.16 branch
      (10:08:25 AM) [Arch_SB]thpr: which appears clean so far
      (10:08:34 AM) TirGwaith: James, what data change (which unit test)?
      (10:10:19 AM) [Arch_SB]thpr: umm, where are the autobuilds now? The
      pcgen.org shows a 23 Jul set of tests
      (10:10:22 AM) James[Code_SB]: See
      http://pcgen.sourceforge.net/autobuilds/junit-report.html looks like a
      MSRD abilities change, but I haven't looked further into it yet
      (10:10:30 AM) [Arch_SB]thpr: great timing James
      (10:10:40 AM) [Admin]Drew: might be a change I made...
      (10:10:48 AM) [Arch_SB]thpr: We should delete the old results from pcgen.org
      (10:10:54 AM) James[Code_SB]: Yep I'll do that
      (10:10:56 AM) [Arch_SB]thpr: so people don't continue to look at them
      (10:11:16 AM) TirGwaith: Drew, I'm checking into it now.
      (10:11:58 AM) [Arch_SB]thpr: ok, back to my report I guess
      (10:12:06 AM) TirGwaith: sorry for the sidetrack
      (10:12:20 AM) [Arch_SB]thpr: Tir: no worries.
      (10:12:45 AM) [Arch_SB]thpr: I think I took an action from one of the
      previous meetings to work on the formula compiler (lost track if that
      was 1 or 2 meetings ago)
      (10:13:10 AM) [Arch_SB]thpr: I did update that code in the sandbox and
      it can now parse pretty much every formula in our data
      (10:13:24 AM) James[Code_SB]: Nice
      (10:13:32 AM) [Arch_SB]thpr: I also found some data bugs while
      developing, and opened some work for the data team
      (10:14:00 AM) [Arch_SB]thpr: I think Drew may have addressed some of
      them already
      (10:14:21 AM) [Arch_SB]thpr: but that is now ready for further
      evaluation to see if we want to use that to process formulas during LST load
      (10:14:59 AM) [Arch_SB]thpr: not much more work on the facet side since
      last time, so nothing to report there
      (10:15:06 AM) [Arch_SB]thpr: that's it from me
      (10:15:37 AM) *cpmeister [/n=cpmeiste@.../] entered
      the room.*
      (10:15:44 AM) James[Code_SB]: Hi Connor
      (10:15:50 AM) cpmeister: hi all!
      (10:15:52 AM) [Arch_SB]thpr: Hey Connor
      (10:16:48 AM) James[Code_SB]: Mark did you want to go next
      (10:16:54 AM) MotorViper: OK
      (10:17:04 AM) James[Code_SB]: Connor we are going through current status
      (10:17:18 AM) cpmeister: ah, ok
      (10:17:39 AM) MotorViper: I've finished the first pass of the change in
      error reporting. Still more to do however.
      (10:17:59 AM) MotorViper: I've also started to write the lst editor.
      (10:18:42 AM) MotorViper: There's a small problem with getting the list
      of tokens automatically, which may be because I'm not fully up to speed
      with the code yet.
      (10:19:19 AM) MotorViper: For instance I see ConcretePreReqObject but
      not Feats!
      (10:19:48 AM) [Arch_SB]thpr: Let me pull together a description for you
      of how to get the token list
      (10:19:57 AM) James[Code_SB]: Shall we hit that one at the end?
      (10:20:12 AM) MotorViper: That's ok with me.
      (10:20:12 AM) [Arch_SB]thpr: yea, we can come back to taht
      (10:20:16 AM) James[Code_SB]: Cool
      (10:21:08 AM) James[Code_SB]: All done Mark?
      (10:21:27 AM) MotorViper: That's all for now.
      (10:21:55 AM) James[Code_SB]: Thanks! Connor, did you want to add a report?
      (10:22:20 AM) cpmeister: not particularly, I just wanted to drop by :)
      (10:22:26 AM) James[Code_SB]: :)
      (10:22:58 AM) James[Code_SB]: Cool - I assume you have been busy with
      (10:23:32 AM) cpmeister: yeah, pretty much
      (10:24:01 AM) James[Code_SB]: ok, so it sounds like we are very close to
      being ready for a RC of 5.16.2.
      (10:24:18 AM) James[Code_SB]: In fact, once your SPELLEVEL fix is in TOm
      I'll start work on the release
      (10:25:11 AM) James[Code_SB]: Alright, moving on
      (10:25:12 AM) James[Code_SB]: 2. New UI demo - path getting something
      out before Christmas
      (10:26:33 AM) James[Code_SB]: We've been asked to provide something to
      the commuinity to comment on before we go too far, which I have to agree
      is a good idea
      (10:26:58 AM) James[Code_SB]: I think a few screen shots would be a good
      inital offering
      (10:27:36 AM) James[Code_SB]: and from what I have seen the CDOM-UI
      branch is probably up to that about now apart from how the character
      sheet would be displayed
      (10:27:45 AM) James[Code_SB]: Thoughts Connor?
      (10:28:44 AM) cpmeister: I think screen shots would be a good start,
      since trying to get a working demo would produce a lot of unnessesary code
      (10:28:59 AM) James[Code_SB]: Indeed
      (10:29:28 AM) James[Code_SB]: Would there be a simple way of grafting on
      the character sheet display in the way you intended?
      (10:29:55 AM) James[Code_SB]: I'd be equally happy to do some work in an
      image program to merge two screen shots for instance
      (10:31:18 AM) cpmeister: there should be, I'm not sure if the current
      demo just has a blank space where it is supposed to be, but iy would be
      fairly easy to set it up so you can easily image edit it
      (10:31:56 AM) cpmeister: I'd need to check
      (10:31:59 AM) James[Code_SB]: Should we have a quick chat offline about
      what you intended and I'll set up the demo?
      (10:32:14 AM) cpmeister: sure, if you want
      (10:33:22 AM) James[Code_SB]: So actions out of that:
      (10:33:31 AM) James[Code_SB]: Connro and James to chat about presentation
      (10:33:48 AM) James[Code_SB]: James to assemble some screenshots for
      community discussion
      (10:35:00 AM) James[Code_SB]: -
      (10:35:01 AM) James[Code_SB]: 3. Output sheets/output tokens
      (10:35:02 AM) James[Code_SB]: -
      (10:35:14 AM) James[Code_SB]: Tom, did you want to lead that one?
      (10:35:19 AM) [Arch_SB]thpr: sure
      (10:36:10 AM) [Arch_SB]thpr: So the goal is to look at how we
      restructure the output tokens
      (10:36:22 AM) [Arch_SB]thpr: this is a code change, not a literal
      formatting change for the tokens
      (10:36:39 AM) [Arch_SB]thpr: so if a token appeared in a file as
      "TEMPLATE.X.NAME" today, it would remain that way in the immediate future
      (10:36:48 AM) [Arch_SB]thpr: the intent here is to redo the code underneath
      (10:37:02 AM) [Arch_SB]thpr: this can accomplish a few things
      (10:37:21 AM) [Arch_SB]thpr: first, get the tokens out of the core, so
      that they are more plugins, akin to the LST token work done in 5.16
      (10:37:46 AM) [Arch_SB]thpr: second, get away from the long if
      statements we have in token lookups (which will help performance during
      output due to less string comparisons)
      (10:38:12 AM) [Arch_SB]thpr: third, provide more modularity to the
      tokens to allow easier and more isolated changes
      (10:38:26 AM) [Arch_SB]thpr: (this is similar to how we have separate
      LST tokens for subtokens of ADD, CHOOSE, etc.)
      (10:38:52 AM) [Arch_SB]thpr: fourth, to provide more code reuse (we have
      a bunch of copy/paste going on in the output system)
      (10:39:20 AM) [Arch_SB]thpr: and also, at least I'd like to get more of
      a handle on what the output tokens can do, so we can do conversions
      (10:39:30 AM) [Arch_SB]thpr: we have a few duplicate output tokens
      (10:39:42 AM) [Arch_SB]thpr: but it would be nice to be able to read in
      an unformatted OS and output a new unformatted OS with the "correct"
      token names
      (10:39:59 AM) [Arch_SB]thpr: just as we do automated conversion in the
      LST files today for token changes between versions (like we are doing
      with CHOOSE)
      (10:40:25 AM) [Arch_SB]thpr: so, with all of those expectations...
      (10:40:57 AM) [Arch_SB]thpr: the idea that I have is to turn the tokens
      into a form of pipeline
      (10:41:11 AM) [Arch_SB]thpr: so that each item does a set of processing
      and can pass to another item
      (10:41:25 AM) [Arch_SB]thpr: TEMPLATE.X.NAME for example, is 3 items,
      TEMPLATE, X, and NAME
      (10:41:40 AM) [Arch_SB]thpr: (the X presumably is from an IF statement
      that is iterating over a set of numbers)
      (10:42:06 AM) *[Admin]Drew is now known as Drew_afk*
      (10:42:45 AM) [Arch_SB]thpr: With that design, if we produced something
      that could take in a Domain and output its name (e.g. DOMAIN.X.NAME)
      (10:43:08 AM) [Arch_SB]thpr: that output item (specifically the NAME
      component) could be reused in other places where a Domain could be
      produced, e.g. DEITY.DOMAINS.X.NAME
      (10:43:20 AM) [Arch_SB]thpr: this is possible with the same code
      (10:43:31 AM) [Arch_SB]thpr: by making this separation for each item
      (10:43:59 AM) [Arch_SB]thpr: So (and I'm duplicating a bit what was in
      my prep note), this leads to 6 types of items:
      (10:44:15 AM) [Arch_SB]thpr: Starting List (e.g. TEMPLATE) ... MUST
      appear as the first item in a token, returns a list
      (10:44:21 AM) [Arch_SB]thpr: Starting Object (e.g. RACE) .... MUST
      appear as the first item in a token, returns an object
      (10:44:28 AM) [Arch_SB]thpr: Filter (e.g. SPELLCASTER) ... MUST not
      appear as the first item, MUST start with a list, and returns a list
      (10:44:35 AM) [Arch_SB]thpr: Expander (e.g. DOMAIN) ... MUST not appear
      as the first item, MUST start with a single object and returns a list
      (10:44:42 AM) [Arch_SB]thpr: Reducer (e.g. X) ... MUST not appear as the
      first item, MUST start with a list and returns an object
      (10:44:48 AM) [Arch_SB]thpr: Characteristic (e.g. NAME) ... MUST not
      appear as the first item, MUST start with a single object and returns a
      (10:45:44 AM) [Arch_SB]thpr: with a few exceptions, that should provide
      a feature-complete set of tokens
      (10:45:59 AM) [Arch_SB]thpr: The two main sets of exceptions are:
      (10:46:08 AM) [Arch_SB]thpr: 1) Stateful tokens controlling whitespace
      (10:46:24 AM) [Arch_SB]thpr: 2) Some Game Mode information tokens, such
      as units (meters, feet)
      (10:46:52 AM) [Arch_SB]thpr: those are both single item type things that
      don't need the pipeline complexity
      (10:47:05 AM) [Arch_SB]thpr: any questions so far?
      (10:47:55 AM) MotorViper: Just a comment, making whitespace behaviour
      etc. different may be more efficient but it can fit into the schema and
      makes the code more consistent.
      (10:48:41 AM) [Arch_SB]thpr: I think they need to share some of the
      (10:48:50 AM) [Arch_SB]thpr: they shouldn't be in a big if statement
      still, for example
      (10:49:25 AM) [Arch_SB]thpr: but as far as sharing the same interfaces
      (which may return a String result), I have to think more about that.
      (10:49:31 AM) [Arch_SB]thpr: They don't process information, they
      control state, so they are different
      (10:50:18 AM) MotorViper: Not really they are just another type of
      output, the main difference is where they get their info from.
      (10:50:37 AM) James[Code_SB]: Except some of them do control state
      (10:50:54 AM) James[Code_SB]: The manual whitespace one for instance
      (10:51:10 AM) [Arch_SB]thpr: The Game Mode items are output, so they can
      probably share the Interface of the last set of tokens (that returns a
      (10:51:20 AM) [Arch_SB]thpr: But the whitespace controllers don't ever
      output anything, so I'm cautious to use that Interface
      (10:51:36 AM) [Arch_SB]thpr: because it leads can lead to false
      conclusions about behavior
      (10:52:13 AM) [Arch_SB]thpr: Long term, I'd like to get rid of them by
      having a different OS system (e.g. templating) that doesn't require them
      as a workaround
      (10:52:16 AM) MotorViper: Sorry got confused I assumed manual whitespace
      was inserting whitespace so I withdraw, at least partially, my comment.
      (10:52:36 AM) James[Code_SB]: True
      (10:52:47 AM) James[Code_SB]: I assume you have a plan in mind for
      characteristics which only apply to specific objects?
      (10:53:08 AM) [Arch_SB]thpr: Yes, pretty much identical to how the LST
      tokens work
      (10:53:25 AM) [Arch_SB]thpr: meaning it can be an OutputToken<Ability>
      and do things specifically for Ability objects
      (10:53:40 AM) [Arch_SB]thpr: or OutputToken<CDOMObject> and apply to any
      type of CDOMObject (this is what NAME would actually be)
      (10:54:14 AM) James[Code_SB]: Right
      (10:54:17 AM) [Arch_SB]thpr: this minimizes duplication of the basic
      CDOMObject info (NAME, SOURCE, etc.)
      (10:55:29 AM) [Arch_SB]thpr: so if I go back to the DEITY.DOMAINS.X.NAME
      (10:55:33 AM) [Arch_SB]thpr: we can walk through that a bit
      (10:55:50 AM) [Arch_SB]thpr: DEITY is a Starting Object, since a PC can
      only have one Deity
      (10:56:01 AM) [Arch_SB]thpr: so it returns a Deity
      (10:56:23 AM) [Arch_SB]thpr: the next item (DOMAINS) is then evaluated
      in context to Deity
      (10:56:42 AM) [Arch_SB]thpr: meaning the system looks for a
      Characteristic or Filter that is for a DEITY
      (10:56:53 AM) [Arch_SB]thpr: If it was a Characteristic it would be an
      error (since it's followed by another item)
      (10:57:22 AM) [Arch_SB]thpr: DOMAINS would be an Expander<Deity> (making
      up the interfaces here)
      (10:57:32 AM) [Arch_SB]thpr: It would return a List<Domain>
      (10:58:15 AM) [Arch_SB]thpr: (I'm considering it returns the DOMAINS
      specified in the DOMAINS token in the LST file for the PC
      (10:58:17 AM) [Arch_SB]thpr: 's Deity)
      (10:58:36 AM) [Arch_SB]thpr: The next item is then tested in the context
      of List<Domain>
      (10:58:49 AM) [Arch_SB]thpr: X (representing a number) is a Reducer,
      which can work on a list
      (10:59:13 AM) [Arch_SB]thpr: (note that this could also be one or more
      filters followed by a reducer)
      (10:59:25 AM) [Arch_SB]thpr: the result of the reduction is a single Domain
      (10:59:43 AM) [Arch_SB]thpr: then NAME is tested in the context of
      Domain, and it's a Characteristic<CDOMObject>
      (11:00:04 AM) [Arch_SB]thpr: since Domain extends CDOMObject, it can be
      used, so the NAME of the Domain is output
      (11:00:39 AM) [Arch_SB]thpr: Similar as to how the LST tokens work, if a
      Characteristic<Domain> called "NAME" existed as well as a
      Characteristic<CDOMObject> called "NAME", the more specific one would "win"
      (11:01:02 AM) [Arch_SB]thpr: The system can also detect (and produce an
      error) if two Characteristics with the same target class and same name
      are loaded
      (11:01:08 AM) [Arch_SB]thpr: just as is done with LST tokens today
      (11:01:32 AM) James[Code_SB]: Sounds good
      (11:01:56 AM) [Arch_SB]thpr: that's pretty much it
      (11:02:10 AM) [Arch_SB]thpr: I have some specific examples of the
      interfaces in the note I shipped out
      (11:02:29 AM) [Arch_SB]thpr: and we'll need to polish that so there
      aren't code cycles
      (11:02:52 AM) MotorViper: Is it worth adding in something like
      DEITY.DOMAINS.NAMES where NAMES is an aggregator, i.e. it takes a list
      and produces a string
      (11:02:53 AM) [Arch_SB]thpr: (I haven't stopped long enough this week to
      work through that to ensure a solution I like)
      (11:03:46 AM) [Arch_SB]thpr: that sounds very interesting. Tir, are
      there places in the OS where we do that type of list generation that
      this would help eliminate a loop?
      (11:05:14 AM) [Arch_SB]thpr: I'll check on that; we can move on
      (11:05:21 AM) [Arch_SB]thpr: I think it's a good idea though
      (11:05:46 AM) [Arch_SB]thpr: and likely will help simplify OS, so we
      should consider that part of the plan unless we prove it really can't help
      (11:06:10 AM) TirGwaith: typically, we do a loop for getting at objects
      and data in them. But some of the tokens for Stat sheets just print a list
      (11:06:46 AM) TirGwaith: I'm not sure if they just loop through the
      objects and print names or not
      (11:07:02 AM) [Arch_SB]thpr: there are some cases, e.g. languages, where
      it seems that would be useful
      (11:07:13 AM) TirGwaith: proficiencies
      (11:07:14 AM) [Arch_SB]thpr: at least without looking at the OS :)
      (11:07:18 AM) [Arch_SB]thpr: another one, yes
      (11:08:13 AM) [Arch_SB]thpr: any other thoughts or ideas?
      (11:09:19 AM) [Arch_SB]thpr: back to you I think, James
      (11:10:24 AM) James[Code_SB]: That seemed like a pretty thorough study
      Tom - thanks
      (11:10:42 AM) James[Code_SB]: 4. Other business
      (11:11:03 AM) James[Code_SB]: I think the first thing to discuss was
      getting the list of tokens automatically for the editor
      (11:11:19 AM) [Arch_SB]thpr: eek
      (11:11:21 AM) [Arch_SB]thpr: not ready yet
      (11:11:25 AM) [Arch_SB]thpr: machine has been lagging with a build
      (11:11:34 AM) James[Code_SB]: ok, we can do that on the list easily enough
      (11:11:39 AM) James[Code_SB]: That work for you Mark?
      (11:11:51 AM) [Arch_SB]thpr: give me 2 min
      (11:11:54 AM) James[Code_SB]: ok
      (11:12:09 AM) James[Code_SB]: Anyone have anything else they wanted to
      (11:12:10 AM) MotorViper: Any time, as long as I'm still awake!
      (11:12:15 AM) James[Code_SB]: :)
      (11:15:59 AM) [Arch_SB]thpr: ok
      (11:16:13 AM) [Arch_SB]thpr: Sorry about the lag guys, having some
      issues here
      (11:16:15 AM) [Arch_SB]thpr: TokenFamilyIterator<T> it = new
      (11:16:15 AM) [Arch_SB]thpr: while (it.hasNext())
      (11:16:15 AM) [Arch_SB]thpr: {
      (11:16:15 AM) [Arch_SB]thpr: CDOMPrimaryToken<? super T> token = it.next();
      (11:16:15 AM) [Arch_SB]thpr: }
      (11:16:37 AM) [Arch_SB]thpr: give the class you want to deal with (e.g.
      Race.class) to TokenFamilyIterator
      (11:16:46 AM) [Arch_SB]thpr: it will return to you the possible tokens
      you can use
      (11:17:11 AM) [Arch_SB]thpr: including any that are valid due to the
      parent of the class (e.g. CDOMPrimaryToken<CDOMObject> would also be
      returned for Race.class)
      (11:17:25 AM) [Arch_SB]thpr: You can see it actually used in public <T>
      Collection<String> unparse(LoadContext context, T cdo)
      (11:17:35 AM) [Arch_SB]thpr: within
      (11:17:43 AM) [Arch_SB]thpr: as part of supporting unparsing of data
      (11:17:56 AM) [Arch_SB]thpr: which has to do an exhaustive iteration
      over all the tokens
      (11:18:16 AM) [Arch_SB]thpr: is that what you're looking for Mark?
      (11:18:38 AM) MotorViper: I was actually trying to get the list of items
      at the level above, i.e. Race, Deity, Skill etc.
      (11:19:11 AM) [Arch_SB]thpr: ok, need to be specific here
      (11:19:22 AM) [Arch_SB]thpr: Race, has a token called Hands
      (11:19:28 AM) [Arch_SB]thpr: there is a global token called Spells
      (11:19:32 AM) [Arch_SB]thpr: when you ask for Race tokens
      (11:19:39 AM) [Arch_SB]thpr: do you want only Hands, or both Hands and
      (11:20:42 AM) [Arch_SB]thpr: or am I not following what you're asking for?
      (11:21:42 AM) MotorViper: I'm looking for the global tokens, i.e. I want
      something that will return the list that is partially hard-coded in the
      current list editor.
      (11:22:15 AM) [Arch_SB]thpr: so just pass in CDOMObject.class into
      (11:22:45 AM) [Arch_SB]thpr: or maybe I should ask where it's hardcoded
      (11:22:46 AM) MotorViper: I see, I'll give it a go now and see if it
      gives what I want. Can you wait a few minutes?
      (11:22:54 AM) [Arch_SB]thpr: absolutely
      (11:23:22 AM) [Arch_SB]thpr: sounds to me like were into detail beyond
      what we need to call the formal meeting though
      (11:23:43 AM) MotorViper: I agree this is probably outside the meeting.
      (11:23:48 AM) James[Code_SB]: One last thing I wanted to chat quickly about
      (11:24:10 AM) James[Code_SB]: I while ago I added Spring support into a
      sample of the facets
      (11:24:43 AM) James[Code_SB]: Just wondering if anyone had any views on
      it - for or against
      (11:25:36 AM) cpmeister: none from me
      (11:26:03 AM) [Arch_SB]thpr: I'm for, just hadn't done any of the others
      since my focus has been 5.16 bugs and CHOOSE changes
      (11:26:47 AM) James[Code_SB]: no worries - anyone can have stab at
      migrating some other too if they like. It's pretty straight forward
      (11:27:02 AM) James[Code_SB]: ok, anything else to discuss?
      (11:27:53 AM) TirGwaith: for some reason, I'm not seeing the raw data
      xml output on Elwood, so I can't really compare. I'm not sure where my
      system is putting it
      (11:29:05 AM) James[Code_SB]: I can give you a hand with that
      (11:29:35 AM) James[Code_SB]: coce/testsuite/output/Elwood.xml
      (11:30:01 AM) James[Code_SB]: and it is compared to
      (11:32:29 AM) TirGwaith: ok, different than I was expecting. Ok,
      something about Uncanny dodge, and some DESCs.
      (11:32:42 AM) James[Code_SB]: Happy to chat about those
      (11:32:43 AM) TirGwaith: I think it is a data change, but those would
      have to be from
      (11:32:49 AM) TirGwaith: Eddy's converter run
      (11:32:50 AM) James[Code_SB]: Sounds like that's all for now
      (11:32:57 AM) James[Code_SB]: Thanks for coming along everyone
    Your message has been successfully submitted and would be delivered to recipients shortly.