Bring back unique light sources (no new macro functions) #5067
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Methods on `Token` to add or delete unique light sources and look them up. - Support in `AttachedLightSource` to resolve against a `Token` in addition to a `Campaign`. - Support in `TokenDto` to transfer unique light sources. Attaching (turning on) a unique light source works exactly as for a campaign light source: the ID is added to the list. The only difference in behaviour between unique and campaign light sources is where the definition lives.
The new version is not an overload of `updateTokenProperty()` but has a more descriptive name. It also does not rely on the caller deciding which `Token.Update` value to use. Instead, a `boolean` is accepted to toggle the light source on or off, and the method will pick one of the two valid `Token.Update` value based on that.
This only adds the ability to write a `"$token"` category in `getLights()`, `setLight()`, and `hasLightSource()` to restrict the operation to unique light sources on the given token, rather than restricting it to a campaign category. It also extends the wildcard (`"*"`) support in these functions to also look for unique light sources on the token.
The Edit Token dialog now sports a textbox where unique light sources can be defined. The syntax is identical to the light syntax in the Campaign Properties dialog except that categories are not supported. If a token has unique light sources, its context menu will display them under "Light Sources". They will be in their own "Unique" category, separated from the campaign categories. The functionality is identical to that for campaign lights.
The importer will synthesize unique lights for each light in the UVTT file. The range will be taken from the light's `"range"` field, and the lumens will be set to 100. The colour will be set to the light's `"color"` field, unless the map image has baked lighting in - in that case, the unique light source will be clear. The `IGNORES-VBL` flag will be set if the light's `"shadow"` flag is `false`. All light properties are now written to the GM notes. Previously we wrote a hand-picked subset, but now everything is there. This avoids any chance of missing some in the future if the UVTT format adds additional properties. There are a few limitations with the import: 1. UVTT does not include the shape or texture of the light, so imported lights are always treated as circles. 2. We have no equivalent to "intensity" so that remains unused.
|
That was quick. Looks like a good implementation. Quick question... If a token has a light source and is saved. Then imported into a campaign without that light source, will it convert to a "unique" light source on the token? |
kwvanderlinde
changed the title
No. Tokens don't actually store campaign lights, they just make a note saying that a certain light is activated. So at import time there's nothing available to convert. This PR doesn't change that. |
cwisniew
approved these changes
Nov 26, 2024
|
Damn you. I had just redesigned the whole config tab. *sigh* |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Identify the Bug or Feature request
Resolves #3087
Description of the Change
This adds unique light sources, originally from #4356. Unlike before, this change focuses primarily on UI changes and does not include any macro functions for manipulating unique light sources.
UI changes
The only way to define unique light sources for now is through the Edit Token dialog's Config tab. It has a textbox for entering light source definitions, following the same syntax as lights in the Campaign Properties dialog, minus the support for groups.
The token context menu's "Light Sources" sub-menu now shows a "Unique" group containing the token's unique light sources. If the token has none, this group will not be shown. Attaching and detaching unique lights works exactly the same as for campaign lights.
UVTT importer
The UVTT importer now defines and attaches a unique light source on the light tokens it produces. The range of the light source is taken from the light's
"range"field. The color is taken from the"color"field, but only if the imported map does not have baked lighting. Clear lights are produced if lighting is baked since the light color is already present on the map.The light's properties are still written to the token's GM notes as JSON, but now all properties are written rather than a hand-picked subset.
There are two limitations on this part of the importer:
"intensity"field goes unused as we don't have a equivalent concept.Macro function changes
The only change to macro functions is to add the
"$token"type togetLights(),setLight(), andhasLightSource. The"*"wildcard type will also include any unique light sources on the token in addition to those in the campaign.Possible Drawbacks
Existing macros may fail if they try to match up the results of
getLights("*")with the lighting info ingetInfo("campaign"), without validating that the keys exist. This would not immediately impact existing campaigns since it is only an issue if run against tokens with unique light sources added to them.Documentation Notes
How the Edit Token dialog looks for defining unique light sources:
How the token context menu looks for turning unique light sources on and off:
For
getLights()type parameter:"$token", unique light sources on the token are returned."*", all light sources - including unique light sources on the token - are returned.For
setLight()type parameter:"$token",namerefers to a unique light source on the token.For
hasLightSource()type parameter:"$token", only unique light sources on the token are checked."*", all light sources - including unique light source on the token - are returnedRelease Notes
This change is