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

Re: [pcgen_developers] We Deprecating WEAPONBONUS?

Expand Messages
  • Tom Parker
    This impact LANGBONUS as well? Unfortunately, I don t think this is as simple as this discussion implies. It can be used in Race: FooRace
    Message 1 of 5 , Mar 8, 2012
    • 0 Attachment
      This impact LANGBONUS as well?

      Unfortunately, I don't think this is as simple as this discussion implies.

      It can be used in Race:
      FooRace <> WEAPONBONUS:BladedWeapon|SharpWeapon

      Then in a Template:
      BarTemplate <> WEAPONBONUS:ThrownWeapon

      ...and the PC gets a choice of 1 of BladedWeapon, SharpWeapon or ThrownWeapon.

      Since we don't have dynamic lists (meaning we can't have CHOOSE:WEAPONPROFICIENCY|SOMESPECIALLIST), we can't duplicate the existing behavior ... so I'm not sure how we think we can deprecate it.
       
      TP.
      --
      Tom Parker


      From: Andrew <drew0500@...>
      To: pcgen_developers@yahoogroups.com
      Sent: Thursday, March 8, 2012 9:59 AM
      Subject: Re: [pcgen_developers] We Deprecating WEAPONBONUS?



      Hi James,

      I never have used the token/tag BONUSWEAPON, and didn't even notice its presence until I'd implemented a standard solution for the commoner (I guess these poor guys aren't commonly used (pun intended)).

      Yeah, one obscure tag that requires you to know to go to a certain screen without any indication is a bad design to me, so this is a vast improvement.

      As to your thought on switching it to a chooser based dialog for now, I'd agree - for backwards compatibility for homebrews, we'll deprecate effective immediately and set to be removed 6.2. I'll remove it from the main sets so we don't have any issues with a double chooser. I'll also agree, reimplementing on button or tab screen for an obscure issue doesn't make sense.

      I'm scanning our sets for it's usage (Note to self - don't include the code folders)

      On 3/8/2012 3:39 AM, James Dempsey wrote:
      --
      Andrew Maitland (LegacyKing)
      Admin Silverback - PCGen Board of Directors
      Data 2nd, Docs Tamarin, OS Lemur
      Unique Title "Quick-Silverback Tracker Monkey"
      Unique Title "The Torturer of PCGen"




    • Tom Parker
      Actually, now that I think about it, this is a fantastic project for one of the folks looking for something to do... the underlying infrastructure is _all_ in
      Message 2 of 5 , Mar 8, 2012
      • 0 Attachment
        Actually, now that I think about it, this is a fantastic project for one of the folks looking for something to do... the underlying infrastructure is _all_ in place, it just needs some work to actually implement... and shouldn't be all that bad (98% of the work is in the plugins, so work is rather isolated).

        What needs to be done?

        1) Method to create lists

        initial proposal, global token:
        LIST:DEFINE|x|y|z|z|z
        x=CDOMObject type (e.g. ABILITY=Category, FEAT, LANGUAGE, etc.)
        y=List name (user choice, can't use reserved characters, _must_ not start with *)
        z (optional)=Items to put on the initial list

        *Note: This is really off the cuff to get folks thinking about it and able to ask questions by the code team meeting on Friday if they are interested.  We would have to check the code to see if we want a define or just use ADD and DEFINE is implicit.  This somewhat depends on whether we can have something distinguish DEFINE with z and ADD.  If not, we can make it implicit or prohibit z on DEFINE and just make it the definition of an empty list (and require DEFINE and ADD on the object)

        Code: What happens here is you load a global list modification (this will be rather similar but not identical to how WEAPONBONUS works - today it uses WeaponProf.STARTING_LIST, but in this case, it would be a dynamic list of the type defined by x and with the name defined by y)... it should be a CDOMObjectList<x> NOT a specific subclass that forces us to have a lot of empty classes [we want to keep things generic going forward] - you'll need a class like ListKey (there are dynamic lists created there), but which storing  things that go into the list modification system in CDOMObject - meaning lists of CDOMList<? super T>)

        2) Method to add things to lists
        LIST:ADD|x|y|z|z
        x=CDOMObject type (e.g. ABILITY=Category, FEAT, LANGUAGE, etc.)
        y=List name (user choice, can't use reserved characters, _must_ not start with *, like variables have to have hit a DEFINE first)
        z=Items to add to the list

        Code: What happens for ADD is you load a global list modification (again, this will be rather similar but not identical to how WEAPONBONUS works - today it uses WeaponProf.STARTING_LIST, but in this case, it would be a dynamic list of the type defined by x and with the name defined by y)... it should be a CDOMObjectList<x> NOT a specific subclass that forces us to have a lot of empty classes [we want to keep things generic going forward])

        Note REMOVE is a bit more complicated (requires some infrastructure work), so (a) We need to ensure we have a specific use case that _requires_ it not a "that would be nice" opinion, and (b) It should be a separate set of work.

        3) Method of using lists in CHOOSE.
        New CDOMObject primitive:
        LIST=x
        x is the list name as defined in the LIST token (above)

        Code: This is a new plugin in plugin.primitive.pobject, and would have to go through the CDOMObjects attached to the PC and extract any that added to the given LIST.  Note a CHOOSE is structured as:
        CHOOSE:x|q[p]|q|p

        This is a new "p" (primitive).  Since x is the type of CDOMObject type (e.g. FEAT, LANGUAGE, etc.), then we know enough information (the list type and the list name) to make the exact same method calls to get the appropriate list (just like the LIST token would have to have done in 1 and 2 above [this is why we don't need a separate class - we have all of the exact information to produce an identical object - what we WILL need - and is likely the only work in the core - is an enumeration of these things just like ListKey [in this case probably ListObjectKey] that has the same getConstant type methods as in ListKey.)

        Given the above, WEAPONBONUS could be converted to a new list (like, uhh, WeaponBonus) and we could convert them to LIST:DEFINE/LIST:ADD depending on the location.  (DEFINE in Race, ADD in Template, Ability).  Then we can add a new AbilityCategory with a point for any Race that had a DEFINE (AbilityCategory in AC file, then point via a BONUS).  Then create the Ability that has the appropriate CHOOSE:WEAPONPROFICIENCY|LIST=WeaponBonus that is in that AbilityCategory just defined... in that way the conversion is capable of being done in a fully automatic fashion, WEAPONBONUS and LANGBONUS can be properly deprecated in 6.0, removed in 6.2, and we get out of a unique UI (for both WEAPONBONUS and LANGBONUS) in the new UI.

        We also get to close the ABILITYLIST and a few other token FREQs all at once, since this will have only a small slice of code working across a lot of things :)

        Thoughts? (other than this probably belongs on _exp?)

        TP.
        --
        Tom Parker


        From: Tom Parker <thpr@...>
        To: "pcgen_developers@yahoogroups.com" <pcgen_developers@yahoogroups.com>
        Sent: Thursday, March 8, 2012 12:51 PM
        Subject: Re: [pcgen_developers] We Deprecating WEAPONBONUS?



        This impact LANGBONUS as well?

        Unfortunately, I don't think this is as simple as this discussion implies.

        It can be used in Race:
        FooRace <> WEAPONBONUS:BladedWeapon|SharpWeapon

        Then in a Template:
        BarTemplate <> WEAPONBONUS:ThrownWeapon

        ...and the PC gets a choice of 1 of BladedWeapon, SharpWeapon or ThrownWeapon.

        Since we don't have dynamic lists (meaning we can't have CHOOSE:WEAPONPROFICIENCY|SOMESPECIALLIST), we can't duplicate the existing behavior ... so I'm not sure how we think we can deprecate it.
         
        TP.
        --
        Tom Parker


        From: Andrew <drew0500@...>
        To: pcgen_developers@yahoogroups.com
        Sent: Thursday, March 8, 2012 9:59 AM
        Subject: Re: [pcgen_developers] We Deprecating WEAPONBONUS?



        Hi James,

        I never have used the token/tag BONUSWEAPON, and didn't even notice its presence until I'd implemented a standard solution for the commoner (I guess these poor guys aren't commonly used (pun intended)).

        Yeah, one obscure tag that requires you to know to go to a certain screen without any indication is a bad design to me, so this is a vast improvement.

        As to your thought on switching it to a chooser based dialog for now, I'd agree - for backwards compatibility for homebrews, we'll deprecate effective immediately and set to be removed 6.2. I'll remove it from the main sets so we don't have any issues with a double chooser. I'll also agree, reimplementing on button or tab screen for an obscure issue doesn't make sense.

        I'm scanning our sets for it's usage (Note to self - don't include the code folders)

        On 3/8/2012 3:39 AM, James Dempsey wrote:
        --
        Andrew Maitland (LegacyKing)
        Admin Silverback - PCGen Board of Directors
        Data 2nd, Docs Tamarin, OS Lemur
        Unique Title "Quick-Silverback Tracker Monkey"
        Unique Title "The Torturer of PCGen"








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