Proposal Attachment

This is a proposal for a new equipment tag that works similar to CONTAINS but with the following difference.

Items that are stored in containers using CONTAINS count as "carried", so that their bonuses and abilities are not applied.

Items that are stored in containers using ATTACHMENT use the same location as the container, i.e. if the container is equipped, so is the attached item. Then it can grant its bonuses and abilities, even if stored in a container.

As described in http://jira.pcgen.org/browse/NEWTAG-469, this is needed for various implementations, such as Wayfinders, the nine-ring-sword and some artifacts from a certain Pathfinder Adventure Path.

MARK:

This idea has been bandied about in various forms. But we need a solution that will handle all contained items. Some items in pathfinder work as long as they are anywhere on the person, even carried. Even carried in containers that are also in containers in other containers.

A better mechanism would be to define, in the item, where it is considered equipped. Some considerations to make a comprehensive solution include:

- item functions if slotted in another item specifically designed to slot it and where the other item must be equipped (such as nine ring sword or hand of glory)

- item functions if carried anywhere on the pc but not in an extra dimensional space (spherewalkers staff, nexus crystal, whispering coin, etc)

- item functions if another item is present and otherwise considered equipped (either directly or indirectly) on the PC but with no requirement to be carried within that other item.

TOM: o the challenge here is we need to decide how deeply we want to solve the problem, which in my opinion is a valid discussion for a proposal. That doesn't mean we reject the proposal because there is a larger issue, just that having the larger frame is a valuable part of understanding.

I also believe that some of the comments in this thread are correct - In fact, I'll be more blunt: The current buckets don't work. The truth is that the current buckets are mostly unrelated... so we should recognize that there are actually two things at work and separate them.

The first consideration is where the object is located.

The second consideration is whether something is "active" on a Player Character (can apply bonuses, et. al.)

If we just think about carried and not carried, all 4 "buckets" are valid situations for some object:

active, carried (e.g. weapon) [currently we think of this as equipped] active, not carried (e.g. artifact in a castle or whatever) [not sure we can do this today] not active, carried (e.g. in extradimensional space, or just your backpack) [Carried today] not active, not carried (e.g. your house) [Not Carried today]

The thread has lots of examples that break this simple model, even if we add the 2nd item.

Having said all that, the two considerations are not totally independent of each other. It would be nice if they were, but they aren't, as Mark pointed out. In fact, active seems to be derived from the location, based on each item.

But we also know that it is more than carried and not carried. If I've followed this discussion correctly, it's actually: - Equipped - Attached (same activity as parent item) - Carried - Carried, Extradimensional - Not Carried

Some items are active when carried, some active when equipped, etc. So it seems to me that we don't need a replacement for contains. We go down the path Mark suggested: Each piece of equipment gets to identify when it is applied.

Let's call that APPLYWHEN: for giggles.

Default is probably APPLYWHEN:Equipped, because that is today's behavior and so we don't have to change a ton of equipment... or we could do the default as Equipped|Attached...

APPLYWHEN is a list token, would likely need .CLEARALL associated with it. It is a list of allowable states for application.

We also need a CONTAINERTYPE: (I don't like to overuse TYPE, so would love other ideas, but again for giggles to get the concept across). The default is likely to be CARRIED if none other is specified. (Some of the magical bags would need EXTRADIMENSIAL added to their entry in the LST files)

CONTAINERTYPE: is a single entry token, overwrite.

Then something in the code needs to recognize when something has CONTAINS, to look up the CONTAINERTYPE and check the APPLYWHEN on the items in the container. (Actually the same Facet Stefan probably needs to change to do ATTACHMENT ;) )

The biggest issue is that if we have an extradimensional space within a backpack (or vice versa), to track that container-in-container situation (I'm ignoring the UI issue since that should be opened as a bug and should not impact the architecture). So we generate a set of CONTAINERTYPEs that something is part of, and it thus needs to meet all of them in its APPLYWHEN.

That would presumably prevent something from applying regardless of whether an extradimensional space was the top or sub container.

It would also prevent something that is properly ATTACHED from being applied if the parent is Carried.

I would think the arguments to CONTAINERTYPE and APPLYWHEN are defined in the data, the code never needs to care about the exact values (ignoring for the moment that for the foreseeable future we'd probably have to tie the data team's hands with at least EQUIPPED, CARRIED and NOTCARRIED since those are very much hard-coded concepts in the code in other places.)

This requires at least: (1) An error check to ensure that everything ever used in CONTAINERTYPE is also in an APPLYWHEN (and vice versa) or produce a load warning. (This is likely a typo) (2) The (e.isEquipped()) check in the EquipmentFacet would need to be changed to the larger check, as well as "peel apart" any containers to find what is inside (this will require a check to know what is included in the currentEquipment list... I don't think it would include container contents) (3) All other uses of isEquipped would need to be checked and probably replaced with a new isActive

There may be other things I'm missing (some currently built in terms may need help)... but I think this is the path to investigate.

ANDREW M: Excellent discourse Tom.

If you want to really get into the impact of the proposal though, your APPLIEDWHEN will need to be a bit more flexible. From what I saw, your intention is ITEM based. However, it's worse than that... Let's take for instance an item that exists today with some hypothetical add-ons:

I have Artifact "Foo", let's make Foo a longsword.

Foo has a BONUS that is granted to the PC - APPLIEDWHEN:Carried

Foo grants a +8 AC bonus to the PC when it's possessed (carried, equipped, etc.) Foo grants a +5 Luck bonus to Saves when Held in the hand (equipped state) Foo has the standard Damage and weapon block, which has a preference to display if Carried or Equipped. (So a Conditional "APPLIEDWHEN:if("Rule","TreatCarriedAsEquipped",Yes),Carried,Equipped")

If I have WHENAPPLIED as a item/object, then we cannot support the two states presented on Foo. Therefore, I need to be able to split up WHENAPPLIED based upon both Object and Bonus (or MODIFY if we want to expand to bring in the Formula).

Gets a bit tricky.

Hope that explains the very intricate items a little bit better.

TOM:

Interesting, but I think that would be a "phase 2" of the project. The premise I proposed holds. The item itself is APPLYWHEN:Carried, because pretty much by definition a MODIFY or a BONUS are applied when carried.

Beyond that, the item then has a BONUS (today) or MODIFY (maybe future) that is conditional on being Equipped.

So most likely this would be address with something like: MODIFYOTHER:CHECK|ALL|Value.Luck|ADD|if(isLocation(this(),"Equipped"),5,0)

...or some such function, with implementation TBD.