Skip to content

Releases: brunocalado/light-sources

0.8.3

Choose a tag to compare

@github-actions github-actions released this 14 Oct 15:06

Fixed

  • Dropped lights land on the token's level (#21, thanks @bdavis19). A light dropped from the Token HUD is placed on the level and at the elevation of the token that dropped it, instead of on every level of the scene.
  • A light's on/off control shows only on its own level (#21). On a scene with several levels, the players' control over an interactive light appears only while one of that light's levels is being viewed.
  • Pickup and switching stay within the token's level. A token can only pick up or switch a light on its own level, not one on the floor above or below at the same spot.
  • Map controls no longer pile up. Changing scene or level left the previous on/off controls on the map, one more set per change, and the stale ones never updated or went away.

0.8.2

Choose a tag to compare

@github-actions github-actions released this 13 Oct 00:23

Added

0.8.1

Choose a tag to compare

@github-actions github-actions released this 04 Oct 20:03

Fixed

  • Italian translation updated (#18, thanks @GregoryWarn). Adds the missing strings for the refused-light notice and the effect expiry event, and tightens the wording of the running-low option.

0.8.0

Choose a tag to compare

@github-actions github-actions released this 02 Oct 12:43

Added

  • A light that spends a charge keeps the time it had left (#16). Putting out a "charge" light before it burns down — with Extinguish Light, through deactivate, or by lighting another source — keeps the time it had left on its item. The next lighting of that item burns that time without spending another charge, and an item that kept time can still be lit at 0 charges. Hover the source in the flame menu to see how much is left. A light that burns out, or that moves to the ground or to another character, keeps nothing this way. See the API docs.
  • Lights that run low before they go out (#12). Each pattern can have a second, running-low look — its own radii, color and animation — and a source's Running Low Phase sets how many of its last minutes use it. A light switches to it on its own, in hand or on the ground, and switches back if the clock is rewound. registerSources accepts it as ending on a pattern's light and endingMinutes on the entry. See the API docs.

Fixed

  • The flame button's tooltip is shown. Hovering the flame button on the Token HUD now tells what is lit and how many minutes it has left. Foundry 14 never displayed that text.
  • A GM can drag a dropped light on the Lighting layer (#12). The players' on/off control over an interactive light sat on top of core's own light icon, so dragging the light switched it off instead of moving it. The controls are now hidden while the Lighting layer is active, where a right-click already switches a light.

0.7.0

Choose a tag to compare

@github-actions github-actions released this 02 Oct 00:35

Added

  • Advanced light options per pattern (#12). Each pattern in the light editor has a folded Advanced section with Foundry's coloration technique, luminosity, attenuation, saturation, contrast and shadows. They apply only when Use Advanced Options is ticked, and then both on the token and on a light dropped on the ground. Left off, a pattern behaves exactly as before: the token keeps its own advanced options and a dropped light uses Foundry's defaults. Not offered for a darkness source. registerSources accepts them as an optional advanced object on a pattern's light. See the API docs.

0.6.0

Choose a tag to compare

@github-actions github-actions released this 01 Oct 22:22

Added

  • A light source can be kept from being dropped (#14). A new Can Be Dropped switch on the Consumption tab of the light editor, on by default. Turned off, the Token HUD no longer offers Drop for that source, for a light built into what the character wears, such as glowing armor or a lamp fixed to a helmet. The light still leaves together with its item when a module carries the item off through dropLightWithItem or handOverLight. registerSources accepts it as droppable. See the API docs.

0.5.0

Choose a tag to compare

@github-actions github-actions released this 01 Oct 18:11

Changed

  • Every registered pattern needs an id. A pattern was identified by its name, so a translated name gave the same pattern different ids on clients with different languages, and a pattern with no name, which the docs allowed for a source with a single pattern, was rejected. A pattern now has an id, a key unique within its entry that is never shown. Its name is only the label: it can be localized or left empty. An entry with a pattern missing an id, or with two patterns sharing one, is skipped with a console warning. activate's pattern option takes the pattern's id instead of its name. See the API docs.

0.4.0

Choose a tag to compare

@github-actions github-actions released this 01 Oct 16:36

Added

  • Copy light sources to another world (#11). A new Import or Export Light Sources menu in the module settings saves the world's light sources, the GM's edits to sources that modules provide, and the System Compatibility settings to a JSON file, and loads such a file in another world. The import shows what it will change before writing anything. Compatibility is applied only between worlds of the same game system. A source whose item does not exist in the new world is still imported and keeps working by name and type.

Changed

  • Light sources registered by other modules are no longer stored in the world. Each module registers its sources again every session, on every client, and only the GM's own sources and the GM's edits are saved. A module that is disabled takes its sources with it, unless the GM edited them. Modules using the API must call registerSources on every client, not only the GM's. See the API docs.
  • A source's id is its item's UUID. activate takes that id, and getActive reports it as sourceId. A pattern's id is the name its module registered it under.
  • Light sources configured before this version are not kept. The module now stores them in a new setting, so a world updated from 0.3.0 starts with no sources of its own and has to set them up again. Lights burning during the update can still be put out and still burn out, but they can no longer be dropped, picked up or handed over.

Fixed

  • A light with no color works in Daggerheart. A pattern whose color was left blank made Daggerheart throw an error when it was lit, and the token stayed dark. Such a light now shines with no tint, as it always did in other systems.
  • A light source the GM removes stays removed. Removing a source registered by another module used to last only until the next session, when the module registered it again. It is now listed under Removed module light sources, where Restore brings it back.
  • registerCompatibility no longer tries to write world settings from a player's client, which only a GM may do.

0.3.0

Choose a tag to compare

@github-actions github-actions released this 30 Sep 22:15

Added

  • A light can spend a charge and burn on its item. A new consume value, "charge", spends one charge of a single object instead of one copy of a stack: a torch that can be lit three times, a wand with charges. The light burns on that item, so it goes out when the item leaves the character and travels with it when a module carries the item onto the map. Two new compatibility paths say where charges live: Item Charges Path (charges left, e.g. system.uses.value) and an optional Charges Spent Path for systems that count charges used instead (e.g. system.uses.spent). Both can be seeded through registerCompatibility. See the API docs.
  • A lit item handed to another character keeps its light. A new API function, handOverLight, lets a system or module that gives items between characters take the light along. Create the copy on the receiver, call handOverLight(original, copy), then remove the original. The light moves with the time it had left and spends nothing, so a torch with charges doesn't lose one to a lighting that never happened. Between two players it goes through the GM. See the API docs.

Changed

  • consume says what lighting spends. The API and the stored sources take "none" or "copy" instead of false or true. An API entry with any other value is skipped with a console warning. There is no migration: a source stored with the old boolean lights without spending until it is registered again or opened in the editor and saved. The editor shows a select instead of a checkbox.

Fixed

  • A light the game system refuses is no longer spent or announced. Some systems don't let modules add effects to actors. PF2e refuses all of them (#9). Lighting a source there used to spend the item and post the "lit" message while the token stayed dark. Now nothing is spent, nothing is posted, and a warning says the light was refused. activate returns false, and pickupGroundLight and handOverLight return the reason "refused". On PF2e the module still can't light anything.
  • A light set down from the Token HUD can't be lit a second time. A lantern put down and lit again used to give two lights from one lantern. Picking the light back up now returns it to the item it came from.

0.2.0

Choose a tag to compare

@github-actions github-actions released this 30 Sep 01:37

Added

  • Other modules can carry a lit light to the ground with its item. Two new API functions, dropLightWithItem and pickupGroundLight, let a module that moves items between sheets and the map (loot, a thrown lantern) take the light along. The light lands where the item lands and comes back with the burn time it had left. See the API docs.

Changed

  • A lit light belongs to the item that burns. A light from a source that doesn't consume its item now remembers which item it is. getActive reports it as itemId.

Fixed

  • Removing a lit item puts its light out. Deleting a lit lantern from a sheet, or dragging it to another actor, used to leave the token glowing until the timer ran out.
  • Burned-out lights go out without console errors, and lights on the ground go out on time. When the in-game clock moved past a light's end, Foundry's own effect expiry and this module both acted on the same light, and two checks could overlap and put the same light out twice. The error that followed also stopped that check before it reached the lights lying on the ground, so they stayed lit up to 15 seconds longer. Light effects now use their own expiry event, which Foundry leaves to this module, and the checks run one at a time. Lights lit before this update can still show the error once, when they burn out.
  • Ctrl+Z on the Lighting layer no longer loses or copies a dropped light. The GM's client recorded every light the module placed on the ground or picked up, including the ones done for players. Undoing on the Lighting layer could then remove a dropped light, putting the flame out for good, or bring back one already picked up, so the same flame burned in two places. Those changes are no longer recorded. Lights the GM places by hand can still be undone as before.
  • A player dropping a light with no GM connected keeps it. The light was put out on the token before the module found out there was no GM to place it on the ground, so it vanished. The light now stays on the token and the player is told a GM is needed.