Re: [pcgen_developers] We Deprecating WEAPONBONUS?
- 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 listsinitial proposal, global token:LIST:DEFINE|x|y|z|z|zx=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 listsLIST:ADD|x|y|z|zx=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=xx 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|pThis 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.--
From: Tom Parker <thpr@...>
To: "firstname.lastname@example.org" <email@example.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|SharpWeaponThen 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.
From: Andrew <drew0500@...>
Sent: Thursday, March 8, 2012 9:59 AM
Subject: Re: [pcgen_developers] We Deprecating WEAPONBONUS?
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:
Based on your comment to the pcgen list I think we should deprecate this tag. The hard part is that we don't want to implement a UI component just for this tag to then remove it after 6.0, so perhaps as an interim this should become chooser driven?
PS: I'd never encountered that one before.
On 8/03/2012 4:13 PM Andrew wrote
The NPC Class 'Commoner' in the new UI is broken - I'm reviewing the code and the commoner uses this little used functionality -
Tag Name: WEAPONBONUS:x|xVariables Used (x): Text (Weapon Proficiency Name)Variables Used (x): TYPE.Text (Weapon Type)What it does:
- This is a pipe-delimited (|) list of weapons or weapon types that are granted to the class as a choice of ONE of the listed weapons.
- This tag does not use a CHOOSE pop-up to make a selection. You nust use the "Lang, Weapon, and SA" dialog found on the "Summary" tab.
WEAPONBONUS:Dagger|Staff|Club|Mace|Sword(Short)|Shortbow (Composite)The class can choose from a weapon proficiency from "Dagger", "Staff", "Club", "Mace", "Sword (Short)" or "Shortbow (Composite)".
WEAPONBONUS:TYPE.SimpleThe class receives bonus proficiency in any one Simple weapon.Where it is used:Class Level Line.Note: In order to use it you have to switch to a non-existent tab. So, this begs the question, are we deprecating this tag, or re-enabling the missing tab, or another option?
Andrew Maitland (LegacyKing)--
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"