Token Lighting and Vision Control
Token Lighting and Vision Control
Token management is expanded to handle initiative and turn sequences by embedding functions to toggle combat status for tokens and automate initiative rolling. The script moves through the combat sequence using 'game.combats.active.previousTurn()' to manage turns, ensuring sequential order and appropriate game flow. This comprehensive management allows seamless transition between combat states and orderly resolution of combat scenarios .
Lighting configuration for controlled tokens can be managed by checking the current state of a token's light setting and updating it accordingly. If a token's bright light setting is already on, the light configuration is set to minimal (dim and bright light set to 0.1). Otherwise, the light is configured with specific dim and bright light radii, as well as other properties like color and animation type. This is done by invoking the 'update' method on the token's document with the appropriate lighting parameters .
All doors on the canvas are closed by updating each wall's 'ds' property, where 'ds' represents the door state. The script iterates over each wall in the scene, checking if the 'ds' property equals 1 (open) and setting it to 0 (closed) accordingly. This change effectively closes all doors via updating the 'updateEmbeddedDocuments' method for walls .
The macro automates combat management by first toggling the combat status for all tokens using 'canvas.tokens.toggleCombat()'. Subsequently, it rolls initiatives for NPCs in a private mode using 'game.combat.rollNPC()', ensuring that only game masters see the results, thus efficiently managing the combat state and sequence of turns in gameplay .
The script calculates the actual distance between two controlled tokens (tokenA and tokenB) using the geometric distance between their center points on the grid. It considers the horizontal pixel distance, applies the scene's grid distance, and adjusts for differences in elevation. The vertical distance is considered as the absolute difference in elevation data, and the total distance is reported using the Pythagorean theorem to consider both horizontal and vertical components, encapsulated in a chat message .
Token vision parameters are adjusted in real-time through a dialog that allows users to select vision types and light sources. The script updates vision parameters such as 'dimSight' and 'brightSight' based on vision type, and light properties like 'dimLight' and 'brightLight' through selected light source. Once confirmed, the script applies changes to each selected token, modifying how tokens interact visually with the environment .
Vision and light sources for tokens are customized through a dialog interface that allows users to select different vision types like 'dim60' for Darkvision (60 ft), and light sources such as 'candle' or 'torch'. These choices affect how much of the map a token can see (dim and bright sight) and the lighting parameters (dim and bright light) applied to the token. Such customization impacts gameplay by influencing visibility, strategic planning in terms of light management, and ambiance through visual representation in the game setting .
Specific in-game events or results are communicated to game masters through private messages using 'whisper' functionality within the chat data object. This includes results from stealth checks or perceptive observations formatted into a message and directed únicamente to GM by filtering and mapping game users who hold GM privileges .
To adjust the visibility settings of tokens, methods are implemented to update each token's display modes. For example, a method updates all controlled tokens so that names and health bars are only visible when hovered over by setting the 'displayName' and 'displayBars' properties to HOVER. Another method sets them to ALWAYS, making the names and bars visible at all times. This is done using 'updateEmbeddedDocuments' on the token's data with the new display modes .
The script determines visibility during stealth versus perception checks by first obtaining stealth rolls for selected tokens. It compares each token's stealth result with perception rolls of other tokens in the scene. If a token's perception roll is equal to or exceeds the active token's stealth roll, the token is considered to have spotted the active token. This process is iterated for each token, and a message is compiled and sent to GM to report outcomes .