Light item separate from consumed resource option

[picollo-24]

Some items (like lanterns) have scenarios where you're using oil to light them, but the lantern itself is the source of light.

Would it be possible to add scenario where you need item X to be able to have light, but consumed resource would be object Y instead (also required in the inventory)?

[lupestro]

I really don't want to get into all that complexity because:

• we don't know anything about time beyond the very primitive notion of "a single use".
• the passage of time is handled differently in every system.
• every time we have moved in the direction from utility - "hey, the lights came on!" - to simulation - "okay, guys, who brought the matches? Did nobody think to bring matches?" we get a lot of pushback because most players don't game that way.

There are quite a lot of things we shamelessly don't do: dropped light sources, light sources that consume spell slots when lit, light sources in spells that also have other game-effecting side-effects. Your request is more akin to those than to other things that have come up. They all require knowing more about game system rules and how the game system structures data than I feel comfortable supporting in a general use module. (Okay, dropped light sources is admittedly borderline for that. Maybe one day...)

However, thanks for the suggestion.

I don't want to leave you completely "high and dry", though.We have recently added the ability to invoke torch functions from macros, so you might experiment with that to get what you want. It's in the README.md.

[claycle]

I would second the OPs request. I was making a system JSON for RuneQuest, and in that game, candles are a light resource that you can also use in Lanterns. As currently modeled, the candles can be used (consumes candles) and the lantern can be used (does not consume the lantern), but the lantern should consume a candle when used.

The OP's request is a fairly system agnostic request.

[lupestro]

@claycle I see what you mean.

If the candle you use as fuel is consumed per use, then we don't need to tangle with ideas like time. We would need only create a module-specific relationship called "fuel" that relates the light source named Lantern with the consumable fuel named Candle. A Candle could also appear independently as a consumable light source in its own right.

What about the original request?

In the original request, the object named Oil could be referred to as a fuel to ensure that you at least have some in your inventory, but

• oil isn't consumed per use
• Foundry has no common concept of time beyond "per-use" or (only in encounters) "per round".
• I never want this module to depend on some other module (like Simple Time) for its features to work.

Without a way to track consumption, the best we could do for Oil would be to insist that the user have some oil in their inventory to use an Oil Lamp. A feature that consisted of nothing more than "nanny-minding" the inventory didn't seem really compelling to me.

In cases where we don't have a general Foundry way of tracking usage, I'm quite happy to fall back on the GM to negotiate that with the player via roleplay, especially where the concepts involved are loose or fluid. This lets the GM bring limitations into play when they'll enhance gameplay the most, which should be the point of the exercise:

You've been running this oil lamp for hours, buddy. Reduce your supply of lamp oil by one flask. Oh, that was your last one? Your lamp looks like it will gutter out very soon. You hear a dry chuckling out in the darkness...

I get enough complaints about the attention we pay to inventory as it is. :) Many gaming tables care only about equipment with combat stats. Beyond weapons and armor, if it seems reasonable to have it, you can assume that you have it. So I hear:

What? If I want to light a torch, I actually have to buy them? And then count them? Really??!

Don't worry, guys - I've heard you - I've got a feature in the works - just getting my test cases in play to support the added internal complexity of bigger decision trees - "dry as dust" boring stuff so I'm dragging my feet but you'll thank me later - soon.

Proposed Feature

I could enhance the module to support the "fuel" concept by applying the following sub-features:

• Light sources identify the fuel that drives them. (I'd still stick with one light source supports only one kind of fuel. I don't want to add UI for selecting which fuel to use - too much complexity.)

• Light sources that take fuel are only shown in the HUD when both the light source and the fuel are in the actor's inventory.

  • If there is a light source in the actor's inventory but not the fuel, the user gets a warning when selecting light sources.

• Consumable fuels are consumed and their count reduced in the inventory.

• Only fuels are consumed, not light sources.

  • A candle or torch, as a light source, lists itself as its own consumable fuel.
  • Other self-fueled light sources might list themselves as non-consumable fuel.

• A light source whose fuel is in the inventory with quantity zero has a slash through it indicating it's time to buy more.

Complexity

We always need to look at what any feature does to complexity so we don't make the module harder for casual use:

• For the module maintainer: Complexity in the light source definition.
• For the GM: Complexity in custom light sources.
  • Instead of consumable: boolean on a light source, we have fuel: {name: string, consumable: boolean}.
  • Fallback: if just consumable appears, i.e. the original text, the name of the fuel is assumed to be the light source itself.
• For the user:
  • A message if the light source is supplied but no fuel is in the inventory.
  • A slash on the fuel if the quantity of consumable fuel in the inventory is zero.

Feature interaction

• Planned future: allowing for ignoring all equipment via a switch in the module config:
  • all of the light sources in the game system and their fuels would be available to all the players at any moment with no fuel limits
  • this proposed feature would not come into play and hence would have no impact

Time for Folks to Chime in...

• Will this feature enhance your gameplay?
• Will this feature detract from your gameplay?
• What considerations have I missed?