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

Re: [pcgen_developers] Re: Databases, Characters and Cloning

Expand Messages
  • Devon Jones
    This idea has definite merit, though I do have some questions. I ve connected an image that I believe lays out the graph you propose. the two things I don t
    Message 1 of 32 , Jan 17, 2012
    • 1 Attachment
    • 29 KB
    This idea has definite merit, though I do have some questions.

    I've connected an image that I believe lays out the graph you propose.

    the two things I don't get:
    1) Why does human go to choice which goes to boost - I thought boost was granted directly, and it itself grants a choice
    2) Why does UID-C2 point to both Ability: Skill Boost and it's choice, shouldn't it instead point to ability skill boost and another choice that in turn points to skill: hide?

    Actually, looking at it, maybe I do get it.  Let me rephrase it to make sure I understand:

    Ability: Boost and Ability: Skill Boost are both mult:YES, and thus have ambiguities.

    In place of attaching a mult: yes object directly into the graph, you are attaching a choice object.  that choice object has as children both the mult: yes object and any choices granted by that object.  Yes?


    If the above is the case, the following applies.  If not, then no:
    Since the choice has two children, I think it can be confusing as to which is the grantor and which is the selection.  I think these should be different edge types to differentiate between them.  Imagine the case of an ability of a type that grants selection of another of the same type.  It could be very unclear as to which child of the choice is the selection and which is the selector.

    To a degree, I think this is a more efficient version of #3 - wrapping objects, but at the graph level, and only doing it to objects that could potentially have ambiguity.


    Advantages:
    - This also stores all of the information (nothing is lost).
    - No Cloning
    - Less edges then #6
    - Less complicated attaching then #6

    Disadvantages:
    - If I add Human and select skill boost, but don't select a skill, then add Fighter and select skill boost, I think there is still an ambiguity, because you now don't know where to attach the selection - to C2 or to C4.  I think #6 suffers from this as well.  Upon further consideration, this may be a non-issue, but I'll still mention it.
    - The upside on #6 is it is more explicit as to which choices are still available.  With #7 it can be calculated, but it is implicit.
    - The above mentioned ambiguity on the edges as to who is the selector and who is the selectee.  This can be solved easily with edge types.

    Devon

    On Mon, Jan 16, 2012 at 5:31 PM, thpr <thpr@...> wrote:
     



    So calling Devon's Idea #6 (since it is clearly distinct from the other 5), Kar's post along with Devon's idea of consequences of choices got me thinking and here is idea #7:

    Choices are used as inst and can grant native objects to ensure key identity tests pass. The key point is that the two forms of identity I defined (key and inst) are held by two different objects. The Choices hold inst and the objects themselves continue to act as keys.

    Note any items from the LST of the native object are granted by the choice rather than the native object if the object is MULT:YES.

    This shares the same "prune" capability as other graph solutions (although in this case it doesn't need to detect the type of incoming edge, just existence, so it's a bit cleaner)

    This also keeps things "local" so that any object triggering a grant doesn't have to do a monitor its descendants to see if they trigger a choice, it only has to detect: Are any of the things I grant MULT:YES?
    - If not, just put down the graph.
    - If so, it puts down a Choice object and the system analyzes the choice's underlying object (which the code knows since it had to already query it for MULT:YES to get into this code path) in order to find out what it grants, and then places the main object into the graph as a child of the choice (rather than a child of the object itself). This allows non-granting things (e.g. BONUS) to detect weights and be appropriately applied without the choice having to do delegation of method call, and existence tests can simply use .contains on the graph (actually for either the choice [inst] or the base ability [key])

    Choices could be considered cloned in this scenario, although they hold no information, so are very light weight and could just be generated by a factory consistently generating unique objects (in fact, the key shown in the XML below could be generated by the persistence system, as == identity could be used in memory)

    Note the result of the choice is on an outgoing edge of the choice, so that a skill selection for example, could be grabbed by the underlying Ability on one of its incoming edges without having to go up the tree further (if it was on the edge from the parent to the choice, for example)... again keeps things local and no graph traverses to get information.

    <character>
    <race key="Human"/>
    <ability key="Boost"/>
    <ability key="Skill Boost"/>
    <class key="Fighter"/>
    <choice key="UID-C1"/>
    <choice key="UID-C2"/>
    <choice key="UID-C3"/>
    <choice key="UID-C4"/>
    <Skill key="Hide"/>
    <Skill key="Search"/>
    <edge sourcetype="Root" source="Character" desttype="Race" dest="Human"/>
    <edge sourcetype="Root" source="Character" desttype="Class" dest="Fighter"/>
    <edge sourcetype="Race" source="Human" desttype="Choice" dest="UID-C1"/>
    <edge sourcetype="Choice" source="UID-C1" desttype="Ability" dest="Boost"/ choice="Skill Boost">
    <edge sourcetype="Choice" source="UID-C1" desttype="Choice" dest="UID-C2"/>
    <edge sourcetype="Choice" source="UID-C2" desttype="Ability" dest="Skill Boost"/ choice="Hide">
    <edge sourcetype="Choice" source="UID-C2" desttype="Skill" dest="Hide"/ weight=5>
    <edge sourcetype="Class" source="Fighter" desttype="Choice" dest="UID-C3"/>
    <edge sourcetype="Choice" source="UID-C3" desttype="Ability" dest="Boost"/ choice="Skill Boost">
    <edge sourcetype="Choice" source="UID-C3" desttype="Choice" dest="UID-C4"/>
    <edge sourcetype="Choice" source="UID-C4" desttype="Ability" dest="Skill Boost" choice="Search"/>
    <edge sourcetype="Choice" source="UID-C4" desttype="Skill" dest="Search"/ weight=5>
    </character>

    Note this effectively makes any MULT:YES ability into a leaf, and the "main" participant in the graph is the Choice.

    Note also one could add "inst" information to each of the race, ability, class, etc. in order to compact the XML so that the edge would be able to do just source and dest (rather than source, sourcetype, dest, desttype), but IMHO that's a persistence detail, not an in-memory issue.

    TP.


  • Devon Jones
    Awesome, thank you. I ll read these these today
    Message 32 of 32 , Feb 3, 2012
    • 0 Attachment

      Awesome, thank you.  I'll read these these today

      On Feb 2, 2012 11:11 PM, "thpr" <thpr@...> wrote:
       


      Specifically for facets, these two threads lay down the background of what/why:
      http://tech.groups.yahoo.com/group/pcgen_developers/message/86
      http://tech.groups.yahoo.com/group/pcgen_developers/message/308

      Some additional architecture background that was helping to work the thought process is available in these threads:
      http://tech.groups.yahoo.com/group/pcgen_developers/message/37
      http://tech.groups.yahoo.com/group/pcgen_developers/message/48
      http://tech.groups.yahoo.com/group/pcgen_developers/message/50
      http://tech.groups.yahoo.com/group/pcgen_developers/message/52
      http://tech.groups.yahoo.com/group/pcgen_developers/message/53
      http://tech.groups.yahoo.com/group/pcgen_developers/message/54
      http://tech.groups.yahoo.com/group/pcgen_developers/message/55

      Note that this thread clarified new issues found in the graph construction since the threads starting at 53, 54, and 55, and effectively refines those threads.

      TP.

      --- In pcgen_developers@yahoogroups.com, Tom Parker <thpr@...> wrote:
      >
      > pcgen.cdom.facet is the package.
      > Basically we are loading things (effectively lists of objects like Languages) into individually testable objects, in order to break up the application.  The facets then use a listener/event model to add items to themselves, so effectively you end up with a pipeline of facets acting as the data store for the PlayerCharacter.
      >
      >
      > Languages are especially clean, and I think done (?), so that would be the most instructive thing to see how they are being handled through the pipeline of events when an object is added to a PC. 
      >
      >
      > Will explain more later once I'm not trying to multitask with a (somewhat after hours) work phone call...
      >
      >
      > TP.
      >
      >  
      >
      > ________________________________
      > From: Devon Jones <devon.jones@...>
      > To: pcgen_developers@yahoogroups.com
      > Sent: Wednesday, February 1, 2012 5:18 PM
      > Subject: Re: [pcgen_developers] Re: Databases, Characters and Cloning
      >
      >
      >
      >
      >
      > So the Facet system is all new to me.  I'm not sure where to start to look to implementing this in Facet instead of as a graph.  Where should I look (code, dos or papers) to get an understanding of the Facet system?)
      >
      >
      > On Wed, Feb 1, 2012 at 4:38 PM, thpr <thpr@...> wrote:
      >
      >
      > > 
      > >I think it's to the point where we know the next step.
      > >
      > >The key point - common between both #6 and #7 is that the unique identifier for the instance and a unique identifier for an Ability are two different objects.
      > >
      > >So I think the next step is to do that break-up in some way - hopefully consistent with the facet system we are using in the core.
      > >
      > >I don't think we're at a point where we can (or should) be putting things in a graph structure.
      > >
      > >TP.
      > >
      > >
      > >--- In pcgen_developers@yahoogroups.com, Devon Jones <devon.jones@> wrote:
      > >>
      > >
      > >> so have we hashed this out sufficiently that we think we can make the
      > >> trackers? I'm happy to attempt this after I'm done with the my work on
      > >> AUTO.
      > >>
      > >> Devon
      > >>
      > >
      > > On Mon, Jan 23, 2012 at 3:13 PM, Devon Jones <devon.jones@> wrote:
      > >>
      > >> > **
      > >
      > >> >
      > >> >
      > >> > I think the problem is that I'm not super well versed in TEMPLATE due to
      > >> > years of inactivity. The structure you've layed out looks good to me.
      > >> >
      > >> > Devon
      > >> >
      > >> >
      > >> >
      > >
      > > > On Thu, Jan 19, 2012 at 6:43 PM, Tom Parker <thpr@> wrote:
      > >> >
      > >> >> **
      > >> >>
      > >> >> [Attachment(s) <#1350c33a9c0020d7_134f85aee8f2696d_TopText> from Tom
      > >
      > >> >> Parker included below]
      > >> >>
      > >> >>
      > >> >> --- In pcgen_developers@yahoogroups.com, Devon Jones <devon.jones@>
      > >
      > >> >> wrote:
      > >> >> > So I'm considering this, but one observation I have is that both A & B
      > >> >> > require the same thing that proposal #6 required, which is that you
      > >> >> need to
      > >> >> > know about all choices downstream of an object that is attached when
      > >> >> you do
      > >> >> > the attachment so that you know if you need to attach it via a choice
      > >> >> > object.
      > >> >>
      > >> >> I'm confused by this assertion of similarity. The knowledge situations
      > >> >> are different. Even if you view it as downstream knowledge (I don't - see
      > >> >> below), 6 requires knowledge be recursive, 7A and 7B do not.
      > >> >>
      > >> >> Consider this obviously contrived example:
      > >> >> RACE:Human <> TEMPLATE:Human Stuff
      > >> >> TEMPLATE:Human Stuff <> ADD:FEAT|Boost
      > >> >> ABILITY:Human Stuff <> CHOOSE:TEMPLATE|TYPE=Boost <> MULT:YES
      > >> >> TEMPLATE:Skill Boost Framework <> TYPE:Boost <> ADD:FEAT|Skill Boost
      > >> >> ABILITY:Skill Boost <> CHOOSE:SKILL|ANY <> MULT:YES
      > >> >> SKILL:Hide
      > >> >>
      > >> >> #6 would require the CHOOSE from Human Stuff to recursively go through
      > >> >> TEMPLATE:Skill Boost Framework to see ABILITY:Skill Boost and attach the
      > >> >> choose from "Human Stuff" to the choose from "Skill Boost" (probably would
      > >> >> happen as a traverse up the graph, but it's still a graph traverse to find
      > >> >> the parent/child choice relationship). See the blue dashed line in the
      > >> >> graphic for how the recursive check has to happen in order to build the red
      > >> >> line. This is the "non-locality" I am concerned about.
      > >> >>
      > >> >> #7 only requires local knowledge by an object of whether it is MULT:YES
      > >> >> during the add to the graph action. The code (not related anything near
      > >> >> our current code base, of course) can do:
      > >> >>
      > >> >> addGrantedStuff(CDOMObject parent)
      > >> >> {
      > >> >> for (Node objToAdd : parent.getGrants())
      > >> >> {
      > >> >> Node linkToParent = objToAdd;
      > >> >> if (objToAdd.allowMultiples())
      > >> >> {
      > >> >> ChoiceSelectionThingy chooser = objToAdd.getChooser();
      > >> >> ChoiceNode choose = ChoiceNode.getNodeFor(chooser);
      > >> >> graph.addNode(choose);
      > >> >> Edge edge = new Edge(choose, objToAdd);
      > >> >> edge.setType(EdgeType.CHOOSE_OWNER);
      > >> >> graph.addEdge(edge);
      > >> >> linkToParent = choose;
      > >> >> }
      > >> >> graph.addNode(linkToParent);
      > >> >> Edge edge = new Edge(parent, linkToParent);
      > >> >> graph.addEdge(edge);
      > >> >> addGrantedStuff(objToAdd);
      > >> >> }
      > >> >> }
      > >> >>
      > >> >> That's it. The parent never knows it's child has a CHOOSE (the code
      > >> >> adding stuff to the graph has to know that in any method we choose) and
      > >> >> there is no recursion to find out what the children of objToAdd do ...
      > >> >> except the natural granting from grants themselves (regardless of choices)
      > >> >> being recursive. (but no "look ahead" or "look back" is required
      > >> >> independent of the grant code)
      > >> >>
      > >> >> (p.s. this method is probably a bit backwards and it probably should be
      > >> >> grant(parent, child) so it doesn't depend on duplicate code somewhere doing
      > >> >> the original grant, but it serves the purpose of illustrating locality
      > >> >> none-the-less)
      > >> >>
      > >> >>
      > >> >> > Also, how do we handle this if Ability: Advantage also provides a
      > >> >> > choice?
      > >> >>
      > >> >> I don't understand. It DOES provide a choice right now - the CHOOSE is
      > >> >> in the LST example...
      > >> >>
      > >> >> If you're asking whether one CHOOSE object can grant another CHOOSE
      > >> >> object, then yes, you already drew that in response to my initial #7
      > >> >> proposal:
      > >> >>
      > >> >> http://groups.yahoo.com/group/pcgen_developers/attachments/folder/2010049280/item/1983928438/view
      > >> >>
      > >> >> One choose object is simply attached to another.
      > >> >>
      > >> >>
      > >> >> > Or is this presently verboten? e.g. can you get around MULT: YES
      > >> >> > allowing only one choice by also applying a template?
      > >> >>
      > >> >> Starting a bit confused at this point, but I think the answer is MAYBE.
      > >> >> Theoretically you could do a bunch of stuff to try to get around the fact
      > >> >> that MULT:YES only allows a single choice... HOWEVER, the reason we need
      > >> >> multiple choices is things like:
      > >> >> Select a Class and Level for which to apply a bonus spell (yes, we have a
      > >> >> hack around this but it's a simple example of how two choices are closely
      > >> >> associated and thus can't do it without having a method for us to "address"
      > >> >> a choice from another object, or creating all N permutations)
      > >> >>
      > >> >> Does that answer what you were asking?
      > >> >>
      > >> >> TP.
      > >> >>
      > >> >>
      > >> >
      > >> >
      > >>
      > >
      > >
      >

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