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

Re: [ARCH] Developing the Graph model of a PlayerCharacter (part 2)

Expand Messages
  • Tom Parker
    ... I think we need to be precise on some language: Action by user: - Selection (e.g. taking a Feat using a point from the Feat pool) - De-selection (e.g.
    Message 1 of 4 , Jul 29, 2009
    • 0 Attachment
      --- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@...> wrote:
      > > [lots of Adds & Removes]

      > We're also potentially get a massively bloated graph right?
      > Lets assume we have a user who _loves_ tinkering with his/her
      > PC, adding and removing various Templates and other such
      > things, is there a danger it's going to grow too large?

      I think we need to be precise on some language:

      Action by user:
      - Selection (e.g. taking a Feat using a point from the Feat pool)
      - De-selection (e.g. changing their choice on what Feat to take)

      Action by data:
      - Grant (e.g. use of ADD:FEAT token)
      - Remove (e.g. use of REMOVE:FEAT token)

      If a user fumbles with a PC and makes 100 temporary feat selections (98 of which are undone by de-selections) on their way to making their 1st level Sorcerer, only the final 2 selections are stored in the PC. De-selections (actions by a user) are not permanently stored; only those selections that are kept are stored.

      If someone codes a LOT of REMOVE:THINGY|Foo type tokens, then any grants impacted by those REMOVEs will provide overhead that we store permanently. Such is the cost of being able to undo the removal if the parent of the REMOVE is unselected as someone is changing their choices as they build a PC.

      Summary: Action by user: lightweight, Action by data: heavyweight.

      Thus, if the tinkering is simply testing what happens, then it doesn't matter. If the tinkering is done by using REMOVEs in data, then based on our principle to store changes, we must bear the burden of carrying along that knowledge.

      TP.
    • Martijn Verburg
      Hi Tom/All, ... Gotcha, more than happy with that (the 2nd scenario will not occur often). K
      Message 2 of 4 , Jul 30, 2009
      • 0 Attachment
        Hi Tom/All,

        > > We're also potentially get a massively bloated graph right?
        > > Lets assume we have a user who _loves_ tinkering with his/her
        > > PC, adding and removing various Templates and other such
        > > things, is there a danger it's going to grow too large?
        >
        > I think we need to be precise on some language:
        >
        > Action by user:
        > - Selection (e.g. taking a Feat using a point from the Feat pool)
        > - De-selection (e.g. changing their choice on what Feat to take)
        >
        > Action by data:
        > - Grant (e.g. use of ADD:FEAT token)
        > - Remove (e.g. use of REMOVE:FEAT token)
        >
        > If a user fumbles with a PC and makes 100 temporary feat selections
        > (98 of which are undone by de-selections) on their way to making
        > their 1st level Sorcerer, only the final 2 selections are stored in
        > the PC. De-selections (actions by a user) are not permanently
        > stored; only those selections that are kept are stored.
        >
        > If someone codes a LOT of REMOVE:THINGY|Foo type tokens, then any
        > grants impacted by those REMOVEs will provide overhead that we
        > store permanently. Such is the cost of being able to undo the
        > removal if the parent of the REMOVE is unselected as someone is
        > changing their choices as they build a PC.
        >
        > Summary: Action by user: lightweight, Action by data: heavyweight.
        >
        > Thus, if the tinkering is simply testing what happens, then it
        > doesn't matter. If the tinkering is done by using REMOVEs in data,
        > then based on our principle to store changes, we must bear the
        > burden of carrying along that knowledge.

        Gotcha, more than happy with that (the 2nd scenario will not occur often).

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