PF2E - Move item to "held" state, help handle toggle "Torch is Lit"

[galaara98]

Foundry: 11.313 PF2e: 5.6.2

without torch module, one of the most normal ways to cause a light aura is via an equipable item being set to "held" in the PF2e "Rules Engine" a torch object has several "Rules", and like most PF2e the rules are only "in play" when the item is "equipped" versus exists, stowed, or if it has a "Worn Slot" then it must be in that slot (so a boring Torch has a Worn Slot of "Held in 1 Hand" (see first screenshot),

Because of the rules in a boring ol' torch, equipping the torch in at least 1 hand (see attached):

1. engages a rule for Token Light, but makes it predicated on a toggle called "lit-torch"
2. engages several rules around adding special Strikes [separated for whether the toggle "lit-torch" is on or off] (since a torch is not natively a weapon, this add the action to attack with it directly into the character sheet)
3. engages a rule that adds a flat amount of fire damages to a Strike that is from "This Item" while the toggle 'lit-torch' is true
4. engages a rule to add a toggle to the character sheet called lit-torch, with a friendly name of the Localization string found in PF2E.SpecificRule.LitTorch (in English it would say "Torch is lit")
5. engages a rule that if the toggle 'lit-torch' is on, add the appearance of a condition/effect with an image (since the rule has no label, the foundry players will see the name of the item on the effect)

the point of all of this is... I love the Torch Module for 2 reasons...

1. It gives an HUD item to the right click of a character that is both aesthetic and functional
2. and it gives excellent feedback and well thought out control of a particular "system agnostic" need: beyond simple personal light switch function: the ability for it to give feedback on lack of light source, and a way to pick a light source outside of the character inventory sheet is well done

I would like to see the Torch module better integrate into PF2e's "Worn State", and instead of determining if a light is available and then creating a Token Light aura, and instead I'd like to see the HUD interface puts the light source item into the characters hand.

I see lots of complications...

1. the first being how many hands are available. The answer to that is don't worry about it.. that is a GM/Player issue and the PF2e system or other modules can deal with alerting or blocking the action of "holding" the torch (NOTE: It does mean that if your module attempts to move a torch into a held state, you should check that it made it to held before your module provided additional functionality... because there is and probably will be more automation in the PF2e foundry world to block using more hands than a creature has)
2. Pf2e has created structure for the concept of held but not lit torches... you dont care about that directly, but the Users of the Torch Mod might have opinions on what is correct "default" when they click the HUD and the module's functionality might benefit by providing an interface to extinguish/light versus wield/stow?? Not sure how much it is worth it, but in my opinion if someone clicks on the Torch module HUD, they meant a lit torch, now. [NOTE: Lantern (Hooded) and Lantern (Bull's Eye) do not provide a strike nor a toggle to extinguish, but still should be equipped via "holding in 1 hand" to properly use them.]
3. Dropping or Un-holding outside of the Module... not too much of a concern, but does mean the UI in the HUD always has to show the state of the items as it understands them in the current, not just what it knows IT did to the light...
4. when to lower the count... as far as I can tell, and I'm not an expert: In pf2e rules as written, lantern oil has an "hours of use" https://2e.aonprd.com/Equipment.aspx?ID=29 [6 hours per pint of oil] and torches look like they are 1 hour (your current features support 2 lanterns in PF2e, and obviously the everburning torch is forever). In my opinion, as a pf2e GM and Player, i would just leave that all alone and not mess with count, because in game time is wild (BUT Pf2e game system DOES have in game time support, so you very well could track the total hours a filled lantern has been burning, and the total time the torch on the top of the stack has been in a lit state)

Extra: In theory you can find any item that is capable of being a light source by looking for if an item in a token's inventory has a TokenLight rule on it (and maybe has a TokenLight rule, where the type is 'torch', which i found to be true on torches and lanterns, but the PF2E system programmers could tell you more about what the purpose of that property is). Then you could support any item right away that existed in someone inventory, as far as "equipping" to a hand and unequipping, even if you dont do anything with the torch complications of the toggle (which again, in my opinion, i would be absolutely ok with when your HUD is used that the toggle is just forced on right away and then when used to turn off a light, the entire torch is just stowed... let the player use the inventory interface if they want an extinguished torch in their hand)

{
  "key": "TokenLight",
  "value": {
    "animation": {
      "intensity": 4,
      "speed": 1,
      "type": "torch"
    },
    "bright": 30,
    "color": "#975335",
    "dim": 60,
    "shadows": 0.2
  }
}

[lupestro]

I try to avoid letting Torch get involved with the specific mechanics of any system.

Rationale

This policy keeps me from having to make changes to Torch every time the wind blows across one system or another. Even the very narrow exception we made for GURPS was based on providing a cheap generic mechanism to support navigating any other custom item topology that came down the line. Since you can't provide a customization mechanism without at least two samples of use, we used the standard topology and the 40 lines of GURPS topology code as working examples that others could crib from, but since the first release of our new design last July, nothing else has needed it so far.

The pf2e rule elements mechanism has allowed them to more completely model the rules of the system than any other system I've seen. Designers of new systems should study what they've done. I know I will be studying it to see if something like it - probably pared way down - will help me keep the Fudge implementation malleable to support all the different Fudge-based systems and house rules. However, that doesn't change the rationale for a module like Torch standing clear of system specifics as much as possible, regardless of how widely the system is used.

Counter-proposal

The challenge here is to find a way where Torch can provide a generic interface that can then be used externally by any system or module for integration.

• In a recent release, we provided an API so that other modules or systems can control Torch, so I think we've got that direction covered.
• It sounds like the generic mechanism I haven't yet provided that might be useful for this is an event fired when the user changes the state of a light source, identifying the light source and its new state.

Assuming we had such an event, could a rule element or some workbench-type module for pf2e register for notification of the change?

If so, such an event would seem to me a broadly usable alternative. The pf2e code, which will need to track the progress of pf2e anyway, could then make the appropriate pf2e specific changes to stay in sync with the updated torch state.

Let me know if this would give you a starting place you could work with.

[galaara98]

hmmm,

1. Just FYI: i instantly leave my expertise by flipping to an event for pf2e (or a mod made for pf2e) to listen for (so i can only make statements at high level because I dont actually code in .js /.ts myself.)
2. in MY opinion we add work, for you, and for others, when the current solution is not 'enough pain' to justify it.
   The foundry "Game System" pf2e already has a decent amount of sophistication/automation for Inventory "Light" granting auras, but lacks "an easy button"
3. What the Torch Mod does so very gracefully is bring an intuitive interface, with iconography that is well understood, with actions and alt-actions that are natural, to the token's personal HUD.

However, GMs and Players can really just go and set their torch or lantern to "Held in One Hand", by

1. opening their character sheet,
2. changing to the inventory tab,
3. finding the Light emitting object,
4. clicking twice (once to open the small interface, once to choose to hold in hand)
5. and when the object is a type of torch, changing to the Action Tab (where toggles appear), and setting the toggle as appropriate.

So any work for you and for someone else to integrate the event you raise so as to cause a light emitting object to be held in one hand, would probably greatly out weigh the value. I was talking to a GM friend about my feature request and my first counter point against myself was system agnostic... however, as unfair as it certainly is, it's PROBABLY more reasonable for a mod like Torch to tell PF2e a light emitting object has just changed from worn to held in 1 hand than to find a way for pf2e system or a Mod to look for "User is requesting a light source [named X]" (and of course, I haven't looked at how hard it would be to set an Item to "is being held", so maybe i'm full of it).

And again, I very much get the value of system agnostic, and I want to make sure that you know that I am not requesting or beggin', etc. I am tickled that you responded to the ticket at all, and I can see how the design of an event that could be available in any system, would allow integration, but keep your code streamlined.

TLDR, i think that this would probably be better left as a pondering idea, but just know that pf2e has some extra gears related to "torches" and "lanterns"

[lupestro]

For now I've labeled this as enhancement, as I should at least provide the event that will make it possible for a third party to marry the module and the system. Perhaps, once the base hook is in place, someone with the appropriate js/ts experience and deep familiarity with pf2e will be able to say "Oh, yes, that isn't hard" and find a vehicle to deliver it.

That will certainly never happen if I don't provide some way for the communication to occur, so while I may not be implementing the solution here, I can at least "get out of the way" of the community providing satisfaction. The Foundry community is just amazing when they've got something to grab onto.